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 runs triggered from tags or forks with the same name as a protected branch will now be blocked

GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.

We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.

Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

Users can enable push protection for themselves

Secret scanning's push protection feature prevents supported secrets from being pushed into repositories, and has to date been enabled at the repository, organization, or enterprise level.

Now, everyone across GitHub can enable push protection for themselves within your individual settings. This ensures your pushes are protected whenever you push to a public repository on GitHub, without relying on that repository to have push protection enabled.

To opt in, go to the "Code security and analysis" section of your personal settings. Next to "Push protection for yourself", click Enable.

GitHub will enable push protection for all GitHub Free individuals by default in January, 2024.

See more

Sudo mode now applies to the administrator account for an Enterprise Managed User enterprise

The administrator account (ending in _admin) of Enterprise Managed User enterprises is now required to enter sudo mode before taking sensitive actions. As with standard user accounts, the administrator must provide their password or a second factor credential to enter sudo mode.

Sudo mode is a GitHub security feature that validates the user's session before they perform a sensitive action, like creating a personal access token, deleting an organization, or updating their credentials.

Until now this mode was disabled for all Enterprise Managed Users (EMUs), as they had no credentials on GitHub.com and therefore could not provide one for the sudo mode prompt. As a result, EMU accounts are able to take sensitive actions without being asked for a credential. However, the admin for the EMU enterprise does have credentials on GitHub.com and will now be asked for them before taking sensitive actions.

For more information about sudo mode, see "Sudo mode". To learn more about Enterprise Managed Users, see "About Enterprise Managed Users".

See more

The GitHub Enterprise Server 3.10 Release Candidate is available

The GitHub Enterprise Server 3.10 release candidate is here

GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:

  • Code Scanning configuration can be customized per repository, allowing repository owners to decide which languages to analyze by default.
  • Fine-grained personal access tokens (PATs) are now available as a public beta on Enterprise Server, giving developers and administrators granular control over the permissions and repository access granted to a PAT.
  • Assess security risk and coverage data across all organizations in an enterprise via the Code Security tab.
  • Define who can merge pull requests, and how they are merged, to make it easier for you to meet your compliance and security goals.
  • Reduce data transfer required to backup your Enterprise Server by utilizing incremental backups of MySQL data in backup-utils v3.10.0.
  • GitHub Projects is now generally available in Enterprise Server.

If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments. Here are some highlights for this release. Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.10 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.

See more

Removal of source IP addresses from API error messages related to IP allow lists

For security reasons, source IP addresses have been removed from error messages that are returned from the GitHub API when callers try to access protected resources from non-permitted IP addresses.

To learn more about IP allow lists, visit Restricting network traffic to your enterprise with an IP allow list in the GitHub documentation.

If you'd like to learn more about your source IP addresses, please contact GitHub Support.

See more

Improving the code scanning REST API `updated_at` field

The code scanning REST API updated_at field has been improved to help you review your most recently changed alerts.

The updated_at timestamp now returns the alert's most recent state change on the branch that you requested. We consider a state change to be a significant event, including an alert being introduced, fixed, dismissed, reopened or reintroduced. This is implemented in both the repo API and org API so it can be used consistently at scale.

Previously, the updated_at timestamp changed whenever an alert was found in an analysis or the alert state changed, and so was updated very regularly. This improvement lets you efficiently use updated_at to sort and focus on your most recently changed alerts.

The code scanning REST API list alerts endpoints code-scanning/alerts returns the value for the default branch, unless another branch is specificed. The alert endpoint code-scanning/alerts/{alert_number} reports at the alert level, so will return the maximum value for the alert across all branches.

This is now live on GitHub.com for the repository level API. This will be live for the organization level API over the next few days because it requires data reindexing. This will ship to GitHub Enterprise Server version 3.11. For more information, see the code scanning REST API documentation.

See more

Simplified post-migration identity mapping for Enterprise Managed Users

When you migrate to GitHub.com with GitHub Enterprise Importer, user activity (e.g. issues, pull requests, comments) is linked to placeholder identities called "mannequins".

After you've finished migrating, you can "reclaim" those mannequins, linking the migrated activity to users' GitHub.com accounts. As part of this process, users receive invitations, asking them to accept the mannequin attribution.

Now, organizations using Enterprise Managed Users (EMU) can reclaim mannequins immediately, skipping the invitation process. This can be done one-by-one, or in bulk using a CSV.

To use this new feature, you'll need to update to the new v1.0.0 version of the GitHub Enterprise Importer CLI, released today.

For more details, see "Reclaiming mannequins for GitHub Enterprise Importer" in the GitHub Docs.

See more

Copilot in GitHub Support (Alpha)

