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

EDIT: Monday December 2nd, 2024

GitHub Enterprise Server Timeline changing sunset to GHES 3.17 as the final version instead of 3.16.

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: No changes will be made
  • Version 3.17: 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, 2024 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.
  • June 3, 2025: Projects (classic) will be removed in version 3.17.

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 January 30th, 2025, 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

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.

See more

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.

See more

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.

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.

See more

As of August 17, 2023, Dependabot updates no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

This change impacts Dependabot pull requests only – you will continue to receive Dependabot alerts for dependencies with known vulnerabilities. To resolve the alert, you can upgrade the affected package yourself manually.

View the official release cycle for Python for more information on supported versions.

Learn more about supported package managers for Dependabot

See more

For security reasons, source IP addresses have been removed from error messages that are returned from the GitHub API when callers try to access protected resources from non-permitted IP addresses.

To learn more about IP allow lists, visit Restricting network traffic to your enterprise with an IP allow list in the GitHub documentation.

If you'd like to learn more about your source IP addresses, please contact GitHub Support.

See more

As of August 17, 2023, Dependabot will no longer support Python 3.6 or 3.7, which have reached their end-of-life. If your code uses these versions, Dependabot will no longer be able to open pull requests in your repository and will log errors. Update to at least Python 3.8 to ensure your code is secure and Dependabot can still run.

View the official release cycle for Python for more information on supported versions.

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