repos

Subscribe to all “repos” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Repository updates July 31st 2024

We’re excited to bring an updated repository list view experience and the ruleset merge queue rule to general availability, as well as an update to the status check and workflow rules.

Finding repositories in your organization is now easier

With the introduction of custom properties earlier this year we wanted to make it easier to find repositories across your organization. With the new organization repository view and advanced filtering you find repositories based on common parameters like visibility and language, but also custom properties, size, license and a host of additional values.

Screenshot of repository list view filtered by visibility, archived status and a custom property showing a list of 64 repositories.

Repository Rules updates

Repository ruleset merge queue rule is now generally available

In addition to being able to manage your merge queue via rules, you can now see all the pull requests that merged in the same group along with the checks needed for the queue with rule insights.

Screenshot of repository rule merge queue options with default configurations.

Learn more about merge queues in our documentation and repository rules REST API

Avoid required status checks and required workflows when creating branches

Applying status check and actions workflow rules to newly created branches has been a point of friction in rulesets. When creating a new branch will fail unless you add bypass actors or create an intermediate unprotected branch. To alleviate this friction there is a new option available prevent checks and workflows from running on new branches.

Screenshot of require status check rule with the new "Do not require status checks on creation" option enabled

Learn more about status check rules and required workflows rules in our documentation.

Join the discussion within GitHub Community.

See more

Repository updates June 12th 2024

We’re excited to introduce enhancements to custom properties as well as updates to the push rule public beta.

Custom properties updates!

New property types

  • Multi select allows a repo to have more than one value for a property defined. Now a repository can have a property that defines a compliance requirement with values for FedRamp and SOC2, for example.
  • True/False allows you to set whether a given property is true or false for a given repository.

repository properties with multi select

Target rulesets by repository visibility and more

In addition to targeting repositories with the custom properties you’ve created, we’ve now extended property targeting to include the ability to target by:
– Visibility: public, private, or internal
– Fork: true, false
– Language: select primary repository language.

System property targeting in a ruleset screenshot

Learn more in the custom properties documentation

What do you think? Start a discussion within GitHub Community.

Push rule delegated bypass public beta!

We are expanding on the push rule public beta with a new delegated bypass flow.

Previously to bypass push rules you had to be on the bypass list to push restricted content. Now with delegated bypass, contributors can propose bypassing a push rule and members of the bypass list can review those bypass requests to allow or deny the content.

Learn more about push rule delegated bypass in the repository rules documentation and join the push rule discussion in the GitHub Community.

Delegated bypass screenshot

See more

Repository Updates April 30th, 2024

Repository Updates April 30th, 2024

  • Deploy keys are now supported as a bypass actor in repository rules, allowing additional granularity for your automations. Previously for deploy keys to bypass a ruleset the Repository Administrator role was required.

  • Webhooks and GitHub Actions will no longer be run for any push that includes over 5000 branches. Clients will now receive the following warning indicating they have reached this limit. remote: warning: No webhooks or actions will be performed for this push as it updates more than 5000 branches.

Join the discussion within GitHub Community.

See more

Code scanning now allows configuring rulesets to prevent pull requests from being merged (beta)

The code scanning option for repository rules is now available in public beta. Code scanning users can now create a dedicated code scanning rule to block pull request merges, instead of relying on status checks.
Making it easier than ever to prevent new vulnerabilities from being introduced into your code base.

code scanning rule

Configuring code scanning merge protection with rulesets can be done at the repository or organization levels and for repositories configured with either default setup or advanced setup. Additionally you can also use the REST API to set merge protection with rulesets.

You can use rulesets to prevent pull requests from being merged when one of the following conditions is met:
– A required tool found a code scanning alert of a severity that is defined in a ruleset.
– A required code scanning tool’s analysis is still in progress.
– A required code scanning tool is not configured for the repository.

Note: Merge protection with rulesets is not related to status checks. If the code scanning rule is configured for the repository in parallel with an alert threshold and the merge protection rule for the code scanning check run, the two functionalities will work simultaneously. For more information about status checks, see about status checks.

This beta is now available on GitHub.com and will be available on GHES 3.14. The organisation wide rules is only available for GitHub enterprise. For more information, see Configuring merge protection for all repositories in an organization.

We look forward to your feedback on the code scanning option for repository rules in the GitHub community.

See more

Updates to repository pages

We are rolling out a few minor updates to the user experience for GitHub repositories starting today, in order to be more responsive, performant and more easily accessed by a broader range of users.

Repository Overview:
Screenshot of repository overview page showing entering a letter to expand to go to file menu.

  • Go to file: Quickly get to the file you want from the top of every repository using our existing code search and navigation experience.
  • Special files: If you have Code of Conduct, License, or Security files in your repository, they are now shown in tabs alongside your README.

Branches:
Screenshot of branches page showing the overview tab for branches of GitHub Docs repos.

  • Status checks: At a glance, see the status checks’ details on any branch.
  • Stale Branches: The overview page for branches no longer defaults to showing stale branches to improve load times. You can still easily see stale branches by clicking the “Stale branches” tab.

Commits:
Screenshot of Commits page filtered by date and user.

  • Filters: New commits filters allow you to sort by users or limit results to specific date ranges.

These changes have been in a feature preview for the past few months and thanks to community insights, we’ve made several improvements that allowed us to now exit the preview, and bring these enhancements to everyone on GitHub. Join the conversation about this release in the community discussion.

