GitHub Enterprise Server 2.18 is here, offering simplified project management and enhanced security features to the company’s commercial users.
With more and more businesses trying to take security into account in an earlier stage of their product development process, GitHub tries giving devs a leg-up by expanding its support for dependency graphs. Devs working with Enterprise Server and using Yarn to manage dependencies will now receive security alerts if the system finds vulnerable dependencies listed in a yarn.lock manifest.
Admins can also follow changes made to settings and memberships and see if PAT and SSH are used to access an organisation’s information. They also get access to the repository template feature that made its way into regular GitHub in early June 2019. It basically lets admins mark existing repositories as templates, so that people with access to those repositories are able to generate new ones with the same directory structure and files.
Version 2.18 lets you transfer an issue between repositories, should you need, but not moving issues from a private to a public repository. If the issue is housed in a repository that belongs to a private organisation then its new home has to be part of that organisation, too.
Apart from that, maintainers with write access can now assign issues or pull requests to anyone who commented on them without taking membership or other permissions into account, and issues and PRs will sport the name of the milestone they belong to in the project card. The latter comes in tow with options for adding and removing these artifacts to and from milestones and a way of filtering project cards by milestone in the search bar.
While GitHub seems to merrily grow under Microsoft (the project even works on its own registry), rival Bitbucket appears to be more on a slim down-and-focus course. Atlassian just announced the removal of Mercurial features and repositories from both Bitbucket and its API on 1 June 2020. The move was explained with the version-control tool losing traction while binding resources necessary to build new quality features. Stepping away from Mercurial is meant to help the Bitbucket team to: “Focus on building the best possible experience” as it scales.
Up until now, Bitbucket was the only one of the three big distributed repository management services that offered official support for Mercurial, although GitHub at least developed a plugin to us Hg in concert with Git server repositories. Discussions about adding ways to work with Mercurial to GitLab are still in progress, mainly driven by the existence of the Heptapod fork that offers such a thing. Given this has already been going on for two years, it remains to be seen if Atlassian’s move is going to speed up the process and makes GitLab step up.