GitHub Upgrade – 3.12.2

On Monday, May 6th at 5:00 PM EST, the GitHub Service Team will be taking the NC State GitHub Enterprise service offline for an upgrade to version 3.12.2.

During the outage no one will be able to login or interact with the service in any way. We do not expect the upgrade to take more than the scheduled period. In the event that more time is needed, we will update this status.

This upgrade includes changes to the main GitHub User Interface to better match the current user interface on

This changelog is not exhaustive. To view a complete list of changes in this upgrade, please see the GitHub Enterprise 3.12 release notes.


  • Authentication
    • To manage work across different accounts and GitHub products, users can authenticate to the GitHub CLI with multiple accounts, then use the gh auth switch command to switch between active accounts. For more information, see gh auth login in the GitHub CLI manual.
  • Dependabot
    • Users can choose how to respond to Dependabot alerts automatically by setting up custom auto-triage rules in repositories or organizations. Auto-triage rules provide control over whether an alert is ignored, is snoozed, or triggers a pull request for a security update. Users can also use a rule created by GitHub to automatically dismiss low-impact issues in npm dependencies. Auto-triage rules are in public beta and subject to change. For more information, see “About Dependabot auto-triage rules.”
  • GitHub Actions
    • For self-hosted GitHub Actions runners on this GitHub Enterprise Server release, the minimum required version of the GitHub Actions Runner application is 2.311.0. See the release notes for this version in the actions/runner repository on If your instance uses ephemeral self-hosted runners and you’ve disabled automatic updates, you must upgrade your runners to this version of the Runner application before upgrading your instance to this GitHub Enterprise Server release. [Updated: 2024-04-25]
    • Users can set up organization-wide rules to enforce their CI/CD workflows, ensuring workflows pass before pull requests can be merged into target repositories. You can fine-tune your rule by selecting a specific branch, tag, or SHA, and provide maximum control over the version expected to run. To reduce risk, you can “evaluate” workflow rules to validate rules are working correctly. For more information, see “Available rules for rulesets“.
    • GitHub Actions developers can use GitHub Actions Importer to plan, forecast, and automate the migration of existing CI/CD pipelines from Bamboo Server, Bamboo Data Center, and Bitbucket. Developers can migrate their Bamboo and Bitbucket pipelines to GitHub Actions using the GitHub CLI or IssueOps. For more information, see “Migrating from Bitbucket Pipelines with GitHub Actions Importer” and “Migrating from Bamboo with GitHub Actions Importer“.
    • Actions environments support defining selected tag patterns to restrict deployments. Administrators who want to have more secure and controlled deployments can specify selected tags or tag patterns on their protected environments. For more information, see “Using environments for deployment“.
  • Projects
    • Project templates for organizations are generally available. Users in an organization can create a template to share a pre-configured project with other people in your organization as the base for their projects. For more information, see “Managing project templates in your organization“.
    • Users can access Projects from from the global navigation menu. This page can be used to find projects you’ve recently viewed or created, regardless of the organization or where they are located. For more information, see “Finding your projects“.
  • GitHub Discussions
  • Pull Requests
    • Users can merge pull requests without needing to wait for status checks to pass by adding a pull request to a merge queue. The merge queue ensures that the changes in the pull request will pass all required status checks when applied to the latest version of the target branch. A pull request is merged automatically once it reaches the front of the queue. This feature is particularly useful on branches where pull requests are merged frequently. For more information, see “Managing a merge queue.”
  • Markdown
    • Users can highlight information using Markdown alerts. Alerts are displayed with distinctive colors and icons, and include notes, tips, warnings, and more. For more information, see “Basic writing and formatting syntax.”
  • Accessibility
    • The web interface for GitHub Enterprise Server has been redesigned to provide a more intuitive, responsive, and accessible navigation experience. Changes include:
      • Breadcrumbs to help users navigate the site more efficiently
      • Menus to quickly access a user’s top repositories and teams
      • A more accessible navigation experience, including more consistent keyboard navigation and improvements to code search
      For more information, see Exploring GitHub with the redesigned navigation on the GitHub Blog. Note that the redesigned navigation is now generally available.
    • The comment field in issues, discussions, and pull requests has been redesigned for easier use across different screen sizes, and for better integration with assistive technology such as keyboard navigation and screen readers.


  • The REST API’s /rate_limit endpoint is now subject to rate limits. Requests will not consume the primary rate limit quotas for the authenticated user. However, making a very high number of requests in a short period of time will trigger the secondary rate limits if secondary rate limits are enabled on your instance. For more information, see “REST API endpoints for rate limits” in the REST API documentation and “Configuring rate limits.”
  • The payload for the push webhook event is now limited to 2,048 commits. If there are more than 2,048 commits in a push, the webhook payload for that push will not contain any commits. If you need to fetch commit information, you can use the Commits endpoints of the REST API. For more information, see “Webhook events and payloads” and “REST API endpoints for commits.”

Security fixes

  • MEDIUM: An attacker with a deploy key for an organization-owned repository could bypass a ruleset that specified organization administrators as bypass actors. Exploitation would require an attacker to already have access to a valid deploy key for a repository. GitHub has requested CVE ID CVE-2024-3470 for this vulnerability, which was reported via the GitHub Bug Bounty program.
  • MEDIUM: An attacker could maintain admin access to a detached repository in a race condition by making a GraphQL mutation to alter repository permissions while the repository is detached. GitHub has requested CVE ID CVE-2024-2440 for this vulnerability, which was reported via the GitHub Bug Bounty program.
  • Packages have been updated to the latest security versions.

Bug fixes

  • On an instance with GitHub Actions enabled, GitHub Actions workflows that deployed GitHub Pages sites failed with the following error: Error: Deployment failed, try again later.
  • Some API endpoints for projects did not properly filter target repositories based on the users access.
  • Organizations using projects (classic) returned an error log about a soon-to-be deprecated MySQL feature when viewing a project.
  • The web UI presented inapplicable fine-grained permissions for assignment to custom repository roles. The permissions were also displayed as implicitly included in certain base roles.
  • Unauthenticated requests to the REST APIs /search/code endpoint returned erroneous rate-limit values.
  • The profile settings for organizations displayed a warning about profile images that does not apply to organizations on a GitHub Enterprise Server instance.
  • When viewing a file in the instance’s web interface, the “Copy lines” and “Copy permalink” interactions did not copy content to the clipboard.
  • A Redis job had a memory limit that was too low in some cases, leading the process to run out of memory.
  • The / keyboard shortcut did not display the search field in the web UI.
  • In some cases, Treelights timeouts caused pull requests to return a 500 error.