You can now configure an allow list of IP addresses that can access application services on your GitHub Enterprise Server instance while maintenance mode is enabled. Administrators who visit the instance's web interface from an allowed IP address can validate the instance's functionality post-maintenance and before disabling maintenance mode. For more information, see "Enabling and scheduling maintenance mode."
With custom repository roles, organizations now have more granular control over the repository access permissions they can grant to users. For more information, see "Managing custom repository roles for an organization."
A custom repository role is created by an organization owner, and is available across all repositories in that organization. Each role can be given a custom name, and a description. It can be configured from a set of over 40 fine grained permissions. Once created, repository admins can assign a custom role to any user, team or outside collaborator in their repository.
Custom repository roles can be created, viewed, edited and deleted via the new Repository roles tab in an organization's settings. A maximum of 3 custom roles can be created within an organization.
Custom repository roles are also fully supported in the GitHub Enterprise Server REST APIs. The Organizations API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams have been extended to support custom repository roles. For more information, see "Organizations" in the REST API documentation.
The GitHub Container registry (GHCR) is now available in GitHub Enterprise Server 3.5 as a public beta, offering developers the ability to publish, download, and manage containers. GitHub Packages container support implements the OCI standards for hosting Docker images. For more information, see "GitHub Container registry."
Dependabot version and security updates are now generally available in GitHub Enterprise Server 3.5. All the popular ecosystems and features that work on GitHub.com repositories now can be set up on your GitHub Enterprise Server instance. Dependabot on GitHub Enterprise Server requires GitHub Actions and a pool of self-hosted Dependabot runners, GitHub Connect enabled, and Dependabot enabled by an admin.
Following on from the public beta release, we will be supporting the use of GitHub Actions runners hosted on a Kubernetes setup.
For more information, see "Setting up Dependabot updates."
You can now analyze how your team works, understand the value you get from GitHub Enterprise Server, and help us improve our products by reviewing your instance's usage data and sharing this aggregate data with GitHub. You can use your own tools to analyze your usage over time by downloading your data in a CSV or JSON file or by accessing it using the REST API. To see the list of aggregate metrics collected, see "About Server Statistics." Server Statistics data includes no personal data nor GitHub content, such as code, issues, comments, or pull requests content. For a better understanding of how we store and secure Server Statistics data, see "GitHub Security." For more information about Server Statistics, see "Analyzing how your team works with Server Statistics." This feature is available in public beta.
Site administrators can now enable and configure a rate limit for GitHub Actions. By default, the rate limit is disabled. When workflow jobs cannot immediately be assigned to an available runner, they will wait in a queue until a runner is available. However, if GitHub Actions experiences a sustained high load, the queue can back up faster than it can drain and the performance of the GitHub Enterprise Server instance may degrade. To avoid this, an administrator can configure a rate limit. When the rate limit is exceeded, additional workflow runs will fail immediately rather than being put in the queue. Once the rate has stabilized below the threshold, new runs can be queued again. For more information, see "Configuring rate limits."
GitHub Actions on GitHub Enterprise Server now supports OIDC for secure deployments to cloud providers, which uses short-lived tokens that are automatically rotated for each deployment. OIDC enables the following functionality.
- Seamless authentication between cloud providers and GitHub Enterprise Server without the need for storing any long-lived cloud secrets on your instance
- Cloud administrators can rely on the security mechanisms of a particular cloud provider to ensure that GitHub Actions workflows have minimal access to cloud resources. There is no duplication of secret management between GitHub Enterprise Server and the cloud.
For more information, see "Security hardening your deployments."
Support for GitHub Actions in internal repositories is now generally available for organizations on your GitHub Enterprise Server instance. You can innersource automation by sharing actions in internal repositories. You can manage a repository's settings or use the REST API to allow access to workflows in other repositories within the organization or in any organization on the instance. For more information, see "Sharing actions and workflows with your enterprise," "Managing GitHub Actions settings for a repository," and "Actions Permissions" in the REST API documentation.
You can now use dependency caching to speed up your GitHub Actions workflows. To cache dependencies for a job, you can include the actions/cache action to create a cache with a unique key. You can share caches across all workflows in the same repository. These workflows can then restore the cache and run faster.
Actions users can also use our cache APIs to:
- Define the enterprise policy for cache size range allowed per repository.
- Query the cache usage within each repository and monitor if the total size of all caches is reaching the upper limit.
- Increase the maximum cache size for a repository within the allowed enterprise limits, based on the cache requirements of the repository.
- Monitor aggregate cache usage at organization level or at enterprise level.
The external blob storage that is configured within your enterprise account will now be shared across workflow artifacts, logs, and also the caches. For more information, see "Caching dependencies to speed up workflows."
You can now configure GitHub Enterprise Server to automatically sign commits made in the web interface, such as from editing a file or merging a pull request. Signed commits increase confidence that changes come from trusted sources. This feature allows the Require signed commits branch protection setting to block unsigned commits from entering a repository, while allowing entry of signed commits – even those made in the web interface. For more information, see "Configuring web commit signing."
For customers that sync license usage between GitHub Enterprise Server and GitHub Enterprise Cloud automatically using GitHub Connect, you now have the ability to sync your license usage independently of the automatic weekly sync. This feature also reports the status of sync job. For more information, see "Syncing license usage between GitHub Enterprise Server and GitHub Enterprise Cloud."
Reusable workflows are now generally available. Reusable workflows help you reduce duplication by enabling you to reuse an entire workflow as if it were an action. With the general availability release, a number of improvements are now available for GitHub Enterprise Server. For more information, see "Reusing workflows."
- You can utilize outputs to pass data from reusable workflows to other jobs in the caller workflow.
- You can pass environment secrets to reusable workflows.
- The audit log includes information about which reusable workflows are used.
- Reusable workflows in the same repository as the calling repository can be referenced with just the path and filename (
PATH/FILENAME). The called workflow will be from the same commit as the caller workflow.
You now have more control over when your self-hosted runners perform software updates. If you specify the
--disableupdate flag to the runner then it will not try to perform an automatic software update if a newer version of the runner is available. This allows you to update the self-hosted runner on your own schedule, and is especially convenient if your self-hosted runner is in a container.
For compatibility with the GitHub Actions service, you will need to manually update your runner within 30 days of a new runner version being available. For instructions on how to install the latest runner version, please see the installation instructions for the latest release in the runner repo.
Organization owners can now increase the security of CI/CD workflows on self-hosted runners by choosing which workflows can access a runner group. Previously, any workflow in a repository, such as an issue labeler, could access the self-hosted runners available to an organization. For more information, see "Managing access to self-hosted runners using groups" and the GitHub Blog.
You can now control whether GitHub Actions can approve pull requests. This feature protects against a user using GitHub Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user. To prevent breaking existing workflows, Allow GitHub Actions reviews to count towards required approval is enabled by default. Organization owners can disable the feature in the organization's GitHub Actions settings. For more information, see "Disabling or limiting GitHub Actions for your organization."
You can now re-run only failed jobs or an individual job in a GitHub Actions workflow run. For more information, see "Re-running workflows and jobs."
The dependency graph now detects YAML files for GitHub Actions workflows. GitHub Enterprise Server will display the workflow files within the Insights tab's dependency graph section. Repositories that publish actions will also be able to see the number of repositories that depend on that action from the "Used By" control on the repository homepage. For more information, see "About the dependency graph."
GitHub Advanced Security customers can now view an overview of security alerts at the enterprise level. The new Security tab at the enterprise level provides a repository-centric view of application security risks, as well as an alert-centric view of all secret scanning alerts. For more information, see "About the security overview."
The overview of security alerts at the organization level is now generally available. GitHub Advanced Security customers can use the security overview to view a repository-centric view of application security risks, or an alert-centric view of all code scanning, Dependabot, and secret scanning alerts for all repositories in an organization. For more information, see "About the security overview."
Code scanning now detects a larger number of CWEs, and CodeQL code scanning fully supports the standard language features in the following language releases.
- C# 10 / .NET 6
- Python 3.10
- Java 17
- TypeScript 4.5
For more information, see the GitHub Blog.
GitHub Advanced Security customers can now view code scanning alerts in an organization's Security tab. This view is available to organization owners and members of teams with the security manager role. For more information, see "About the security overview."
Users can now retrieve code scanning alerts for an organization on your GitHub Enterprise Server instance via the REST API. This new API endpoint supplements the existing endpoint for repositories. For more information, see Code Scanning in the REST API documentation.
GitHub Enterprise Server can now block any pushes where a token is detected with high confidence. Developers can bypass the block by providing details of why the secret needs to be committed via a web UI. For more information, see "Protecting pushes with secret scanning."
GitHub Advanced Security customers can now dry run custom secret scanning patterns at the organization or repository level. Dry runs allow people with owner or admin access to review and hone their patterns before publishing them and generating alerts. You can compose a pattern, then use Save and dry run to retrieve results. The scans typically take just a few seconds, but GitHub Enterprise Server will also notify organization owners or repository admins via email when dry run results are ready. For more information, see "About secret scanning" and "Defining custom patterns for secret scanning."
The audit log now includes events associated with secret scanning custom patterns. This data helps GitHub Advanced Security customers understand actions taken on their repository-, organization-, or enterprise-level custom patterns for security and compliance audits. For more information, see "Reviewing the audit log for your organization" or "Reviewing audit logs for your enterprise."
You can now configure two new permissions for secret scanning when managing custom repository roles.
- View secret scanning results
- Dismiss or reopen secret scanning results
For more information, see "Managing custom repository roles for an organization."
GitHub Advanced Security customers can now enable secret scanning for archived repositories via the UI and API. For more information, see "About secret scanning," "About archived repositories," and "Repositories" in the REST API documentation.
GitHub Advanced Security customers using secret scanning can now opt to receive a webhook each time a secret is detected in a new location. The
secret_scanning_alert_location webhook event includes location details, like the commit SHA, and the associated alert for the detection. A location is created for every new file path containing the detected secret. For more information, see "Webhook events and payloads."
GitHub Advanced Security customers can now view Dependabot alerts in in an organization's Security tab. This view is available to organization owners and members of teams with the security manager role. For more information, see "About the security overview."
You can now configure two new permissions for Dependabot alerts when managing custom repository roles.
- View Dependabot alerts
- Dismiss or reopen Dependabot alerts
For more information, see "Managing custom repository roles for an organization."
You can now reopen dismissed Dependabot alerts through the UI page for a closed alert. This does not affect Dependabot pull requests or the GraphQL API. For more information, see "About Dependabot alerts."
Users of Dependabot version updates can now proactively update dependencies for Flutter or Dart projects that use the Pub package manager.
To test version updates on your own Dart or Flutter repository, add the following configuration file in
.github/dependabot.yaml. Note the
package-ecosystem: "pub" and
enable-beta-ecosystems: true flags.
- package-ecosystem: "pub"
DependabotUpdate GraphQL object lets you view information about what happens to your repository's security updates. When GitHub Enterprise Server detects that a dependency in your repository is vulnerable, Dependabot will attempt to open a pull request to update that dependency to a non-vulnerable version. You can now see the pull request that fixes the vulnerability. In some cases, Dependabot fails to open a pull request. Previously, the error message that Dependabot generated was only visible in the "Dependabot Alerts" section of the Security tab. Now, if Dependabot runs into an error when trying to open a pull request for a security alert, you can determine the reason using the GraphQL API. For more information, see "Objects" in the GraphQL API documentation.
You can now view fixed alerts from Dependabot with the GraphQL API. You can also access and filter by state, as well as by unique numeric identifier, and you can filter by state on the vulnerability alert object. The following fields now exist for a
For more information, see "Objects" in the GraphQL API documentation.
The following Git-related events can now appear in the enterprise audit log. If you enable the feature and set an audit log retention period, the new events will be available for search via the UI and API, or export via JSON or CSV.
Due to the large number of Git events logged, we recommend you monitor your instance's file storage and review your related alert configurations. For more information, see "Audit log events for your enterprise" and "Monitoring storage."
This release includes improvements to CODEOWNERS.
- Syntax errors are now surfaced when viewing a CODEOWNERS file from the web. Previously, when a line in a CODEOWNERS file had a syntax error, the error would be ignored or in some cases cause the entire CODEOWNERS file to not load. GitHub Apps and Actions can access the same list of errors using new REST and GraphQL APIs. For more information, see "Repositories" in the REST API documentation or "Objects" in the GraphQL API documentation.
- After someone creates a new pull request or pushes new changes to a draft pull request, any code owners that will be requested for review are now listed in the pull request under "Reviewers". This feature gives you an early look at who will be requested to review once the pull request is marked ready for review.
- Comments in CODEOWNERS files can now appear at the end of a line, not just on dedicated lines.
For more information, see "About code owners."
The Update branch button on the pull request page lets you update your pull request's branch with the latest changes from the base branch. This is useful for verifying your changes are compatible with the current version of the base branch before you merge. Two enhancements now give you more ways to keep your branch up-to-date.
When your pull request's topic branch is out of date with the base branch, you now have the option to update it by rebasing on the latest version of the base branch. Rebasing applies the changes from your branch onto the latest version of the base branch, resulting in a branch with a linear history since no merge commit is created. To update by rebasing, click the drop down menu next to the Update Branch button, click Update with rebase, and then click Rebase branch. Previously, Update branch performed a traditional merge that always resulted in a merge commit in your pull request branch. This option is still available, but now you have the choice. For more information, see "Keeping your pull request in sync with the base branch."
A new repository setting allows the Update branch button to always be available when a pull request's topic branch is not up to date with the base branch. Previously, this button was only available when the Require branches to be up to date before merging branch protection setting was enabled. People with admin or maintainer access can manage the Always suggest updating pull request branches setting from the Pull Requests section in repository settings. For more information, see "Managing suggestions to update pull request branches."
You can now configure custom HTTP headers that apply to all GitHub Pages sites served from your GitHub Enterprise Server instance. For more information, see "Configuring GitHub Pages for your enterprise."
It's now possible to ignore revisions in the blame view by creating a .git-blame-ignore-revs file in the root of your repository. For more information, see "Viewing a file."
A light high contrast theme, with greater contrast between foreground and background elements, is now generally available. For more information, see "Managing your theme settings."
Repository owners can now configure tag protection rules to protect a repository's tags. Once protected by a tag protection rule, tags matching a specified name pattern can only be created and deleted by users with the Maintain or Admin role in the repository. For more information, see "Configuring tag protection rules."