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

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

Previously, developers who used private registries to host their packages on internal networks could not use Dependabot to update the versions of those packages in their code.

With this change, users can choose to run Dependabot pull request jobs on their private networks with self-hosted GitHub Actions runners, allowing Dependabot to access on-premises private registries and update those packages.

A prerequisite for enabling self-hosted runners includes enabling GitHub Actions for the repositories of interest. It’s important to note that running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

To get started, check out our documentation on managing self-hosted runners with Dependabot Updates.

If you’re interested in learning more about what it means to run Dependabot as a GitHub Actions workflow, check out our changelog and FAQ or Dependabot on Actions documentation.

See more

Create a tamper-proof papertrail for anything you build on Actions

Artifact Attestations lets you sign builds in GitHub Actions, capturing provenance information about the artifact and making it verifiable from anywhere. There are no keys or PKI to manage, and verification happens with the GitHub CLI tool. The solution is based on Sigstore, an open source project that simplifies signing for software artifacts.

To add provenance to a GitHub Actions workflow, you just need to invoke the new attest-build-provenance Action with the path to an artifact. Here’s a simple example:

permissions:
  id-token: write
  contents: read
  attestations: write

#
# (build your artifact)
#

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'

Then verify it with the CLI tool:

gh attestation verify PATH/TO/ARTIFACT -o myorganization

To learn more check out the blog and join the discussion in the GitHub Community.

See more

Developers of GitHub Apps can simplify their application by using the client ID for both OAuth flows and the installation token flow.

To date, GitHub Apps have had two different IDs to manage – the application ID and the client ID. The application ID was only used to mint a JWT, subsequently used to fetch an installation token. The client ID is used with the OAuth flow to sign in users and request installations. These two values equally identify the application and the question of which one to use where caused unnecessary developer friction. You can now use the client ID in the place of the application ID when minting JWTs.

The application ID is not being deprecated at this time, nor are their plans to remove it. However, compatibility with future features will rely on use of the client ID, so updating is recommended.

The specific change allowed here is that when minting the JWT that proves your app is in posession of an application’s private key, you can use the client ID for the iss claim. Note that application IDs are ints, while client IDs are strings, if using a typed language.

require 'openssl'
require 'jwt'  # https://rubygems.org/gems/jwt

# Private key contents
private_pem = File.read("YOUR_PATH_TO_PEM")
private_key = OpenSSL::PKey::RSA.new(private_pem)

# Generate the JWT
 payload = {
 # issued at time, 60 seconds in the past to allow for clock drift
  iat: Time.now.to_i - 60,
  # JWT expiration time (10 minute maximum)
  exp: Time.now.to_i + (10 * 60),
--- # GitHub App's App ID
--- iss: "12345"
+++ # GitHub App's Client ID
+++ iss: "Iv23f8doAlphaNumer1c"
}

jwt = JWT.encode(payload, private_key, "RS256")
puts jwt

Note that Octokit still expects the use of the App ID in its setup – the Octokit SDK will be updated in the future to support use of the client ID.

You can find the client ID for your application in its settings page:

A screenshot of an app's settings, showing both the client ID and the application ID

Client IDs and application IDs are not secrets, and are expected to be visible to the end user – you do not need to change how you handle your IDs when making this update.

For more information about minting JWTs to get an installation token, see ‘Generating a JWT for a GitHub App’.

See more

GitHub’s audit log streaming health check is now generally available! The purpose of the audit log health check is to ensure audit log streams do not fail silently. Every 24 hours, a health check runs for each stream. If a stream is set up incorrectly, an email will be sent to the enterprise owners as notification that their audit log stream is not properly configured.

Example email notification for misconfigured stream

Streamed audit logs are stored for up to seven days on GitHub.com. To avoid audit log events being dropped from the stream, a misconfigured stream must be fixed within six days of email notification. To fix your streaming configuration, follow the steps outlined in “Setting up audit log streaming.”

See more

npm feedback is now available on GitHub Community. Previously feedback for npm took place on the npm feedback channel, which is going to be sunset as we migrate unresolved discussions.

External users should utilize the new npm category on GitHub Community to make suggestions to any part of npm, the cli, the registry, and the website. Users can vote and rank topics to voice their opinions and give support to existing items.

Please join us on GitHub Community to share your feedback on npm!

See more

GitHub Enterprise owners may notice that we removed the Enterprise Help links from your enterprise licensing page `https://github.com/enterprises//enterprise_licensing`, which were previously found here:

