Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
GitHub Enterprise Server 3.7 is available now, including a single view of code risk, new forking and repository policies, and security enhancements to the management console.
GitHub Enterprise Server 3.7 is now generally available. This release continues our trend of bringing record numbers of new features to our GitHub Enterprise Server (GHES) customers, designed to enable developers to build every day while providing administrators with tools to run GitHub Enterprise at scale, with reliability at its heart.
Highlights of the GHES 3.7 release include:
Download version 3.7 now, and, for help upgrading, use the Upgrade Assistant to find the upgrade path from your current version of GHES to this new version.
GiHub Actions is the developer automation tool, designed to make it easy to automate any workflow and share those workflows easily across teams. Released initially in GHES 3.5, reusable workflows enable enterprise developers to share workflows within a company and enforce their usage across projects.
This release brings two major enhancements to reusable workflows that make it easier for teams to share automation:
Companies using GitHub Pages can also now deploy those pages directly from a repository using GitHub Actions—so you can use GitHub Actions as a single CD provider for your apps and GitHub Pages, with deployment gates and environments built in.
With GHES 3.7, administrators can configure Google Cloud Storage for GitHub Actions to store logs, artifacts, and caches from a server instance, set up directly from the management console.
GitHub has long been the platform for sharing code across companies, and enabling teams to innovate faster by breaking down organizational silos. To make it easier for any developer and company to adopt innersource practices, while balancing security and auditability, GHES 3.7 brings a wealth of enhancements to the forking experience, forking policies and repository creation policies. Here are a few examples.
When enterprise developers create repositories in their personal namespace, administrators can be left with long-term problems: from a lack of auditability and policy enforcement to long-term maintainership problems when developers leave. A powerful new forking workflow helps to address this challenge, backed by two new enterprise policies for administrators.
Developers can now fork a repository into the same Organization and name the fork at the same time. The fork will retain the same visibility as its upstream repository, whether that’s private, public, or internal.
And administrators can enable two enterprise-wide policies that ensure all new repositories are owned by compliant, auditable organizations: they can restrict new repositories to Organizations only, and they can restrict forks to Organizations, too. Together, these changes are designed to make it easier for any company to innovate with innersource.
Identity providers, such as Azure Active Directory and Okta, are often the best source of the truth for which employees should have access to a GHES instance and what team they’re in. Today, administrators can configure SAML SSO with an identity provider, but offboarding and team management are completely separate. That can result in duplicate work, and complex time-sensitive offboarding processes.
This release includes a private beta of SCIM user management, which allows administrators to provision and suspend user accounts in fully automated fashion via the new SCIM APIs, and populate team membership—- directly from your identity provider. Read more about the SCIM APIs, or reach out to your account manager to try the private beta now.
Meanwhile, the management console has just gotten a security facelift, with stricter password policies and a complete audit log.
Every enterprise customer now has access to security overview, which provides a centralized view of your security posture across the entire enterprise. Application security teams, engineering leaders, and developers can see Dependabot alerts, code scanning and secret scanning alerts, and more, all in one place. You can find the security overview in the Code Security tab of the enterprise account:
GitHub’s dependency graph automatically scans most popular manifest formats, but some manifests like those from Gradle, Scala SBT, or Maven either cannot be scanned statically, or do not include transitive dependencies automatically. The dependency submission API allows CI workflows to submit dependencies from recent builds to GitHub’s dependency graph in the form of a simplified software bill of materials (SBOM). These dependencies are then visible in the GitHub dependency graph and can generate Dependabot alerts for vulnerabilities. To learn more about expanding the dependency graph with the submission API, read here.
To make it even easier to assess the impact of security vulnerabilities, we are making code scanning alerts more collaborative, accessible, and relevant. We now display security alerts on the pull request’s Conversation tab by adding them as interactive annotations. Developers can comment on these annotations and continue to use all existing functionality to effectively triage the alert (including show paths, dismiss alert, and show details):
To learn more about GitHub Enterprise Server 3.7, read the release notes, and download it now.
Not using GHES already? Start a free trial to innovate faster with the platform developers know and love.
