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

You can now create new repositories with pre-filled form fields, making it even easier to define the right info for your new repos from the start.
There are a number of query string parameters available, including:

  • name
  • description
  • visibility
  • owner
  • template_name
  • template_owner

To get started you can craft a query string at the end of https://github.com/new starting with ? followed by the fields and their values.

See the example below for more details:

https://github.com/new?owner=octocat&name=new-boilerplate&description=A%20new%20boilerplate%20repository&visibility=private&template_owner=actions&template_name=boilerplate

Learn more about Creating a new repository

We appreciate your feedback in GitHub's public feedback discussions

See more

XL macOS runners can now be used by any developer, without the need to sign-up! You can try the new runners today by setting the runs-on: key to macos-latest-xl, macos-12-xl, or macos-13-xl in your workflow file. The runners are available today to all customers!

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

See more

The macOS 13 (Ventura) beta runner image is now available for GitHub-hosted macOS runners. You can try it today by setting the runs-on: key to macos-13 or macos-13-xl in your workflow file. The full list of software available for macOS 13 can be found here. If you see any issues with your workflows when using macOS 13, please create an issue in the runner-images repository.

More information about the runner can be found in our docs. To learn more about pricing, click here.

See more

Codespaces has a number of new features to get you coding fast, from anywhere on the web, with a single click. Let's jump right in!

You can now add recommended secrets to a project when creating a Codespace!
Screenshot 2023-04-21 at 9 08 25 AM

Recommending secrets will ensure developers won't miss any API keys when creating a Codespace from your repo. You can specify any secrets you need to run your project in a Dev Container. If a developer already has a secret stored in their user secrets, Codespaces recommends they add the secret to their repository. Developers can worry less about setup and jump right into development!

Do you want to share your project for others to try out? You can generate a share link to share in a tweet, add to your website, or send to a friend.
Screenshot 2023-04-21 at 9 09 24 AM

Want developers to pick up on the last Codespace they had when they clicked your share link? You can set your share links to drop developers into the same Codespace every time by selecting "Quick start."

You can select a specific Dev Container for the share link to create a codespace from! Codespaces detects the repo and branch from your repository, limiting your setup.
Screenshot 2023-04-24 at 10 45 11 AM

We've even made it easier to embed the share link into a nice "Codespaces" badge with HTML and Markdown. Nifty!

If your users have never created a codespace from your share link, they are recommended to create a codespace. If users already have a codespace from your share link, they are be prompted to resume their codespace.

Would a Dev Container by any other name smell as sweet?

You can now name your Dev Containers! By defining the property name in your devcontainer.json, you can set the name that will appear under the Dev Container selection on the Codespaces creation page. Even if you don't define the name property in your devcontainer.json, Codespaces will still infer a more useful name from your Dev Container file path.
Screenshot 2023-04-21 at 9 13 48 AM

Jumping Into Development From A Repository With A Comma

Do you want to collaborate on a repository, PR, or Branch? You can jump right back into your Codespace with the ',' key. No need to go to github.com/codespaces, or go to your Code<> drop-down to jump into development. Just one button and you're back to developing!

Learn More

Check out the docs:

Want to leave feedback? Make a post on our discussions page

Thank you!

See more

When editing a file on github.com, repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now default to creating a new branch instead for directly committing. You can still commit directly to a protected branch, but doing so will add notifications in-line highlighting that some rules will be bypassed.

Historically the default behavior was to push through any branch protections with no notifications they were being bypassed.

Now we recommend creating a branch for admins eligible to bypass branch protection rules. This behavior occurs when adding new files to a repository as well as during pull requests.

Screenshot of commiting directly to a repository
Screenshot of bypassing rules in a PR>

We appreciate your feedback in GitHub's public feedback discussions

See more

For GitHub Enterprise Cloud customers, team sync no longer invites members to organizations by default. For existing team sync customers we have added a configuration option to disable automatic organization provisioning for users that are synced from your identity provider groups. Team sync will not remove users from an organization when they are removed from a team.

For additional information and instructions to opt out of the default behavior, learn more in our team sync documentation.

See more

GitHub today announced public beta support for custom deployment protection rules for safely rolling out deployments using GitHub Actions.

