repositories

Subscribe to all “repositories” 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

Enhanced Repo Insights Views

We’re thrilled to introduce improvements to Repo Insights!

New Enhanced Repo Insights Views

With this update, you’ll find significant enhancements to two of our repository insights views—Contributors and Code Frequency. Both now utilize an SVG-based solution, offering improved focus navigation for precise, point-by-point interaction. You can also hide a series by interacting with the chart legend and view or download the data in both table format and as PNGs. Let’s dive into the details!

Contributors

  • Date Range Filter: While the click-and-drag date range selection was a handy feature, it was also a hidden feature. The new date range filter is always visible and fully navigable by keyboard, making it more accessible and easier to use.

  • Clear Date Range Display: The current date range is now explicitly listed under the heading, giving you a clear and immediate understanding of the data timeframe.

  • Responsive Contributor Cards: Previously locked to a two-column view, contributor cards are now more responsive on small screens, seamlessly wrapping to a single-column layout for a better viewing experience.

Code Frequency

  • Enhanced Axes Differentiation: The two different axes are now distinguished not just by color but also by line style, making it easier to interpret the data at a glance.

  • Detailed Tooltips: Data points are now navigable and display more details in a tooltip. Previously, you could only visually reference data against the axes. Now, you get more information directly from the chart itself.

Explore the new features and let us know what you think! Join the discussion within the GitHub Community.

To revert this update, click on your profile picture in the top right corner of the page, go to the feature preview menu, select “Enhanced Repo Insights Views” and click disable. If you choose to turn this feature off – please let us know why using the link listed above!

 

See more

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

GitHub Private Mirrors App – Public Beta

Today, we’re releasing a beta version of an open source GitHub App that manages private mirrors of public upstream repositories. The Private Mirrors App (PMA) enables organizations with regulatory or policy code review requirements to conduct their reviews in private, before contributing changes upstream. The app manages the lifecycle and synchronization of these private mirrors and automatically configures rulesets to manage PRs made to the mirrors.

The main benefits of working on private mirrors through PMA are:

  • Branch protection rules can enforce PR reviews by people on particular teams to ensure proper signoffs
  • If commits include code/keys/docs that should not be made public, there’s the opportunity to remove them and squash merge without leaking history
  • Initial development can happen inside an Enterprise Managed Users (EMU) organization, whose users ordinarily can’t interact with public GitHub repos. Once the app syncs a change, the public fork and upstream PR use normal github.com identities.

If this is interesting to you, check out the Private Mirrors App repo. If you’ve got questions or feedback, feel free to file an issue in the repostitory or join the conversation in the GitHub Community Discussions.

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

Sunset Notice – Tag Protections

EDIT: Monday December 2nd, 2024

GitHub Enterprise Server Timeline changing sunset to GHES 3.17 as the final version instead of 3.16.

Starting today, we will begin work towards the sunset of tag protections, with a full deprecation planned for August 30, 2024. See below for a full sunset timeline. You can migrate existing tag protections with the import to ruleset feature.

We launched repository rules last year to meet the needs of tag protection rules, while also scaling support to provide new functionalities like org-wide rules, granular restrictions for creating, reading, and updating events, and a more granular bypass model that does not require repository administrator permissions. As we such, we will sunset tag protections in favor of our ongoing investment in the repository rulesets platform.

You can import existing tag protection rules today with the existing migration feature. If no action is taken before the sunset date, GitHub will migrate all existing tag protections into a corresponding ruleset.

When are changes happening?

GitHub.com Timeline

  • May 30 : Repositories without tag protection rules will no longer be able to add new protection rules via the GitHub.com UI
  • July 24 through August 14 : A series of API brownouts will be run, see below for additional details on dates and times.
  • August 30, 2024: All tag protection rules will be migrated to a new tag ruleset. All REST and GraphQL API endpoints will be deprecated

GitHub.com API Timeline

  • May 30: API responses will include a deprecation notice
  • July 24: 1 hour API brownout
  • August 7: 8 hour API brownout
  • August 14: 24 hour API brownout
  • August 30: The tag protection rule API will begin responding with NULL data
  • The tag protection rules API will be deprecated in the next calendar version

GitHub Enterprise Server Timeline

  • Version 3.14: Tag protection rules will be marked for deprecation with an in-product banner and API responses will include a deprecation notice
  • Version 3.15: No changes will be made
  • Version 3.16: No changes will be made
  • Version 3.17: Tag protection rules will be migrated to a ruleset and the tag protection rule feature will no longer be available

 

Join the discussion within GitHub Community.

See more

[Public Beta] Repository collaborators for Enterprise Managed Users

Enterprise Managed Users can now be added directly to a repository in their enterprise as a collaborator, without becoming a member of the organization. These users function like outside collaborators, with a few differences:
1. Only user accounts from within the enterprise can be added to the repository. This means that users you want to collaborate with must still come from your linked identity provider (IDP).
2. EMU users can only be collaborators on repositories in their enterprise. EMU accounts cannot collaborate outside their enterprise.
3. Repo Collaborator invitations can only be sent by an EMU’s enterprise owner by default, while in non-EMU enterprises and organizations both enterprise and organization owners can manage outside collaborators.

Like outside collaborators – users do not have to SSO authorize their credentials in order to access repositories that they have been granted access to as a repository collaborators. This aligns to the current access model for internal repositories on GitHub.

You can try out repository collaborators by going to the repository policies section of your Enterprise settings and selecting which tiers of administrators are allowed to invite collaborators.

For more information about repository and outside collaborators, see “Roles in an organization“.

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

