As of October 7, 2024, Dependabot will no longer support Bundler version 1, which has reached its end-of-life. If you continue to use Bundler version 1, there’s a risk that Dependabot will not create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of Bundler. As of September 2024, the newest supported version of Bundler is 2.5. View Bundler’s official support policies for more information about supported releases.
GitHub Actions will be making the following deprecations and breaking changes in our runners and services over the next 6 months.
Exclude hidden files by default in Upload Artifact GitHub Actions
From September 2nd, 2024, we will no longer include hidden files and folders as part of the default upload of the v3 and v4 upload-artifact
actions. This reduces the risk that credentials are accidentally uploaded into artifacts. Customers who need to continue to upload these files can use a new option, ‘include-hidden-files’, to continue to do so.
Ubuntu 20 & Ubuntu 22 arm64 Images
On September 3rd, 2024, we are deprecating the Ubuntu 22/20 base images for our arm64 hosted runners as these are not widely used and customers are better served using the new Arm owned images. At that time all workflows using the Ubuntu 22 or 20 base image on arm64 will begin to fail. To change the image your runner is using, you can delete the runner and recreate a runner with the same name, to prevent failures. We recommend using the partner images provided by Arm:
- Ubuntu 24.04 by Arm Limited
- Ubuntu 22.04 by Arm Limited
.NET6 deprecation in the runner
In October, 2024, at the same time as we move to Node20 on the Actions runner, we will be deprecating .NET6 in the Actions runner and moving to .NET8. This is because .NET6 will reach end of life in November 2024. Any customers who are still using operating systems which are reliant on unsupported binaries will need to upgrade prior to this change. The removal of support for .NET6 means the following operating systems will no longer be supported from this time:
– Debian 10
– macOS 11.0
– macOS 10.15
Along with those already marked as unsupported in our changelog for the removal of Node16.
macOS12 runner image
We are beginning the deprecation process for the macOS 12 runner image, which allows us to balance our fleet capacity ahead of our upcoming macOS 15 launch. This image will be fully retired by the December 3rd, 2024. We recommend updating workflows to use `macos-14`, `macos-13`, or `macos-latest`.
Unsupported macOS labels
On December 3rd, 2024, we are deprecating some of our older and less used labels which are used for smaller numbers of workflows. The following runner labels will stop working from that time:
- macos-11.0
- macos-12-xl
- macos-13-xl
- macos-13-xl-arm64
- macos-latest-xl
- Macos-latest-xl-arm64
The enum field indicating a ‘detached’ status will be deprecated from the ‘Get repositories associated with a code security configuration’ endpoint.
The endpoint itself will remain.
We will replace the ‘detached’ status with a ‘removed’ status. We will also add an additional status of ‘removed_by_enterprise’ to indicate situations where enterprise level settings changes have caused an organization-level code security configuration to be removed from a repository.
This change ensures that the code security configurations API is more inline with the status filters in the UI.
Code security configurations were made generally available on July 10th, 2024. This experience replaces our old settings experience and its API.
If you are currently using the REST API endpoint to enable or disable a security feature for an organization, this endpoint is now considered deprecated.
It will continue to work for an additional year in the current version of the REST API before being removed in July of 2025. However, users should note this will conflict with the settings assigned in code security configurations if the configuration is unenforced. This may result in a code security configuration being unintentionally removed from a repository.
The endpoint will be removed entirely in the next version of the REST API.
To change the security settings for repositories, you can use the code security configurations UI, the configurations API, or the unaffected enterprise-level security settings.
Starting today, we will begin work towards the sunset of tag protections, with a full deprecation planned for August 30, 2024. See below for a full sunset timeline. You can migrate existing tag protections with the import to ruleset feature.
We launched repository rules last year to meet the needs of tag protection rules, while also scaling support to provide new functionalities like org-wide rules, granular restrictions for creating, reading, and updating events, and a more granular bypass model that does not require repository administrator permissions. As we such, we will sunset tag protections in favor of our ongoing investment in the repository rulesets platform.
You can import existing tag protection rules today with the existing migration feature. If no action is taken before the sunset date, GitHub will migrate all existing tag protections into a corresponding ruleset.
When are changes happening?
GitHub.com Timeline
- May 30 : Repositories without tag protection rules will no longer be able to add new protection rules via the GitHub.com UI
- July 24 through August 14 : A series of API brownouts will be run, see below for additional details on dates and times.
- August 30, 2024: All tag protection rules will be migrated to a new tag ruleset. All REST and GraphQL API endpoints will be deprecated
GitHub.com API Timeline
- May 30: API responses will include a deprecation notice
- July 24: 1 hour API brownout
- August 7: 8 hour API brownout
- August 14: 24 hour API brownout
- August 30: The tag protection rule API will begin responding with NULL data
- The tag protection rules API will be deprecated in the next calendar version
GitHub Enterprise Server Timeline
- Version 3.14: Tag protection rules will be marked for deprecation with an in-product banner and API responses will include a deprecation notice
- Version 3.15: No changes will be made
- Version 3.16: Tag protection rules will be migrated to a ruleset and the tag protection rule feature will no longer be available
Join the discussion within GitHub Community.
August 7 update: additional details added to the GitHub.com sunset timeline.
Today, we are announcing the sunset of GitHub Projects (classic), which will follow individual sunset timelines for GitHub.com, GitHub Enterprise Server, and the REST API. Please see the details below for more information.
In July 2022, we announced the general availability of the new and improved Projects, powered by GitHub Issues. Since then, these new Projects have expanded to include a variety of features such as roadmaps, mobile support, project templates for organizations, project status updates, and unlimited items.
As we continue to invest in and enhance the future of Projects, we will be sunsetting Projects (classic). To migrate your existing classic projects to the new projects, please click Start migration
on the banner at the top of your classic project:
The sunset will follow these timelines:
GitHub.com Timeline
- May 23, 2024: A banner to migrate will be visible on classic projects, with the migration tooling included. Creation of new classic projects will be disabled.
- August 23, 2024: Projects (classic) will be officially sunset. All unmigrated classic projects will automatically be migrated to new projects.
- If projects is disabled on the organization level, classic projects under that organization will not be migrated.
- Only cards that have been updated in the last year will be migrated.
- During the migration process, projects v2 webhooks for the newly created projects will not be emitted.
- After the migration on August 23, you will still technically be able to use the REST or GraphQL API to update your classic Projects. We heavily discourage this as your updates will not be persisted to the migrated V2 Projects.
GitHub Enterprise Server Timeline
- August 27, 2024: Projects (classic) will be marked for deprecation in version 3.14. A banner to migrate will be visible on classic projects, with the migration tooling included.
- November 19, 2024: Projects (classic) will be removed in version 3.15.
REST API Timeline
- November 19, 2024: The REST API for Projects (classic) will be sunset.
As of today, May 15th, 2024, you will no longer be able to create security advisories in private repositories. Formerly published advisories will no longer be available.
This change does not affect security advisories in public repositories, or the advisories listed in GitHub’s open-source Advisory Database.
When uploading a SARIF file that contains multiple SARIF runs for the same tool and category,
Code Scanning combines those runs into a single run.
Combining multiple runs within the same SARIF file is an undocumented feature that was originally intended to simplify uploading multiple analyses for the same commit. Since then, we have introduced the explicit concept of category
to be able to upload multiple analysis for the same commit, thus better aligning with the SARIF Specification.
Today, we are starting the deprecation path for the combination of multiple SARIF runs with the same tool and category within the same file. Specifically, in the next few days, the github/codeql-action/upload-sarif
action will start showing a deprecation warning when using 3rd party tools that rely on the combination of multiple SARIF runs with the same tool and category within the same file. While showing the deprecation warning, the upload of the SARIF file will succeed.
We expect to fully stop combining multiple SARIF runs with the same tool and category within the same file in June 2025 (for github.com) and in GHES 3.18, at which point the upload of the SARIF file will fail.
How does this affect me?
You are affected if you are using the github/codeql-action/upload-sarif
action to upload results from a 3rd party Code Scanning tool and the tool generates multiple runs with the same category in a single SARIF file.
If that is the case, you will start seeing the deprecation warning, and you should work with the tool provider so that each run in the SARIF file has a distinct tool or category.
You are affected if you are using github/codeql-action/upload-sarif
action to upload multiple SARIF files from a 3rd party tool. You can end up with multiple SARIF files if the tool either generates multiple SARIF files itself or if you are using a matrix build to run multiple analyses. Specifically, if you are doing a matrix build that generates multiple SARIF files and have a dedicated job to upload all the SARIF files together. For example, your workflow might look like the following if you analyze two apps using a matrix build but then have a dedicated upload
job to upload all the SARIF files together:
jobs:
analyze:
...
strategy:
matrix:
app: ['app1', 'app2']
steps:
- name: SAST Scan
...
- name: Temporary store SARIF file
uses: actions/upload-artifact@v4
with:
name: sarif-${{ matrix.app }}
path: "results"
upload:
name: Upload SARIF
needs: analyze
steps:
- name: Fetch SARIF files
uses: actions/download-artifact@v4
with:
path: ../results
pattern: sarif-*
merge-multiple: true
- name: Upload Results
uses: github/codeql-action/upload-sarif@v3
In this case, you need to make the call to the github/codeql-action/upload-sarif
action to include a distinct category
. For example, you can embed the step in the matrix job and use the matrix variables to generate a unique category. In this way, the example above becomes:
jobs:
analyze:
...
strategy:
matrix:
app: ['app1', 'app2']
steps:
- name: SAST Scan
...
- name: Upload Results
uses: github/codeql-action/upload-sarif@v3
with:
category: ${{ matrix.app }}
Note that changing the value of the category
causes older alerts to remain open, and you might want to delete the configuration using the previous category
value.
You are not affected if you are only using CodeQL via the github/codeql-action
action. For the few repositories that rely on this behavior, the CodeQL CLI (starting version 2.17.0) includes backwards compatible logic.
You are not affected if you are uploading multiple SARIF files for the same commit using one of the documented approaches.
What’s next?
In June 2025, SARIF uploads to github.com that contain multiple runs with the same tool and category will be rejected.
GitHub Importer is a tool that quickly imports source code repositories, including commits and revision history, to GitHub.com. As part of this release, GitHub Importer has implemented a new method for git source migration that will provide users with improved reliability and more detailed error handling when migrating git source repositories to GitHub. Click here to import your project to GitHub.
As previously communicated, this change comes with the ending of support for the REST API endpoints for source imports. Moving forward, these endpoints will return an error. Users are encouraged to make use of the new import repository page instead.
Lastly, we previously announced that GitHub Importer will no longer support importing Mercurial, Subversion and Team Foundation Version Control (TFVC) repositories. Effective today, we’ve ended support for this functionality due to extremely low levels of usage. 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”.
Starting November 30, 2024, GitHub Actions customers will no longer be able to use v3 of actions/upload-artifact or actions/download-artifact. Customers should update workflows to begin using v4 of the artifact actions as soon as possible. While v4 of the artifact actions improves upload and download speeds by up to 98% and includes several new features, there are key differences from previous versions that may require updates to your workflows. Please see the documentation in the project repositories for guidance on how to migrate your workflows.
The deprecation of v3 will be similar to the previously announced v1 and v2 deprecation plans, which is scheduled to take place on June 30, 2024. Version tags will not be removed from the project repositories, however, attempting to use a version of the actions after the deprecation date will result in a workflow failure. Artifacts within their retention period will remain accessible from the UI or REST API regardless of the version used to upload. This deprecation will not impact any existing versions of GitHub Enterprise Server being used by customers.
This announcement will also be added to actions/upload-artifact and actions/download-artifact. Please visit the documentation to learn more about storing workflow data as artifacts in Actions.
Docker Compose v1 has been deprecated as of July 2023. All customers utilizing Compose v1 on GitHub-hosted runners are encouraged to migrate to Compose v2. Per GitHub’s support policy we will remove this tool from our GitHub managed runner images effective July 9, 2024.
To avoid breaking changes, customers will need to update their Actions workflow files from using docker-compose
to docker compose
. After July 9, workflows will begin to fail that are using the previous syntax. Customers are advised to review the migration instructions to ensure they are making all the changes required.
For more information on GitHub managed images, see the runner-images repository.
On December 14, 2023, GitHub Actions released v4 of the actions to upload and download artifacts. This version improves upload/download speeds by up to 98%, addresses long-standing customer feedback requests, and represents the future of artifacts in GitHub Actions.
With the introduction of v4, we will be deprecating v1 and v2 of actions/upload-artifact, actions/download-artifact, and related npm packages on June 30, 2024. We strongly encourage customers to update their workflows to begin using v4 of the artifact actions.
In order to prevent issues for customers using GitHub Connect, the tags for v1 through v2 will not be removed from the actions/upload-artifact and actions/download-artifact project repositories. However, attempting to use a version of the actions after the announced deprecation date will result in a workflow failure. This deprecation will not impact any existing versions of GitHub Enterprise Server being used by customers.
This announcement will also be added to actions/upload-artifact and actions/download-artifact. Please visit the documentation to learn more about storing workflow data as artifacts in Actions.
The public beta Activity Overview of Organization Insights for GitHub Enterprise Cloud will be deprecated on January 5, 2024. Since its initial beta launch in 2019, the amount of data calculation and storage required for these views has proven untenable in its current format and the underlying service will be taken offline later in January. Metrics-specific integrations such as Cauldron are available to read, store, and visualize your organization’s data via the GitHub API, as well as more general-purpose data visualization platforms such as PowerBI or Grafana. The Dependency Insights feature will not be impacted.
As of February 15th, 2024, you will no longer be able to create security advisories in private repositories. Formerly published advisories will no longer be available.
This change does not affect security advisories in public repositories, or the advisories listed in GitHub’s open-source Advisory Database.
We're simplifying how Dependabot operates! Previously, if Dependabot encountered errors in its last run, it would automatically re-run the job when there were changes in the package manifest (like adding or changing dependencies). This often led to Dependabot running more than needed and creating unscheduled pull requests. To streamline the process and stick to the schedules you set, this automated re-run feature is being deprecated.
Dependabot will still run jobs according to your schedule, and you'll have the option to manually trigger jobs whenever necessary.