These shortcuts can still be found elsewhere:

  • GitHub Enterprise documentation is referenced underneath the README on the Enterprise Overview page `https://github.com/enterprises/`;
  • GitHub Support is discoverable both on the Enterprise Overview page as well as the Support page under settings `https://github.com/enterprises//settings/support`; and
  • GitHub Enterprise Server Support bundles can be uploaded from the Setup > Support Site Admin page as well as the GitHub Enterprise Cloud Support page under settings.
See more

For GitHub Advanced Security customers that use secret scanning, you can now specify which teams or roles have the ability to bypass push protection. This feature is in public beta on GitHub Enterprise Cloud.

screenshot of the bypass list in settings

This is managed through a new bypass list, where organizations can select which teams or roles are authorized to bypass push protection and act as reviewers for bypass requests. If an individual not included in this list needs to push a commit that is initially blocked, they must submit a bypass request. This request is then reviewed by an authorized individual who can either approve or deny it, determining whether the commit can proceed into the repository.

Please note, this feature is not yet compatible with web UI pushes.

See more

We recently shipped several changes to improve the Actions user experience. These changes include adding backscroll to the Actions streaming logs and workflow pinning.

Actions streaming logs with backscroll is now generally available. Previously, an Actions job that was actively running would only stream the logs generated after the page was loaded. Logs emitted prior to the page loading would only be available after the job completed. This made it challenging to monitor the progress of jobs as they were running, particularly those that could take a long time to complete. Customers will now be able to visit the logs of a running job and immediately get the previous 1,000 log lines emitted. This will give you immediate context into the run’s progress and status.

We have also made it easier to navigate within the Actions tab. Customers can now pin Actions workflows to the top of the list (a maximum of 5 pinned workflows per repository) to make them easily accessible. When a workflow is pinned, it is visible to everyone with access to that repository. Any collaborator with write access will be able to pin or unpin workflows. In addition, all workflows, including required workflows, will be displayed in a single list. Disabled workflows will be sorted to the bottom of the list and will display a disabled label.

If you have any feedback you wish to share about these changes, please reach out in the GitHub Community Discussion.

See more

GitHub Copilot Enterprise banner

Another month means more exciting updates to GitHub Copilot Enterprise! 📆 Check out what’s new below:

  • Ask Copilot Chat in GitHub.com to summarize and answer questions about specific issues: Copilot can read an issue and answer questions based on its title, author, status, body, linked pull requests, comments, and timestamps. To learn more, see “Asking a question about a specific issue” in the GitHub Docs.
    • Try it yourself: Navigate to an issue on GitHub.com, and ask Copilot to Summarize this issue
  • Stop Copilot Chat in GitHub.com mid-response with the “Stop” button: If your question wasn’t quite right, you’ve already got your answer, or Copilot isn’t heading in the right direction, you can now stop Copilot mid-response with the “Stop” button, like you can in your IDE.

Got feedback on any of these updates or Copilot Enterprise more generally? Join the discussion within GitHub Community.

See more

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

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

This public beta enables developers to use a directories key to list multiple directories for the same ecosystem configuration in the dependabot.yml file.

Previously, developers with multiple package manifests for the same ecosystem (e.g. npm, pip, gradle) across multiple directories had to create separate dependabot.yml configurations for each of those directories. This could lead to many duplicated configurations, and high maintenance costs if a developer wished to make a change that spanned multiple directories.

A new dependabot.yml key, directories, is now available in public beta. The directories key accepts a list of strings representing directories, and can be used instead of directory.

Below is an example dependabot.yml multi-directory configuration setup, including how you can use the directories key:

version: 2
updates:
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"

This example configuration applies to both security and version updates.

Wildcards and globbing support (i.e. using * to represent a pattern of directories) is coming soon in our next public beta releases, with an expected public beta launch within the next few months. Stay tuned for more!

If a developer still wishes to explicitly enumerate configurations for the same ecosystem using directory, they can still choose to do so; the directory key still accepts single-directory entries. For more information on the directory key, check out the dependabot.yml configuration options for the directory key documentation.

See more

To enhance accessibility for our users, we have introduced a new accessibility setting that allows the underlining of links within text. It is important that links are clearly distinguishable from the surrounding text, which is achieved not only through color but also through additional styling.

For more information on this feature, please visit our documentation. Thank you for all your valuable feedback during the beta phase.

See more

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.1 has been released and has now been rolled out to code scanning users on GitHub.com.

CodeQL code scanning now supports automatic fix suggestions for C# alerts on pull requests, powered by Copilot. This is automatically enabled for all private repositories for all GitHub Advanced Security customers. For the first time, autofix covers nearly all security queries for a language, with 49 supported queries for C# from our Default and Extended suites. Use our public discussion for questions and feedback.