Push rules public beta

Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉

A glimpse of push rules in action

You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to the repository network are protected.

Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.

Learn more about push rules in our documentation and join the community discussion to leave feedback.

See more

Repository Rules – configure merge queue rule – public beta

Configuring merge queue in your repo rulesets is now available in public beta!

Screenshot showing the configuration of merge queue inside a ruleset

Merge queue & rule insights

Until now, rule insights would only list one pull request as merged even when multiple pull requests were merged by the queue at the same time. Also in this beta, each pull request in a merge queue will have an individual record in rule insights, linked to the actor that added the pull request to the merge queue.

Example screenshot showing rules insights and all PRs from a queue

Within the additional data of a rule insight dialog you can now see all the pull requests that merged in the same group along with the checks needed for the queue.

Example screenshot of details of a queue in rule insights

Limitations

  • The merge queue rule cannot be configured via an API. This feature will be available in the near future.
  • Merge Queue for branch protections and repository rules do not support wildcard patterns
  • Not supported in organization rulesets.
  • Multiple merge queues configured against a single branch will prevent merging.

Join the discussion within GitHub Community.

See more

Repository Custom Properties GA and Ruleset Improvements

repository custom properties banner image

We’re excited to announce the general availability of Repository Custom Properties, a major enhancement to how repositories are managed and classified across GitHub organizations.

Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets.

Check out this video from our own Jon Peck for a walk through of a common scenario.

New organization repositories list public beta

Starting today the new repositories list view moves to public beta.

Improvements to Repository Rulesets

Repository Rules now support adding Dependabot to bypass lists. This enables you to let Dependabot merge changes to a repository’s protected branch.

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

Head over to community discussions for feedback.

See more

Requiring workflows with rulesets now supports the pull_request_target trigger

Starting today, in Actions workflows, the pull_request_target trigger is now supported for repository rulesets that require a successful workflow run. This is in addition to pull_request and merge_group, making pull_request_target the third workflow trigger supported by repository rulesets.

Read our recent general availability announcement to learn more about how organizations can set up policies with repository rules that require a successful workflow run before code can be merged into its repositories.

Learn more in our repository rulesets documentation and don’t forget to ask questions or leave feedback in the community discussion.

See more

Additional repository metrics available via GraphQL API

There are two new metrics available under the Repository object in the GraphQL API:

  • LastContributionDate – The most recent date there was any of the following activity: a commit to a repository’s default branch, opening an issue or discussion, answering a discussion, proposing a pull request, or submitting a pull request review. This is a good single-number metric to find projects that may be unmaintained or in need of archiving.
  • CommitCount – A monotonically increasing count of the total number of commits pushed to the default branch of the repository. Tracking the change in this over time will give a sense of the overall activity in the repository.

These metrics are currently in public beta, so you will need to include a header to your GraphQL requests to opt-in:

GraphQL-Features: ospo_metrics_api

Additional documentation and context around these metrics is available in the github-ospo repo. Please provide your feedback on this discussion thread: https://github.com/orgs/community/discussions/72156

See more

New branches and commits pages – feature preview

New updates to the branches and commits pages are now in feature preview. These updates are focused on improved navigation, performance, and making these experiences more accessible.

Branches

Screenshot showing new branches page on GitHub Docs Repository

We added clarity to the list header explaining what each section of the branches page does. Stale branches are now hidden by default to speed up page load times.

GIF walkthrough of branches page showing the new UI and clicking on various elements to show new functionality.

Commits

Screen shot showing new commits page on GitHub Docs Repository

You can now filter commits by a date range and collapse the list per day to find the commits that matter to you quickly.

GIF showing the commits page filtering by date in a calendar and collapsing commits for a whole day

Click here if you have feedback and let us know in our community discussion.

See more

Repository Rules – Public Beta – History, Import, Export

Need to roll back a change to a ruleset? How about easily moving your ruleset around?

With today’s public beta you now have new tools to manage your ruleset.

Import and Export

Rulesets are now easier to share and reuse, with the ability to import and export rulesets as JSON files. Giving you the ability to share rules across repositories and organizations or to share your favorite rules with the community. Which is what we’re doing. The ruleset-recipes repository is home to a collection of pre-baked rulesets covering a number of popular scenarios ready for you to use.

Gif walking through the steps outline above to import a ruleset from a JSON file.

History

If you are a repository or organization administrator of GitHub Enterprise cloud, we’re adding a history experience so you can track changes and revert rulesets. Now, it’s easy in the ruleset UI to see who changed a ruleset, when it happened, and what changed. Then, quickly get back to a known good state.

Only changes made to a ruleset after the public beta are included in ruleset history.

Gif walking through the step of using history, and selecting a ruleset version to restore.Screenshot of Ruleset history comparison screen.

Click here to learn more. If you have feedback, please share and let us know in our community discussion.

See more

GitHub Repository Custom Properties Beta

PNG Custom Properties Header.

Starting today, organization administrators can create custom properties to enrich repositories with valuable information. Using these properties, you can dynamically target repository rules to apply protections on just your production repositories or to a business unit or any other way you want to classify your repositories.

Only organization administrators can configure custom properties; you can be confident knowing that they are not accidentally removed by a repository administrator, ensuring your branch and tag rules are consistently applied. Property values can also be automatically applied with default values at repository creation, ensuring every new repository is classified, and its first commit is protected.

Today, organization administrators can only use custom properties for dynamically targeting rulesets. But soon, you can use properties to filter and search in an updated repository list and other experiences across GitHub.

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

Head over to community discussions for feedback

See more
View more changes