Custom deployment protection rules are powered by GitHub Apps and can be enabled on any GitHub org/repo/environment to allow external systems to approve or reject deployments.
Each rule evaluates specific conditions in those external systems to assess the readiness of the environments for automated deployments, making them less risky and more robust.

Starting with this public beta, GitHub Enterprise Cloud (GHEC) users can create their own protection rules to control deployment workflows and, if desired, share them by publishing their apps to the GitHub Marketplace.
You could also install official apps for deployment protection rules from various external partners to define security, compliance and governance related conditions in their services that can be used to control deployments with Actions workflows.

Two custom deployment protection rules enabled on a production environment

Learn more about creating and configuring custom deployment protection rules to set up rigorous, streamlined guardrails for your deployments that ensure only the deployments that have passed all quality, security, and manual approval requirements make it to production.

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

See more

As we work towards general availability of pull request merge queue, we want to thank everyone that has provided feedback (keep it coming!) and let you know about some recent fixes and new API support.

See the public beta announcement to learn more about merge queue and how it can help increase velocity by automating pull request merges into your busiest branches.

🆕 API support

You can now interact with merge queue programmatically using new GraphQL APIs. Add or remove a pull request from the queue, see which pull requests are queued, get details about a queued pull request, and more. For example:

Call the enqueuePullRequest mutation to add a pull request to the queue or dequeuePullRequest to remove a pull request.

Use the mergeQueue field on Repository to list its contents or configuration. Use the mergeQueueEntry field on PullRequest to get details about a queued pull request including its state, position in the queue, estimated time to merge, and more.

🐛 Fixes

Some of the more noteworthy fixes made since the public beta launch:

  • Fixed: GitHub Actions workflows would not trigger on merge_group events in some repos
  • Fixed: failing queued pull request would remain failing even after checks were rerun and and passed
  • Fixed: confusing “pushed a commit that referenced this pull request” message would appear in the timeline
  • Fixed: commits could be pushed to queue-created prep branches (note: these commits were ignored and not merged, but it created confusion for some users)

Get started

Interested in merge queue? Learn how to get started.

Questions or suggestions? Join the conversation in the merge queue public beta discussion.

See more

npm packages built on a cloud CI/CD system (like GitHub Actions) can now publish with provenance, meaning the package has verifiable links back to its source code and build instructions.

The cloud CI/CD system securely communicates this information by sending provenance information in a signed OIDC JWT to Sigstore's public-good servers, which returns a signing certificate that is sent to the registry along with your built package.

Here's an example of how to do a build with provenance in a GitHub Actions workflow:

name: Publish Package to npmjs
on:
 release:
   types: [created]
jobs:
 build:
   runs-on: ubuntu-latest
   permissions:
     contents: read
     id-token: write
   steps:
     - uses: actions/checkout@v3
     - uses: actions/setup-node@v3
       with:
         node-version: '18.x'
         registry-url: 'https://registry.npmjs.org'
     - run: npm install -g npm
     - run: npm ci
     - run: npm publish --provenance --access public
       env:
         NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Once published, packages display provenance on the registry website:

Provenance displayed on the registry website

Dependencies with provenance can also be verified from the command line with npm audit signatures.

For more information, see generating provenance.

See more

On March 30, 2023, we fixed a bug that allowed a dependency graph hovercard URL to be used to retrieve the name, description, and star count of any repository on GitHub.com. The bug was introduced on March 28, 2023 and our investigation has found no evidence of exploitation. To exploit the bug, a specific header needed to be set when making a request to the URL and the numeric ID of a repository provided. The URL would then return the HTML content designed to be used for a hovercard UI element with the repository name, description, and star count in the response.

This bug was reported to GitHub via the GitHub Bug Bounty program.

See more

Since the introduction of Category Sections to organize content in our own community, users have asked for similar features to organize their own Discussions. Today, we're introducing the ability for all maintainers to group their Discussion categories into sections. We think this will help users better organize content, and also find new content more easily.
Screenshot 2023-04-17 at 8 28 12 AM

The UI for this feature looks similar to the one in our own community, but users will now see a new UI when they edit a category. Users can not only create a new Category, but they can also create a new section from the "Manage Discussion Categories" page.
Screenshot 2023-04-17 at 8 30 22 AM

Editing a single category now also gives the user the option of adding it to an existing section.
Screenshot 2023-04-17 at 8 31 41 AM

For questions or feedback, please visit our community.

