My previous blog looked at some of the new features of GitHub, namely GitHub Actions. This time, I shall be taking a look at another recently introduced feature; the GitHub Package Registry.
Packages are collections of code, scripts and other resources. They provide specific functionality which can be downloaded and bolted onto an application. In a world of increasingly complex IT, this has to be managed using some sort of registry.
GitHub Package Registry
GitHub Package Registry is a software package hosting service. It’s similar to npmjs.org, rubygems.org and hub.docker.com. It allows you to host all your packages and code in one place. You can host them privately or publicly and use them as dependencies in your projects.
Without a package registry, you would have to maintain different sets of user credentials and permissions. Now you can use a single set of credentials across both, and manage access permissions with the same tools. Packages on GitHub inherit the visibility and permissions associated with the repository. Organisations no longer need to maintain a separate package registry and mirror permissions across systems.
For Inner Source too
Like Actions, the Package Registry is a valuable resource for internal teams as well as those working with open source. Package Registry makes it easy to use the same familiar GitHub interface to find public packages anywhere on GitHub. You can work with private packages within your organisation or repositories in exactly the same way.
You need to be able to trust the packages your project depends on. It’s important you can understand the code and where necessary, connect with the community that put it together. For internal projects, that means being able to find what’s been approved for your use. GitHub can assist with this.
Package Registry allows you to collaborate with packages of built code, especially Docker containers which is now becoming mainstream. It’s useful to build and test Docker packages and work with them on GitHub during the dev phase until you’re ready to release them on Docker Hub.
The registry is fully integrated with Actions. This will allow you to automate and build extra utility around the packaging process. For example, if you’re working with Docker you can use Actions to create a container and push the build up to the Package Registry.
GitHub automates some of things which can make it difficult to ensure software remains secure when it’s being worked on and updated. GitHub maintains a database of known vulnerabilities and will let you know if the software you depend on has been updated. It will examine your code and alert you if any associated dependencies have a security vulnerability. And GitHub doesn’t stop there. As shown below, it can fix things too! It can send a pull request to mitigate the security issue at the press of a button.
In the example above, GitHub detects a critical security vulnerability in a .json package (called lodash) prior to version 4.17.3 and recommends an upgrade to the secure version. Details of the vulnerability are provided. The option to allow GitHub to fix the issue appears in the top right hand corner. I’ve used a bit of artistic licence here to ‘cut and paste’ the ‘fix it’ button into the frame of the illustration. In real life, it sits just above the report shown above.
GitHub allows internal teams to work with the open source collaboration model regardless of whether or not the project involves open source software. GitHub Enterprise licences provide extra layers of security, flexibility and functionality for enterprise level requirements. These are likely to involve larger (and possibly distributed) teams working on more critical business applications. Grey Matter can supply licences for this.