Skip to content

Changelog

Subscribe to all Changelog 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

Actions – Secure deployment rollouts to protected environments based on select tag patterns

We now allow defining selected tag patterns for securing your deployments that can run against Actions environments.

Previously environments supported 'Protection Rules' for restricting deployments only for selected deployment branches. We are now enhancing this feature for securing deployments based on selected "Deployment branches and tags".

Admins who want to have more secure and controlled deployments can now specify selected tags or tag patterns on their protected environments – Ex: They could now define that only deployments triggered by tags that match the pattern of "releases/*" could deploy to their "Production" environment.
Deployment Branches and Tags

Learn more about securing environments using deployment protection rules.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

GitHub Actions: NODE_OPTIONS is now restricted from GITHUB_ENV

Due to security restrictions, users can no longer use GITHUB_ENV to set the NODE_OPTIONS environment variable in their workflows. Developers who have NODE_OPTIONS set as an environment variable will now receive an error: Can't store NODE_OPTIONS output parameter using '$GITHUB_ENV' command.

This change was introduced in actions/runner v2.309.0.
For more information on how to set environment variables, please see our docs here.

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

MaxMind is now a GitHub secret scanning partner

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with MaxMind to scan for their license keys and help secure our mutual users on public repositories. MaxMind keys allow users to run queries against minFraud®, GeoIP®, and GeoLite services, and download GeoIP and GeoLite databases. GitHub will forward license keys found in public repositories to MaxMind, who will then email the user about the leaked key. You can read more information about MaxMind keys here.

All users can scan for and block MaxMind keys from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block MaxMind keys in their private repositories.

Learn more about secret scanning
Partner with GitHub on secret scanning

See more

Pinterest is now a GitHub secret scanning partner

GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, our scans help prevent data leaks and fraud.

We have partnered with Pinterest to scan for their API tokens and help secure our mutual users on public repositories. Pinterest tokens allow developers to interact with Pinterest's API in order to build experiences and apps for creators, advertisers, merchants and users on top of Pinterest. GitHub will forward access tokens found in public repositories to Pinterest, which will then notify the user about the leaked token. You can read more information about Pinterest tokens here.

All users can scan for and block Pinterest's tokens from entering their public repositories for free with push protection. GitHub Advanced Security customers can also scan for and block Pinterest tokens in their private repositories.

See more

Secret scanning supports validation checks for select AWS, Google, Microsoft, and Slack tokens

GitHub Advanced Security customers that have validity checks enabled will see the validation status for select AWS, Google, Microsoft, and Slack tokens on the alert.

The following tokens are supported:

  • aws_access_key_id
  • aws_secret_access_key
  • aws_session_token
  • aws_temporary_access_key_id
  • aws_secret_access_key
  • google_oauth_access_token
  • google_api_key
  • nuget_api_key
  • slack_api_token

AWS tokens will have validation checks performed periodically in the background, with on-demand validity checks to come in the future.

View our supported secrets documentation to keep up to date as we expand validation support.

See more

GitHub Sponsors is now available in 35 new regions

GitHub Sponsors is now available in 35 new regions! You can now sign up for Sponsors if you have a bank account and tax residence in any of the following regions:

  • Albania
  • Antigua & Barbuda
  • Armenia
  • Bahrain
  • Bosnia & Herzegovina
  • Cambodia
  • Côte d’Ivoire
  • Ecuador
  • El Salvador
  • Ethiopia
  • Ghana
  • Guatemala
  • Guyana
  • Jamaica
  • Jordan
  • Kuwait
  • Macao SAR China
  • Madagascar
  • Malaysia
  • Mauritius
  • Moldova
  • Mongolia
  • Namibia
  • Nigeria
  • North Macedonia
  • Oman
  • Panama
  • Qatar
  • Rwanda
  • Senegal
  • Sri Lanka
  • St. Lucia
  • Tanzania
  • Uzbekistan and Vietnam

You can sponsor projects from wherever GitHub does business and join the Sponsors waitlist if we’re not yet in your region.

See more

Contributing to GitHub Docs

We’ve added a new category to the GitHub Docs, “Contributing to GitHub Docs”, filled with resources used by the GitHub Docs team, the rest of the company, and the open source community to create documentation. The articles in this category explain the processes behind producing documentation, how GitHub approaches docs, and how to write docs according to GitHub’s style and content guidelines. If you’ve ever wanted to know the processes behind producing documentation or you’re about to begin documenting your own project and want to base your processes on our approach, you can now find that information in GitHub Docs.

GitHub Docs is an open source project that everyone is welcome to contribute to. To contribute, head to our github/docs repository and browse the open issues with the “help wanted” label.

See more

GitHub Actions: Apple silicon (M1) macOS runners are now available in public beta!

Apple silicon (M1) hosted runners can now be used by any developer, team, or enterprise! You can try the new runners today by setting the runs-on: key to macos-latest-xlarge or macos-13-xlarge. The 12-core Intel macOS runner is still available as well and can be used by updating the runs-on: key to macos-latest-large, macos-12-large, or macos-13-large in your workflow file.

More information about using the M1 hosted runner can be found here.
To learn more about hosted runner per job minute pricing, check out the docs.

Join the Community Discussion to share thoughts and feedback.

GitHub

See more

Enhanced Accessibility for Links in Text Blocks Public Beta

To improve accessibility for our users, we've introduced a new accessibility setting to underline links within text blocks. Links should be easily distinguishable from surrounding text, not just by color but by styling. You can now toggle an accessibility setting to either "show" or "hide" underlines for links in text blocks, ensuring clear visibility and differentiation. You can learn more about this functionality in the documentation.

