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

Repositories in the user namespace of enterprise-managed users (EMU) can now be seen and accessed by enterprise administrators. All repositories in the user namespace (e.g. https://github.com/mona_tenantName/scratch) can now be navigated to from the Repositories enterprise policies page: https://github.com/enterprises/<enterprise>/settings/member_privileges. From this new view, administrators can temporarily grant themselves administrative rights to these repositories. This action will trigger alerts to the repository owner as well as audit log events.

This public beta feature set is intended to increase visibility of namespace repositories to administrators while also empowering administrators to audit these repositories as needed.

To learn more, check out our documentation about viewing user-owned repositories in your enterprise and accessing user-owned repositories in your enterprise.

See more

Node12 has been out of support since April 2022. As a result we have started the deprecation process of Node12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023.
Following on from our warning in workflows using Node12 we will start enforcing the use of Node16 rather than Node12 on the 14th of June.

To opt out of this and continue using Node12 while it is still available in the runner, you can choose to set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true
as an 'env' in their workflow or as an environment variable on your runner machine. This will only work until we upgrade the runner removing Node12 later in the summer.

What you need to do

For Actions maintainers: Update your actions to run on Node16 instead of Node12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node16 (Using versions for Actions)

See more

Enterprise administrators can now disable repository level self-hosted runners across organizations and enterprise user namespaces.

Once this new setting has been enabled users will no longer be able to register new self-hosted runners in a repository and existing runners will not be able to receive new jobs.

Learn more about Disabling or limiting GitHub Actions for your organization

See more

If you manage your node.js dependencies with the pnpm package manager, you can now use Dependabot to keep those dependencies updated with automatic pull requests. You can easily configure this feature by adding or updating your dependabot.yml file in your repository. At this time, Dependabot will not open security alerts against pnpm dependencies.

See more

All eligible GitHub Enterprise accounts can now try GitHub Advanced Security for free for 14 days. GitHub Advanced Security provides integrated security with unparalleled access to curated security intelligence. This unlocks your ability to keep your code, supply chain, and secrets secure before pushing the code to production. During the trial, you can try features such as:

  • Code scanning to help find and remediate security issues in your code
  • Secret scanning to prevent and detect secret exposures across your organization
  • Dependency review to catch vulnerable dependencies before introducing them to your environment

Explore our documentation to learn more about GitHub Advanced Security features and how to deploy them in your organization.
GitHub Advanced Security on Enterprise Cloud

See more

Today, we're launching a new brand new tool for migrating from other code hosting platforms to GitHub and between GitHub products: GitHub Enterprise Importer (GEI).

With GitHub Enterprise Importer, you can migrate to GitHub.com or GitHub Enterprise Cloud and bring your source code and collaboration history (for example code reviews and comments) with you.

We’re publicly launching GitHub Enterprise Importer today — but already, it has been used by over 2,000 customers to migrate more than 400,000 repositories to GitHub Enterprise Cloud.

Today, we support the following migrations paths:

  • Azure DevOps to GitHub.com
  • GitHub Enterprise Server to GitHub.com
  • Moving your existing GitHub.com repos to an enterprise with Enterprise Managed Users enabled

Next up, we'll be launching support for migrations from Bitbucket Server and Bitbucket Data Center. If you're interested, you can sign up for our private beta here.

To learn more, head over to "Using GitHub Enterprise Importer" in the docs and check out our blog post.

See more

GitHub Codespaces plans to begin rolling out improved access controls for organizations on June 27th, 2023. These changes will provide organizations additional control over which of their organization’s members or outside collaborators are allowed to use GitHub Codespaces on private and internal repositories. This change will not affect public repository usage.

Today, any user with read access to an org-owned private or internal repository can create a codespace from that repository. The organization may elect not to pay for this Codespace usage, but currently there is no way to block the usage entirely. Starting June 27th, GitHub Codespaces will begin introducing additional Access, Billing, and Ownership settings to more granularly control this behavior. With these new settings, organization admins can decide who within the organization is allowed to create codespaces from private and internal organization-owned repositories, and who owns those created Codespaces:

Some codespace usage may be impacted by this change. Organization owners will receive an email if anyone in their organization has a codespace that will be deleted because it was created from a private or internal repository by an org member or collaborator who will not have the appropriate permissions after this change.

Will I be impacted by this change?

This change will impact organizations that have configured their organization’s billing settings to either “Selected members” or “All members”. If your organization has specified one of those options, members or outside collaborators who are not specified in the list of selected users will lose access to GitHub Codespaces created from impacted internal or private repositories.

Administrators will receive a separate email if anyone in their organization has a codespace that matches these criteria.

What should I do if I am impacted?

Organization administrators should review the list of specific users who are currently allowed to bill codespaces usage to their organization to ensure all members who should have access, continue to have access. This can be done by adding them to the existing billing setting before your organization migrates to the new access setting.

Adding new users to this list will automatically transfer codespace ownership to the organization for any existing, personally owned codespaces created by these users on organization owned repositories. Once this happens, these codespaces will no longer be impacted by this change. Before doing this, ensure your spending limit is properly configured.

Users with impacted codespaces should either push any unsaved changes from these codespaces, or export their changes to a new branch. This will ensure that no code is lost as part of this change.

What will happen to existing codespaces impacted by this change?

Codespaces impacted by this change will become inaccessible when the updates are released, and will be permanently deleted 7 days after that.

Details about the change

Today, any organization member or outside collaborator with read access to a repository can create a codespace on that repository. While the organization may elect not to pay for this usage, the member or outside collaborator can still pay for their own usage.

This release will introduce two control mechanisms for access and ownership.

Access will control which users are allowed to create codespaces on private and internal repositories within your organization. There will be four options:

  • Disabled: Codespaces are not enabled within the organization’s private and internal repositories.
  • Specific members: The organization can select specific members who are allowed to create codespaces on the organization’s private and internal repositories.
  • All members: Any full member of the organization is allowed to create codespaces on the organization’s private and internal repositories.
  • All members and outside collaborators: Anyone associated with your organization (full member or outside collaborator) is allowed to create codespaces on the organization’s private and internal repositories.

Ownership and Billing controls who pays for codespace usage, who receives the audit log events from codespace usage, and whose policies are applied to the codespaces. There will be two options:

  • Organization owned: All codespaces created by organization members for organization-owned repositories will be owned by the organization, send events to the organization’s audit log, and apply the organization’s codespace policies.
  • User owned: All codespaces created by organization members on organization-owned repositories will be owned by the creating user, send events to the user’s security log, and apply the user’s codespace policies.

Please contact support if you have any issues.

Additional Resources

See more

The option to use SMS on the sudo page on GitHub.com has been removed. Users can still use other 2FA methods as well as their password to pass the sudo check and take sensitive actions. If your account only has SMS as its 2FA method, you can visit your security settings to enable additional methods such as security keys and TOTP, as well as installing the GitHub Mobile app.

To learn more about the GitHub.com sudo prompt, see "Sudo mode". For details about setting up additional 2FA methods, see "Configuring two-factor authentication".

See more

The "Remove a repository from an app installation" API has been updated to fail early if attempting to remove a repository from an application that is installed on all repositories.

To switch an application InstallationState from the all to some state in your organization, an organization owner or application manager must make this change within the UI, while picking up to 50 repositories for the app to continue to have access to. From there, additional repositories can be added via the UI or the "Add a repository to an app installation" API.

To learn more about managing application installations, see "Modifying repository access". For details on the GitHub App REST API, see "GitHub Apps".

See more

The GitHub Enterprise Server 3.9 release candidate is here

GitHub Enterprise Server 3.9 brings new capabilities to help companies create and ship secure software, more often. Here are a few highlights:

  • Autoscaling with self-hosted runners – Actions administrators can configure auto scaling self-hosted actions runners using the actions runner controller and runner scale sets.
  • The Projects public beta has seen numerous improvements – We're continuing to add more functionality to Projects in GitHub Enterprise Server, to make planning and tracking your work in GitHub even more effective.
  • REST API now has versioning – API releases will be named with the date on which they are released (for example, 2021-04-01). Users will pick what version they want to use on a request-by-request basis, and each version will be supported for two years.
  • Establishing semantic conventions for logging – As part of GitHub's gradual migration to internal semantic conventions for OpenTelemetry, we have updated many of the field names in our logging statements. This makes it clearer what each statement is referencing and allows you to troubleshoot problems quicker.

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. Read more about the release candidate process.

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

See more

Announcing important changes to what it means for a pull request to be 'approved'.

If you use pull requests with protected branches, there are some important security improvements rolling out now that may impact your workflow:

  • Merge commits created locally and pushed to a protected branch will be rejected if the contents differ from the system-created merge.
  • The branch protection for dismissing stale reviews now dismisses approvals whenever a merge base changes after a review.
  • A pull request approval now only counts towards the pull request it was submitted against.

Note: You may see some older approvals dismissed as we rollout these changes.

Read on to learn more about the specific changes:

User-created merges must have the same contents as the system-created merge.

Previously, it was possible for users to make unreviewed changes to a protected branch, by creating the merge commit locally and pushing it to the server. The merge would be accepted, so long as the parents commits were set correctly.

Going forward, manually creating the merge commit for a pull request and pushing it directly to a protected branch will only succeed if the contents of the merge exactly match the system-generated merge for the pull request. This new check will be enforced on branches where the branch protections mentioned earlier are enabled.

Pull request approvals will become stale if the merge base changes
A pull request approval will be marked as stale when the merge base changes after a review is submitted.

The merge base of a pull request is the closest common ancestor of both the target and source branches for that pull request. It is often (but not always) the commit where a user has branched off the mainline development and started working on a topic branch:

228341522-a954ade3-a4e2-4703-8920-8c3220e2ff0d

When "dismiss stale approvals" is enabled, the review will be dismissed and needs a re-approval. If branch protection rules specify that every push needs to be reviewed by a second contributor, a change in the merge base will require fresh approvals.

Merge bases changing under a pull request will preserve approvals in most situations where no new changes are introduced.

Pull requests no longer combine approvals.
Previously it was possible for a branch protected by "required pull request review" to be merged without an approved PR. This was possible because approvals were gathered across multiple independent pull requests if the feature branches pointed to the same commit as well as targeting the same branch.

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

See more

You can now create single-use self-hosted runners without time-limited registration tokens using the REST API.

When a runner registers using this API it will only be allowed to run a single job before being automatically removed from the repository, organization, or enterprise. This enables you to improve the security of your self-hosted runner infrastructure by limiting the exposure of long lived credentials.

Learn more about just-in-time runners

See more

Today, we're extending CodeQL code scanning support to Swift! Developers working on Swift libraries and apps on Apple platforms can now benefit from our best-in-class code security analysis. We currently identify issues such as path injection, unsafe web view fetches, numerous cryptographic misuses and other types of unsafe evaluation or processing of unsanitized user-controlled data. During this beta, we’ll gradually increase our coverage of distinct weaknesses.

Swift joins our existing supported languages (C/C++, Java/Kotlin, JS/TS, Python, Ruby, C#, and Go), which in sum run nearly 400 checks on your code, all while keeping false positive rates low and precision high.

Set up code scanning on your Swift repositories today and receive actionable security alerts right on your pull requests. Read more about our supported Swift versions and platforms here.

Swift support is available starting with CodeQL version 2.13.3. GitHub.com users are automatically updated, while GitHub Enterprise Server users can update using these guidelines. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

This is just the start for Swift support in GitHub Advanced Security, keep an eye on the main GitHub blog for further announcements. If you have any feedback or questions about the Swift beta, consider joining our community in the #codeql-swift-beta channel in the GitHub Security Lab Slack. Thanks to all Swift community members who have participated in the private beta.

See more

We've now made it easier to understand changes to your repositories with the new activity view. Historically viewing pushes to a repository required contacting GitHub support. This new activity view gives users with read access the ability to self-serve insights to a repository and all of its changes.

You can access the Activity view from the main page of a repository by clicking "Activity" to the right of the list of files.

Location of activity view link on repo homepage

You can also access the activity view from the Branches page of any repository by clicking on the activity icon.

Branch activity icon

Activity view

From the activity view you can sort and filter to find exactly what you are looking for.

Filter activity type

Here is an example of how you could use the activity view to find a force push on a particular branch, and then compare the changes to the repository before and after the push:
Screen recording of the activity view

Learn more about the Activity view.

Already using the activity view? We'd love to hear your feedback.

See more

Today's Changelog brings you project templates, support for tasklists on mobile, and bulk edit support on boards!

🎨 Project templates for organizations

Project templates for organizations are now in public beta! Building upon the recently released ability to copy an existing project you can now create, save and reuse projects with templates, helping you save time and create a consistent approach to managing your projects.

To get started with project templates:

  • Project admins will see a new option Make template on the settings page that will set the project as a template.
  • If you want to keep your current project, but think it will make a great template, admins and write access users will see the option to Copy as template, which will create a new version without your issues and pull requests as a template.
  • To see all templates, simply search for is:template on the projects page.
  • When creating a new project, you will see available templates in the sidebar.

image shows a number of project template options when starting a new project

As we continue to build out more functionality for project templates we would love your feedback and to hear more about your experiences and requests. Check out the docs for more details.

📱 Tasklists on Mobile

mobile-tasklist

Tasklists now render on mobile! View progress on your initiatives, epics, umbrella issues (or whatever your team calls them) on the go!

Tasklists are currently in private beta, and you can sign your organization up on the waitlist.

💪 ⌨️ Bulk updates and keyboard navigation on boards

Kanban enthusiasts rejoice! We've added the ability for users to bulk update cards on their boards with either mouse drag and drop or keyboard navigation. To select more than one card, simply hold Ctrl/Command and click on the cards you wish to move. For keyboard warriors, tab to the card you wish to drag, hold shift and navigate to other cards you wish to update, and press enter to select and move the selected cards.

For more detailed information, find a full list of keyboard shortcuts in the docs.

👁️ Persistent collapsed groups on tables and roadmaps

When you collapse a group in the table or roadmap layout, the group will remain collapsed when you return to the view. This is only the case for your view and will not be applied for anyone else.

🎨 Updates to single-select color options

If other values in this field already have a color, a color will be auto-assigned to any new values added to the field.

📋 Copying values in tables

You can now select and copy a range of cells. Use Ctrl/Command + a keyboard command once to select a row and twice to select all cells, and Ctrl/Command + c to copy values. You can then paste values in other text editors using Ctrl/Command + v.

✨ Bug fixes & improvements

Tasklists bug fixes and improvements:

  • Updated the iconography for "saving" tasklists
  • Set a limit of 512 characters for draft tasks
  • Fixed a bug where users were seeing a red error banner with the message "An error occured while loading your tasklist."

Other changes include:

  • Updated the Auto-archive workflow confirmation dialog to show number of items archived
  • Fixed inconsistent text highlighting in code search filter input
  • Added the ability to exit the label dialog without using a mouse

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

See more

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

We have partnered with Canadian Digital Service (CDS) to scan for their tokens and help secure our mutual users on public repositories. Canadian Digital Service tokens allow users to send email and text messages using the Government of Canada’s Notify service. GitHub will forward access tokens found in public repositories to CDS, which will then revoke the token and contact the impacted users to help them generate new tokens. You can read more information about CDS's tokens here.

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

See more

Bamboo Server and Data Center migrations to GitHub Actions are now in public beta! You can now plan, test, and automate the migration of your Bamboo pipelines to GitHub Actions easily and for free using GitHub Actions Importer.

For details on how to get started, check out our documentation. For questions and feedback about the public beta, please visit the GitHub Actions Importer community.

See more

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 LogicMonitor to scan for their tokens and help secure our mutual users on public repositories. LogicMonitor tokens allow users to authenticate requests to LogicMonitor's REST API. GitHub will forward access tokens found in public repositories to LogicMonitor, which will then inform their portal contacts for remediation. You can read more information about LogicMonitor's tokens here.

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

See more