See more

New Organization Repositories List Feature Preview

In October, we launched the beta of Repository Custom Properties, enabling you to attach key-value pairs to repositories in your organizations. Among many scenarios, one of the key components we had envisioned was the ability to filter your repository properties. Making it easier to find exactly the set of repositories you were looking for.

Starting today, you can enable a new list view for repositories. This update improves accessibility and performance and introduces a new filter bar supporting properties.

To enable select New organization repositories view option in the feature preview dialog.

PNG Custom Properties Feature Preview.

Learn more about managing custom properties for your organization and managing rulesets for your organization.

Head over to the community discussions to share your feedback.

See more

Upcoming changes to repository insights

Beginning January 8th, 2024, we will be making changes to the repository insights UI and API on GitHub for repositories with over 10,000 commits. The targeted UI and API have very low usage and rely on a legacy service we’re moving away from.

User Interface Updates

We are removing the following data:

  1. Under Insights > Contributors, we are removing addition/deletion counts for repositories with over 10,000 commits, as well as the dropdown that shows the graphs associated with additions and deletions. All the commit counts and commit count graphs will remain unchanged.
Current page Repos with over 10,000 commits after the change is made
The current Insights > Contributors tab The new tab which shows no dropdown for additions and deletions, and no addition and deletion counts
  1. Under Insights > Code Frequency, we will only show data for repos with under 10k commits.
Current page Repos with over 10,000 commits after the change is made
The current Insights > Code Frequency tab which shows a graph of additions and deletions over time The new tab which shows that there are too many commits to generate this graph

REST API Modifications

Alongside the UI changes, the following API changes will be implemented:

  1. The REST API responses for repositories with 10,000+ commits will report 0 values for the addition and deletion counts to improve performance. This impacts the /repos/{owner}/{repo}/stats/contributors endpoint to get all contributor commit activity
  2. The /repos/{owner}/{repo}/stats/code_frequency API endpoint will return a 422 status code for repos with 10,000 or more commits.
    • This is different from the previous two because this endpoint only returns additions/deletions, which we will no longer return for repos with over 10k commits. The previous two endpoints also return the total number of commits, which we will continue to generate.

For users who continue to need detailed addition and deletion statistics for large-scale repositories, we suggest using the following Git command, as described in the Git documentation:

git log --pretty="format:%m%ad----%ae%n%-(trailers:only,unfold)" --date=raw --shortstat --no-renames --no-merges

See more

Organization Archiving public beta

You can now archive all repositories in an organization with a single click. Archiving an organization will:

  • Archive all repositories in the organization
  • Set a key in the API to indicate the org has been archived
  • Restrict activities in that organization such as creating new repos
  • Display a banner on the organization's profile indicating that it's been archived

To archive an organization, go to the organization's settings page and click the "Archive organization" button in the Danger Zone. This will launch a background job which performs the archiving; once complete, the banner will show up on the organization's profile page.

For more information on organization archiving, including how to un-archive an organization, see "Archiving an organization"

This feature is in public beta. We'd love to hear your feedback on how it works for you.

See more

Custom repository roles API GA and breaking change

The Custom Repository Roles REST API has moved to general availability, with a breaking change to the path used.
Previously, the API was found at /orgs/{org}/custom_roles – it has been moved to /orgs/{org}/custom-repository-roles. With organization-level custom roles in progress, we found that the custom_roles path was wasn't specific enough and could generate confusion.
The deprecated beta API will be removed from api.github.com in 6 months, on September 7th, 2023.
On GitHub Enterprise Server, the API will be available at its new path in version 3.9. The previous API to list roles was added in GHES 3.4, and will be removed with the next API version.

To learn more about custom repository roles, see "About custom repository roles" and "Custom repository roles REST API".

See more

Custom repository role creation APIs are now available in public beta

Custom repository roles enable Enterprise organization administrators to define and assign least-privilege roles for their repositories, beyond the standard Read, Triage, Write, Maintain, and Admin roles.

Now, REST API endpoints to create and update custom repository roles are available in a public beta for GitHub Enterprise Cloud customers. These new endpoints build on the existing custom repository role APIs that allow assignment of those roles to a team or user. The endpoints accept PATs from organization admins, as well as calls from properly authorized OAuth and GitHub apps.

These REST APIs will be supported in GitHub Enterprise Server 3.8, after they reach general availability in GitHub Enterprise Cloud.

Find out more about programmatically creating custom repository roles.

We'd love to get your feedback through your account team, or in our community Discussions board topic.

See more

Custom repository roles are now GA

Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.

Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.

Custom repository roles can be managed in the Repository roles tab of your Organization settings:

image

Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.

To get started with custom repository roles, read the docs.

See more

GitHub Actions: Re-run jobs with debug logging

You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures.

To enable debug logging, select "Enable debug logging" in the re-run dialog.

Re-run dialog screenshot

You can also enable debug logging using the API or the command-line client.

For more details see
Re-running workflows and jobs.

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

See more

GitHub Actions: Prevent GitHub Actions from creating and approving pull requests

To further reduce the risk of a user using Actions to merge a change into a protected branch that was not reviewed by another person, the organization setting to disallow Actions from approving pull requests, which was introduced in January 2022, has been extended to also limit Actions from creating pull requests.

The Allow GitHub Actions to create and approve pull requests setting can be managed by admins in organization settings under Actions > General > Workflow permissions.

image

See more
View more changes