We are excited to announce the alpha release of Copilot in GitHub Support, a faster way to find answers to your GitHub related questions! Copilot in GitHub Support is an AI-powered assistant that answers questions based on our official GitHub Enterprise Cloud documentation.

Initially, we’re offering the Copilot experience to a limited number of randomly selected GitHub Enterprise Cloud customers. We hope to continue rolling out the experience to a wider audience over the coming months.

If your ticket is selected, you’ll be provided with an option to opt-in while creating your support ticket. During the alpha, GitHub will be reviewing answers provided and collecting feedback from participating customers to improve the accuracy.

Copilot in GitHub Support is part of our ongoing effort to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.

We look forward to hearing from you and learning from your feedback.

See more

[Private Beta] Jenkins Scripted Pipeline Migrations

Support for migrating Jenkins Scripted Pipelines to GitHub Actions is now available as a private beta! If you use Scripted Pipelines in your Jenkins instances, you can now automate the migration of your pipelines to GitHub Actions using GitHub Actions Importer.

To get started, please reach out to your GitHub account manager or contact our sales team! For questions and feedback about the private beta, please visit the GitHub Actions Importer community.

See more

Codespaces gives you a free upgrade

What would you do with twice the memory on your computer? How about 30% better CPU performance?

We’ve leveled you up!

Over the past six weeks we’ve upgraded underlying infrastructure for Codespaces, migrating from Intel to AMD based CPUs, which boast improved specs.

As of today, 4-core and higher Codespaces now include twice the RAM, and 30% better CPU performance, at no additional cost to you. You now get snappier performance and more room for your processes to stretch out without having to lift a finger. We’ll be rolling out the same upgrade for the 2-core Codespaces in a matter of days.

Save money

If you’re using an 8-core machine because you need the RAM, now you can save cost by backing that down to a 4-core machine so you get twice the bang for the buck. Same goes for scaling down from 4 to 2 cores, and so on. Because free usage of GitHub Codespaces is calculated by cores per hour, using a smaller machine will also give you more free coding hours.

Now your GitHub Codespaces cloud dev environment builds, tests, and shares your running application faster than ever, at the same price.

Note: this release does not affect the machines used in the generation of Codespaces prebuilds.

Give ‘em a spin! https://github.com/codespaces

See more

GitHub Actions: Required Workflows will move to Repository Rules

We will be moving the private beta of required workflows on GitHub Actions to Repository Rules to give organization administrators a powerful way to protect their repositories with added feature benefits including unified configuration, dry running workflow rules, branch targeting, and a consistent UI experience.

Starting September 20th, 2023, users can configure their workflows using rulesets in order to run and pass in selected repositories before merging their code. On October 18th, users will no longer be able to access Actions Required Workflows and must use rulesets in its place.

How does this impact beta users of Actions Required Workflows?

Existing Actions Required Workflows private beta users will continue to have access until October 18th, 2023, allowing them time to adapt to the forthcoming changes. During this transitional period, users will maintain their existing workflows without disruption. This ensures that organizations can smoothly navigate the migration process, avoiding any abrupt disruptions to their current code merging practices. Here’s a quick overview of the events leading up to the move.

For GHEC customers

Leading up to October 18th:

  • GitHub will attempt to automatically migrate any existing Required Workflows to Rulesets for customers.
  • Any workflow files that did not successfully migrate will need to be manually migrated by code owners.

After October 18th:

  • The ability to require a workflow to pass before merging code will only be available on GitHub Enterprise plans via Repository Rules
  • Organization Rulesets will enable administrators to define, configure, and manage all workflows required to pass before merging code in repositories.
  • The feature formally known as Actions Required Workflows will no longer be accessible and users will be directed to Rulesets.

For GHES customers by version

  • GHES 3.8 and 3.9 will not be impacted until their next upgrade
  • GHES 3.10 and 3.11 will not be impacted if Actions Required Workflows are already in use
  • GHES 3.12 Requiring a workflow to run and pass before merging will be only be available vis Repository Rulesets

To learn more about how Repository Rules can help control how people can interact with branches, visit our documentation.

See more

Deprecation Notice – Dependabot to Drop Support for Python 3.6 and 3.7

As of August 17, 2023, Dependabot will no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

View the official release cycle for Python for more information on supported versions.

See more

pnpm Support for Dependency Graph, Dependabot Alerts, and Dependabot Security Updates

pnpm is now fully supported by dependency graph, Dependabot alerts, and Dependabot security updates! If you manage your Node.js dependencies with the pnpm package manager, you can now receive and fix alerts about security vulnerabilities in those dependencies. To use this, enable Dependabot Security Updates from the repository settings page on the code security and analysis tab.

To read more about how to use Dependabot and dependency graph, you can read our documentation here

