GitHub Enterprise Server 2.18: What’s New

GitHub released Enterprise Server 2.18, bringing a set of improvements focused on security, project management, and repository administration for commercial users hosted on self-managed GitHub infrastructure.

Expanded Dependency Security Alerts

With “shift left” security becoming a standard expectation in modern development workflows, GitHub expanded its dependency graph support in this release. Developers using Yarn to manage JavaScript dependencies on Enterprise Server will now receive security alerts when vulnerable packages are detected in a yarn.lock manifest file. This extends the same dependency vulnerability scanning that was already available for other supported ecosystems.

Audit Log Improvements for Admins

Administrators gain better visibility into activity across their Enterprise Server instance. Specifically:

• Admins can now track changes to organisation settings and membership.
• Usage of Personal Access Tokens (PAT) and SSH keys for accessing organisation data is now logged and auditable.

These additions give security and compliance teams a clearer picture of how and by whom organisational resources are being accessed.

Repository Templates

Enterprise Server 2.18 includes the repository template feature, which arrived on GitHub.com in early June 2019. Admins can mark any existing repository as a template. Users with access to that template repository can then generate new repositories that inherit the same directory structure and files — useful for enforcing consistent project scaffolding across teams without manual copying or external tooling.

Issue Transfers Between Repositories

Version 2.18 introduces the ability to transfer issues between repositories. There are constraints worth noting:

• Issues cannot be moved from a private repository to a public one.
• If the source repository belongs to a private organisation, the destination repository must also be within that same organisation.

Project Management Enhancements

Several quality-of-life improvements landed for teams using GitHub Projects and milestones:

• Broader assignment options: Maintainers with write access can now assign issues or pull requests to any user who has commented on them, regardless of whether that person is an organisation member or has specific repository permissions.
• Milestone labels on project cards: Issues and pull requests displayed as project cards now show the name of the milestone they belong to.
• Milestone management from project boards: Users can add or remove items from milestones directly within the project board view.
• Filter by milestone: The project board search bar now supports filtering cards by milestone.

Bitbucket Announces End of Mercurial Support

While GitHub continued expanding its feature set under Microsoft ownership, Atlassian made a notable strategic decision around the same time: Bitbucket would drop all Mercurial support — including Mercurial repositories and related API endpoints — effective 1 June 2020.

Atlassian’s stated rationale was that Mercurial had been losing adoption across the industry, and that maintaining support for it was consuming engineering resources that could otherwise go toward improving the Git-based experience. The announcement framed the decision as a way for the Bitbucket team to “focus on building the best possible experience” as the platform scales.

What This Means for the Broader Ecosystem

At the time of this announcement, Bitbucket was the only one of the three major hosted repository platforms — GitHub, GitLab, and Bitbucket — to offer official, first-class support for Mercurial. GitHub had at some point maintained a plugin to enable Mercurial use alongside Git repositories, but that was not a native offering. GitLab did not support Mercurial natively either, though discussions had been ongoing, partly driven by the community-developed Heptapod fork — a GitLab fork with Mercurial support built in.

With Atlassian removing official support, the question became whether GitLab would accelerate its own Mercurial plans or whether Mercurial users would need to migrate to Git workflows. Heptapod remained the most practical path for teams determined to stick with Mercurial on a self-hosted GitLab-style platform.

Key Takeaways for DevOps Teams

• Yarn users on GitHub Enterprise Server should ensure their yarn.lock files are committed to repositories so they benefit from the new vulnerability alerts.
• Enterprise admins should review the expanded audit log capabilities to strengthen access governance and support compliance requirements.
• Mercurial users on Bitbucket should plan a migration to Git before the June 2020 cutoff (note: this cutoff has now long passed).
• Teams evaluating self-hosted Mercurial alternatives should assess Heptapod as a community-supported option.