See more

Available in public beta today, the security coverage page now includes multi-repository enablement, which lets you enable or disable security features across several repositories at once. This feature improves upon the "enable all" feature that only allows you to enable one security feature at a time for all repositories within the organization.

Multi-repository enablement also allows you to filter repositories based on attributes such as team or repository topic, and to enable or disable security features for only those repositories in just a few clicks.

multi-repository enablement panel on security coverage page

The following security features can be enabled/disabled using multi-repository enablement:

  • Dependency graph
  • Dependabot alerts
  • Dependabot security updates
  • GitHub Advanced Security
  • Code scanning default setup
  • Secret scanning
  • Push protection

These improvements have shipped as a public beta to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about multi-repository enablement and send us your feedback

Learn more about GitHub Advanced Security

See more

Today we are announcing the public beta of repository rules! 🎉

Repository rules are GitHub’s next evolution of branch protections to help make your repositories more secure and compliant at scale.

Screenshot of ruleset overview

Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.

Creating rules

Screenshot of creating a ruleset

At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.

The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.

When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be merged, while disabled rulesets are not enforced; they will not prevent merges but allow admins to craft rules before enforcing them. Enterprise Cloud customers can also evaluate rulesets: a “dry run” mode for understanding the impact of new rules before they are active and enforced.

It’s also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.

Viewing the rules

You can always know what rules are in place for a repository.

Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.

From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.

Screenshot of read only view of rules

Getting Started

Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.

We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.

See more

When we introduced GitHub Discussions in 2020, we allowed users to mark an answer to a question in the "Q&A" Discussions category. As the feature began getting more usage, we noticed that often, the real answer to a question may live in a reply to an answer. Today, we are introducing the ability for users to mark a threaded reply as the answer to a question.

All replies will now have a button to allow the questioner to mark them as the answer.
Screenshot 2023-04-05 at 3 11 51 PM

Marking the reply as the answer highlights it and makes it clear to the reader where the real answer to the original question lives.
Screenshot 2023-04-05 at 3 12 33 PM

This feature improves the accuracy of marked answers, while also reducing the burden on users to duplicate their text to get their answer marked as correct.

For questions or feedback, please visit our community.

See more

GitHub Importer allows you to import repositories from other code hosting platforms to GitHub.com using a UI or REST API.

Today, GitHub Importer supports Git, Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories.

From April 12, 2024, we will no longer support importing Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories. We’re ending support for this functionality due to extremely low levels of usage.

Even without GitHub Importer, moving from these alternative version control systems to Git is simple thanks to fantastic open source tools – for more details, read our Docs article, “Using the command line to import source code”.

EDIT: The original end of support date in this post was October 17, 2023. We delayed this change in order to give customers more time to adapt.

 

See more

When changes in a repository make a Dependabot pull request out-of-date, Dependabot will automatically rebase it so that it is able to be merged without your manual effort. With this release, if a PR has not been merged for 30 days, Dependabot will stop rebasing it and will include a note about this in the PR body. You will still be able to manually rebase and merge the pull request. We've heard your feedback about Dependabot noisiness and are making Dependabot quieter and more focused on repositories you care about. For enterprise customers, this improvement has the added benefit of enhanced efficiency with your self-hosted GitHub Actions runners. For Enterprise Server customers, this update will be available to you in GHES 3.10.

See more

You can now filter by repository topic or team on the enterprise-level Dependabot, code scanning, and secret scanning pages in security overview.

Code scanning enterprise-level page filtered by repository topic and showcasing the team drop-down

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.9.

Learn more security overview and send us your feedback

Learn more about GitHub Advanced Security

See more

You can now fetch release notes, changelogs and commit history for Docker update pull requests with Dependabot. This will allow you to quickly evaluate the stability risk of the dependency upgrade. To enable support, add the org.opencontainers.image.source label to the Dockerfile with the URL of the source repository. Additionally, the repository should be tagged with the same tags as the published Docker images. This allows Dependabot to understand which repo and commit is associated each version/tag of a Docker image. Here's an example repository demonstrating this setup.

Did you know? Dependabot's internal library for identifying dependency updates is open source. If you notice a Dependabot pull request is missing metadata, you can leverage the transparency of open source to debug the root cause – for example, if the package maintainer needs to fix their metadata annotation.

See more