See more

New rate limit for the audit log API endpoints is active

In early July, GitHub announced a new rate limit was coming for the audit log API endpoints. Starting today, each audit log API endpoint will impose a rate limit of 1,750 queries per hour per user, IP address, enterprise, or organization. This is higher than the previously stated change to 15 queries per minute, in order to allow integrators more time to adjust workflows and scripts which programmatically query the audit log API. We intend to enforce a limit of 15 queries per minute on or after November 1st, 2023.

This rate limit will be enforced on each combination of an individual user, IP address and entity path (/orgs/<org_name>/audit_log or /enterprises/<enterprise_name>/audit_log) independently.

To adapt to these changes and avoid rate limiting, programs or integrations querying the audit log API should query at a maximum frequency of 1,750 queries per hour. Additionally, applications querying the audit log API should be updated to honor HTTP 403 and 429 responses to dynamically adjust to the back-pressure exerted by GitHub.

For additional information, please consult our documentation on handling rate limits for requests from personal accounts and rate limits for GitHub Apps. Alternatively, enterprises seeking access to near real-time data should consider streaming your enterprise audit log.

See more

Swift Support for Dependabot Updates

Dependabot can now open pull requests to update your Swift dependencies. In June, support for Swift advisories in the Advisory Database and Dependabot alerts was released. Dependabot will now be able to open pull requests to fix related alerts, and you will also be able to configure scheduled updates for your dependencies via dependabot.yml.

For more information on how to configure Dependabot updates, please view our documentation here: https://docs.github.com/en/code-security/dependabot

See more

2FA requirement status on the People pages

As part of the two-factor authentication requirement program on GitHub.com, the People pages of enterprises and organizations have been updated to include the 2FA requirement status of members and collaborators. As an administrator, you can see which of your users have not yet enabled 2FA but are required to do so because of an action they have take in one of your organizations, or elsewhere on GitHub.com.

A clock icon will appear as a user's 2FA status will show if the user is required to enable 2FA. When the icon is red, they are past the due date for enabling 2FA, and are at risk of being blocked from accessing GitHub.com until they enable it. Clicking the clock icon will display the user's enrollment date.
256704235-eb7cb75d-2806-4aa6-aa44-aa9148bfb828

You can filter the UI to show only users who have a pending requirement. Enrollment dates are also now included in the CSV and JSON downloads of enterprise and organization memberships.

To learn more about the 2fa enrollment program, see our blog post with more details. For information about viewing your members, see the organization and enterprise documentation.

See more

Secret scanning shows metrics for push protection at the organization level

Organization owners and security managers can now view metrics associated with push protection usage across their organization.

The overview shows a summary of how many pushes containing secrets have been successfully blocked across the organization by push protection, as well as how many times push protection was bypassed.

You can also find more granular metrics, including:

  • the secret types that have been blocked or bypassed the most
  • the repositories that have had the most pushes blocked
  • the repositories that are bypassing push protection the most
  • the percentage distribution of reasons that users give when they bypass the protection

These metrics are found under the Security tab of your organization and are based on activity from the last 30 days.

screenshot of push protection metrics, showing overall secrets blocked and details on most blocked types, repositories with most pushes blocked, and bypassed secret metrics

See more

Code scanning default setup is now available for Swift

Code scanning default setup is now available for Swift analysis with CodeQL! Default setup now supports all CodeQL supported languages at the repository level. This includes JavaScript/TypeScript, Ruby, Python, Go, Java, Kotlin, C/C++, C#, and Swift. We're working to support enabling code scanning at the organization level for all CodeQL languages soon.

Default setup automatically detects the languages used in a repository, and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. You can also optionally customize the configuration to analyze Java/Kotlin, C/C++, C# and Swift. The configuration can be viewed and edited at any time, during or after set up. You can also use the REST API to include languages in the default setup configuration.

Java, Kotlin, C/C++, C# and Swift are not automatically included in the default setup configuration because they often require more advanced configuration. Code written in these languages needs to be compiled in order for CodeQL analysis to proceed. CodeQL will attempt to build your code automatically but may fail if your code requires bespoke build steps.

If a language fails in default setup, you will see an error message on the repository's settings page, in the code security and analysis section. To resolve the situation you can:

  1. Deselect the language from the configuration and continue to use default setup for the successful languages.
  2. Convert to advanced setup. The advanced setup uses a yml file and allows you to provide the build information required for the CodeQL analysis to succeed.
  3. Debug and fix the cause of the language failure. The Actions log will provide the failure reason so you can resolve this for a successful analysis.

For more information, see the documentation for when a particular language is causing default setup to fail. For more information on code scanning default setup, see Configuring code scanning automatically.

See more
View more changes