During this public beta phase, your feedback is invaluable. If you spot a link within a text block that isn’t underlined when the setting is enabled, please let us know.

Thank you for supporting our commitment to making GitHub more accessible for everyone!

See more

CodeQL code scanning deprecates ML-powered alerts

In February 2022, we introduced experimental CodeQL queries that utilize machine learning to identify more potential vulnerabilities. This feature was only available for JavaScript / TypeScript code and was available to code scanning users that enabled the optional security-extended or security-and-quality query suites.

We disabled this experimental feature for new code scanning users in June 2023. Today, we're sunsetting it for all users.

Any currently open code scanning alerts from these queries (Rule ID starts with js/ml-powered/) will be closed. Closed alerts will still be visible in the code scanning alerts view in your repository’s Security tab. The complete history of each alert will remain accessible by clicking on the alert.

CodeQL will continue to run the existing non-ML versions of these queries and provide you with highly precise and actionable alerts.

We’ve learned a lot from the feedback and experience of the repositories that participated in this experiment, and we’ve since ramped up our investment in AI-powered security technology. This new technology is already boosting our ability to cover more sources and sinks of untrusted data in order to significantly increase the coverage and depth of all queries.

See more

GitHub Issues & Projects – September 28th update

Today's changelog brings you improvements to project templates (public beta), including new templates pages and the ability to create a template with a single click!

🏠 Find projects templates from your organization's Projects page

You'll now find all project templates in the "Templates" section of your organization's Projects page. This allows you to quickly find, filter, and open all available templates right alongside your projects.

You can also create templates using New template, in addition to converting an existing project into a template by toggling Make template on the project's settings page.

Create, set up, and reuse templates to make getting started with new projects a breeze!

organization templates page

In order to find templates that are relevant to you and your teams, you can now link project templates and create them directly from your team and repository "Projects" pages. This allows you to link relevant templates for quick and easy access the same way that you can link or create projects from these locations.

✍️ Tell us what you think!

We’ve got more improvements planned for project templates but we want to hear from you, so be sure to drop a note in the discussion and let us know how we can improve! Check out the documentation for more details.

✨ Bug fixes and improvements

  • Improved the project collaborators suggestions to differentiate between teams and users
  • Fixed a bug where you could not download an empty project view with Export view data
  • Fixed a border contrast issue in the Workflows page

See how to use GitHub for project planning with GitHub Issues, check out what's on the roadmap, and learn more in the docs.

Questions or suggestions? Join the conversation in the community discussion.

See more

List of Dependabot Job Logs

You can now now see the list of recent jobs that Dependabot has run to check for updates and create or rebase pull requests directly from the repository-level dependency graph section of the insights tab. This list will show whether a job was successful, any error messages, and provide links to both the full logs for the job and any pull request affected by the job. This will give you more visibility into the Dependabot process and help you debug.

Screenshot of a list of details about recent Dependabot jobs for a repository

Learn more about troubleshooting Dependabot issues

See more

GitHub Advanced Security only consumes licenses for commits and pushes made after a repository is migrated to GitHub

GitHub Advanced Security now automatically only consumes licenses for commits and pushes made after a repository is migrated to GitHub, rather than considering all historic contributions from before the migration.

When a repository is migrated to GitHub, all historic commits are combined into a single push. This meant that when GitHub Advanced Security was enabled the repository would use licenses for all commits in that combined push, and so consume licenses for all historic commits. Previously this would be resolved manually, but this ship automates this work. GitHub Advanced Security now only uses licences for commits and pushes made after migration and does not consider legacy pushes that occurred in migrated repositories.

This has shipped to GitHub.com and will ship to GitHub Enterprise Server 3.12. Read more about billing for GitHub Advanced Security.

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

Authentication Metadata for Git Events – Public Beta

GitHub Enterprise and organization owners now have improved visibility into authentication activity via personal access token (classic), fine-grained personal access token (FGP), OAuth token, SSH key or deploy key. The audit log may now contain hashed renderings of the token or key used for authentication and the programmatic_access_type field describing the type of token/key used for authentication. Enterprise and organization owners can query by specific token or key to identify and track activity.

To learn more, read our documentation on identifying audit log events performed by an access token.

See more

Changes to token permission on packages

Announcing changes to permissions for packages.

We are restricting the refs REST API endpoint from accepting POSTs from users and apps that only have the permission to read and write packages. Previously, this endpoint accepted updates to both tags and branches.

If that ability is critical to your development flows you will now be required to add explicit contents permissions to create refs.

A small cohort of customers relying on this flow have been notified of these changes and will have additional time to remediate.

We appreciate your feedback in GitHub's public feedback discussions.

See more

More details provided when a pull request is merged indirectly or is still processing updates

To help users better understand the state of a pull request, we now provide more details in two specific cases.

Merged indirectly

If a pull request's commits are merged into the base branch by another pull request (or directly), the pull request is still marked as merged, but previously, it was not clear from the timeline that the pull request was merged this way. This could result in confusion if the pull request was still awaiting approvals or had failing status checks. Now, the timeline provides more details, including a link to the merged pull request that caused the pull request to be marked as merged.
image

Note: this message only appears when using rulesets.

Pushed commits are still being processed

If new commits are pushed to a pull request's branch and it takes longer than usual for them to be processed and appear in the commit list, an informational message is now presented at the top of the pull request page.
image

See more
View more changes