closing-down

Subscribe to all “closing-down” 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

In the coming months, the current interface for managing code security settings for an enterprise will be deprecated and replaced with new and improved code security configurations that will provide you a more consistent and scalable way to manage security settings across repositories within your enterprise.

The current REST API endpoint to enable or disable a security feature for an enterprise is now deprecated. It will continue to work for an additional year in the current version of the REST API before being removed in September of 2025, but note that it may conflict with settings assigned in code security configurations if the configuration is unenforced, potentially resulting in a security configuration being unintentionally removed from a repository. To change the security settings for repositories at the enterprise level, you can use the current enterprise-level security settings UI or the upcoming code security configurations API.

Send us your feedback!.

See more

As of November 6, 2024, Dependabot will no longer support Composer version 1, which has reached its end-of-life. If you continue to use Composer 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 Composer. As of October 2024, the newest supported release of Composer is 2.8, and the long-term supported version is 2.2. View Composer’s official documentation for more information about supported releases.

See more

As of October 7, 2024, Dependabot no longer supports Bundler version 1, which has reached its end-of-life. If you continue to use Bundler version 1, Dependabot will be unable to create pull requests to update your dependencies. If this affects you, we recommend updating to a supported release of Bundler. As of October 2024, the newest supported version is 2.5.

View Bundler’s official support policies for more information about supported releases.

See more

Following our change to default customers to use Node20, Node16 will reach end of life in the Actions runner on the 15th of October 2024.

From the 15th of October, we will no longer include Node16 in the Actions runner and customers will no longer be able to use Node16 Actions or operating systems that do not support Node20.

To prevent disruption to your Actions workflows, if you’re an Actions maintainer, update your actions to run on Node20 instead of Node16. If you’re an Actions user, update your workflows with latest versions of the actions, which run on Node20.

Learn more about Actions configuration settings or using versions for Actions. Join the discussion within GitHub Community.

See more

Over the next six months, we will be making the following changes and deprecations to the GitHub Actions service:

Reduction to Webhook rate limit in GitHub Actions
Starting October 1st, 2024 we will be adding a new rate limit of 1,250 requests per 10 seconds per repository for incoming Webhook events for GitHub Actions. After monitoring usage over the past several weeks, we believe that no customers will be impacted by this change, but if you believe you will need to exceed this in the future, please reach out to GitHub support.

Cache v1-v2 deprecation
Starting February 1st, 2025, Actions’ cache storage will move to a new architecture, resulting in the deprecation of v1-v2 of actions/cache. Attempting to use a version of the action after the announced deprecation date will result in a workflow failure. Please note: if you are pinned to a specific version or SHA of the action, your workflows will also fail after February 1st. We strongly encourage you to update your workflows to begin using v3 or v4 of actions/cache as soon as possible.

This deprecation will not impact any existing versions of GitHub Enterprise Server that are currently in use. Cached entries within their retention period will remain accessible from the UI or REST API regardless of the version used to upload. This announcement will also be added to the actions/cache repository.

See more

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.

See more

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
See more

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.

See more

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.

Send us your feedback!.

See more

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.

See more

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.
  • March 11, 2025: Projects (classic) will be removed in version 3.16.

REST API Timeline

See more

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.

See more

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”.

See more

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.

See more