Also included in this release:

For a full list of changes, please refer to the complete changelog for version 2.17.1. All new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

See more

For enterprise owners and security managers dedicated to managing security products, we are excited to announce a new capability: you can now gain historical insights into security products enablement trends across your GitHub enterprise. This overview helps you understand how security product coverage is being implemented across your company.

Following our March announcement of the public beta of the enablement trends report for organizations, which allowed monitoring of enablement trends for all security products within your GitHub organization, we’ve expanded this capability to the enterprise level. The addition of an owner filter further simplifies the navigation of metrics for repositories owned by specific organizations.

Enterprise enablement trends report

Explore enablement trends and gain historical insights into the activation status of GitHub security features:
* Dependabot alerts
* Dependabot security updates
* Code scanning
* Secret scanning alerts
* Secret scanning push protection

Historical data is available from January 1, 2024, with the exception of Dependabot security updates data, which is available from January 17, 2024.

To access the enablement trends report, navigate to your enterprise account. In the enterprise account sidebar, click Code Security.

This feature is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and join the discussion within the GitHub Community

See more

The new deployment views across environments are now generally available (GA)! 🎉

Previously we have shipped dashboard views to track your deployments using GitHub Actions across various environments.
These views have enabled Developers and DevOps managers to view the full history of deployments in a repository or filter them across environments & workflows to understand their status, duration or address any blockers.

We are now announcing GA for these Deployment Dashboard views along with the following enhancements:

  • Pinning of environments. Ex: You can now “pin” up to 10 of your most critical environments to provide a quick way to view all the deployments rolled out to them.
  • More filters on the views. Ex: You can now drill down to the list of deployments triggered by specific creators with specific deployment statuses and targeting specific environments.

New Deployment views

Learn more about viewing and filtering deployments in your repository through our documentation.

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

See more

Today’s changelog brings you a new workflow to auto-close issues in Projects!

🪄 Auto-close issue project workflow

The auto-close issue workflow allows you to automatically close issues when their project status is changed to “Done” ✅ or any custom status you define (🙅 say goodbye to repetitive clicks).

Implementing the new workflow

For existing projects anyone with write or admin access can enable the new auto-close issue workflow on the workflows page.

For new projects the auto-close issue workflow will be enabled by default.

✍️ Tell us what you think!

Join the conversation in the community discussion to share your feedback.

Bug fixes and improvements

  • Enterprise Managed Users can now use public project templates and copy public projects.
  • Changed the behavior to apply a secondary sort field from the view configuration menu and also the table column menu.

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

See more

We’re excited to announce the public beta of the GitHub Copilot Metrics API, available to all customers of GitHub Copilot Business and GitHub Copilot Enterprise starting today.

The GitHub Copilot Metrics API is designed to supply you with information about Copilot’s usage within your organizations. The data from the API is intended to be consumed and combined with your organization’s own data to create greater visibility into how Copilot fits into the bigger picture of your software development cycle.

What functionality will be included in the Public Beta?

  • Historical data will be automatically loaded, giving you the ability to overlay data with any previous sources from day one.
  • The endpoint will supply data for the previous 28 days of usage history, on a rolling basis.

  • Data is summarized by day, and is refreshed at day end.

  • Date ranges and pagination are now available.

  • This iteration of the GitHub Copilot Metrics API is focused on serving metrics for Copilot Chat and code completions that take place in the IDE.

  • Code completion metrics: Lines of Code Suggested, Lines of Code Accepted, Number of Suggestions, Number of Acceptances, and Active Users with slices on language, and IDE.

  • Copilot Chat metrics: Number of Chats, Chat Suggestions Accepted, and Active Users. The endpoint does not currently feature slices on language or IDE for Chat metrics.

  • Team-level aggregates for GitHub teams with five or more members are also available.

Documentation and Resources

To help you get started, we have prepared comprehensive documentation and resources:

  • API Documentation: Explore the detailed API documentation, including metrics definitions here.
  • Visualization: You can find an open source tool for consuming and visualizing data from the endpoint here.

  • Metrics Export: Generate a flattened CSV from the endpoint using GitHub Actions here.

  • Learning Pathway: You can find an extended article on measuring the impact of GitHub Copilot here.

Participate in the Public Beta!

Your feedback during this beta phase is invaluable to us. We encourage you to share your experiences, which will be instrumental in refining and enhancing the API as we look toward the future.

Stay tuned for updates and enhancements throughout the beta period. We’re committed to delivering a robust and feature-rich API that meets your needs and expectations.**

See more