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

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

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: 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

Requiring workflows with Repository Rules is generally available

Requiring Actions workflows with Repository Rules is now generally available on GitHub.com!
Screenshot showing the add required workflow modal overtop the enabled rule inside a ruleset

Through Repository Rules, GitHub Enterprise Cloud customers can now set up organization-wide rules to enforce their CI/CD workflows, ensuring workflows pass before pull requests can be merged into target repositories. Additional settings allow for fine-tuning how the workflow file can be selected — either from a specific branch, tag, or SHA — and provide maximum control over the version expected to run.

Applying a newly created workflow policy across an organization can feel risky. To ensure confidence when enabling a workflow rule across targeted repositories, workflow rules can be put into “evaluate” mode which will validate the rule is working correctly. And don’t worry, organization administrators can even allow select roles to “break the glass” and bypass a rule when necessary.

Learn more about this release and how requiring workflows with Repository Rules can protect your repositories.

To share feedback or ask questions, join our Community Discussion!

See more

Repository Rules – insight enhancements

Repository rule insights now make finding more details about how someone merged specific code into your repos even easier.

🔍 Filter by status

If you want only to see bypassed rules, you can now filter rule insight by the status of the results.

No more scrolling through and sorting through all the insight activity to find that one bypass situation. You can now filter by All Statuses, Pass, Fail, and Bypass.

Overview of selecting different rule insights status types. And showing the change between pass, fail, and bypass

👀 Clamoring for more insight into your rule insights?

Well, now you have access to way more information, including who ✅ approved and ❌ denied a pull request. As well as having access to the results of all required status checks and deployment status states right in rule insights.

Rule insight instance showing a specific passed status check.

👩‍💻 REST API Endpoint

Want to look for ruleset failures for a specific app programmatically?
With the new REST endpoint, you can now view and query rule insights via your favorite API tools.

Repository Endpoint

All repo insight activity

–  GET http://api.github.com/repos/{owner}/{repo}/rulesets/rule-suites

Specific insight rule suite for a repository ruleset
–  GET http://api.github.com/repos/{owner}/{repo}/rulesets/rule-suites/{rule _suite_id}

Organization Endpoint

All org insight activity
–  GET http://api.github.com/orgs/{org}/rulesets/rule-suites

Specific insight rule suite for an organization ruleset
–  GET http://api.github.com/orgs/{org}/rulesets/rule-suites/{rule_suite_id}

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

See more

Block npm package publishes when names and versions don’t match between manifest and tarball package.json

On September 27, 2023, we began blocking npm package publishes with differing name or version fields between the manifest and tarball package.json. This blocking protects against obfuscation. The different fields in the manifests have been assessed from a risk-based perspective. We will continue to analyze for other mismatches that can be blocked that won’t have adverse effects on the ecosystem. If a package is blocked, a user may receive an error message similar to “Package ‘version’ is “1.0.4”. It should match “1.0.3” from “package.json” in packaged tarball. Make all changes to package.json before packaging a tarball to publish.” In addition, a new tool, npm pkg fix, can help users fix any validation errors from the registry when they attempt to publish a package.

See more
View more changes