5 simple things you can do with GitHub Packages to level up your workflow

Whether you’re contributing to an open source project, building a personal project, or spinning up the next feature for your 9-5 job, finding (or building) the right package is , a core part of any development workflow.

Package managers and registries aren’t new. But using one often means integrating another service into your repositories and workflows.that’s why Introduced GitHub packages in 2019 Build package and container registries in all public and private GitHub repositories.

GitHub Packages helps you centralize your development workflow on GitHub by connecting to industry and community standard package managers such as npm, Gradle, Maven, RubyGems, NuGet, and even Docker and OCI for containers.

The net effect is that the package lives with the code. And its proximity is unique. It’s also very useful when it comes to providing tighter integration. Need proof? Here are some simple things you can do with GitHub Packages to level up your workflow.

1. Put the package right next to the code

When working on a project with dependencies, it’s important to make them easily accessible, usable, and visible. Often you’re using not one package, but many interconnected packages, so having a registry containing all the dependencies between the various technologies you’re using can be a lot simpler .

This is even more important for organizations with pre-approved packages that need to be used in numerous projects. Let’s name one of the great benefits of GitHub Packages. This allows the packages to persist correctly in repositories and organizations. This means one less piece of infrastructure to worry about when integrating things.

For example, say you’re working on a project whose code is in a GitHub repository and whose packages are on npm. That means you likely have several different user credentials and permissions. But with GitHub packages, you can centralize credentials and permissions across systems. Also, there is no need to build separate package registries to mirror permissions across systems and projects.

When you end up using a package, having a close relationship between the package and your code makes it easier to know what you’re using and where that package is.

Pro tip: many packages common package registryyou can easily publish packages using your preferred tool of choice and host them directly in your GitHub project.

Screenshot of Package Insights overview on GitHub.

Here’s another useful feature: All packages hosted on GitHub come with download statistics and a full history, making it easy to track usage across repositories, organizations, or the broader open source GitHub ecosystem.

Learn what GitHub packages can do >

2. Host your container registry in your repository

Here’s something interesting: GitHub Packages also supports Docker and OCI images. Own native container registrySo if any of your projects use Docker or OCI, the entire process can be published and managed (and even injected into your CI/CD pipeline via GitHub Actions). but more on that below). section).

One advantage of doing this on GitHub is that it’s quick and easy to provision containers with all dependencies in place. So if you have an organization with 50 projects, you can publish all of them via GitHub Container Registry.

Container registries also provide access policies and the ability to facilitate the use of standardized base images across your organization. This facilitates permitting and standardization enforcement across projects. GitHub Container Registry also supports layer caching, allowing you to: Quickly spin up images in your CI/CD pipelineAdditionally, GitHub Container Registry comes with more fine-grained permissions that you can use to separate package permissions from underlying source code permissions and restrict who can publish their own containers. .

And here’s one more thing: you can also access public container images anonymously. own super linterThis makes it easy to use what you need on your own terms.

Learn how to host a container registry in your repository using GitHub Packages >

Screenshot of super-linter, a public container image on GitHub.
Screenshot of super-linter, a public container image on GitHub.

Pro tip: If you’re using GitHub Enterprise Cloud, you can also create and use containers with internal visibility in your projects. This means that members of your organization or company can quickly share data via containers. See changelog for details.

3. Use GitHub Actions to automate how packages and containers are managed

If you use GitHub Packages to publish and consume your packages and containers, you can manage everything via GitHub Actions. In other words, automate the way packages are consumed, Connect them directly to your CI/CD pipeline without doing anything special.

If you’re using packages on different systems and adding containers to the mix, the ability to automate which packages are consumed by which services can be very useful and very fast. This means that for any developer or team using GitHub packages, all packages are in a repository, no need to source sources from different places, and you can build automated workflows to use and manage them at scale. increase.

A screenshot of a GitHub Actions workflow that allows developers to automate the process of publishing Docker container images.
A screenshot of a GitHub Actions workflow that allows developers to automate the process of publishing Docker container images.

Want to learn more about using GitHub Actions and GitHub Packages together? watch the video Publish to GitHub Package with Actions on YouTube.

Learn more about publishing, consuming, and installing packages with GitHub Actions >

4. Use GITHUB_TOKEN to secure how you manage your packages and containers with GitHub Actions

If you’re using GitHub Actions to automate package management across your projects, there’s something you should do now: use GITHUB_TOKEN to reduce the attack surface of your development pipeline.

GITHUB_TOKEN is a special access token that can be used with GitHub Actions. Each token is automatically generated for every job that requires authentication or installation access. And once that job is done, the token automatically expires, mitigating potential risks.

Simply put, when you run a workflow, the token only exists until the workflow completes, after which it is deleted. Other solutions may have long-lived tokens. If you don’t rotate that token, it can expire and cause problems.

GitHub tokens for action workflows can be published to GitHub packages by default. The net benefit is that using GITHUB_TOKEN to reduce your attack surface gives you a more secure system.

Learn how to use GITHUB_TOKEN in your workflow >

5. Create a private GitHub repository with a private package registry

A free GitHub account allows you to host an unlimited number of public packages in any public repository. However, GitHub Packages also works for private repositories for free, with 500MB of storage and 1GB of transfer (which is enough storage to host 331,000 pages of YAML. we did the math right).

Packages on GitHub inherit the visibility and permissions of the repository in which they’re stored. This means that a private package registry is immediately created in your spun-up private repository.

Net income: You can create private repositories with private packages and not worry about them being shared publicly.

Learn more about using private packages on GitHub >

Get started with GitHub packages

GitHub packages are available to all organizations on GitHub and can be leveraged by all repositories within a given organization. To get started, Check out the GitHub documentation. 5 simple things you can do with GitHub Packages to level up your workflow

Back to top button