Publishing Artefacts to GitHub Packages With Gradle
An experiment for an alternative Maven Central continues …
As a developer, I’m always looking for a convenient place to provide my open-source tools, libraries and/or projects. When I read GitHub Packages’ slogan, “Your packages, at home with their code.” I got motivated to evaluate it as a public repository for my packages. The following article is about my premier excitement and induced disappointment.
Following is a how-to guide and a bit of recommendation on how to use it.
Before we can jump in, there are some preconditions. And I assume that if you found this guide, you do
- have a basic understanding of Gradle.
If not, please read first: https://tomgregory.com/gradle-tutorial-for-complete-beginners/*
- have a registered GitHub Account and a basic understanding of Git
If not, please read first: https://www.freecodecamp.org/news/the-beginners-guide-to-git-github/
*I’m no advocate nor paid to list these links here. I don’t even earn anything if you click on them. I googled them or had them in my bookmarks. So it is truly here to assist you, chosen by my personal bias as a developer. Feel free to get the required know-how anywhere else, as you desire; disclaimer end.
Service: GitHub Packages
As I focus on open-source, we can easily see that GitHub Packages are free for public repositories. Otherwise, it comes with costs. But please think at this point about the potential risk of vendor lock-in.
Open the following web link for more information: https://github.com/features/packages#pricing
Let’s get started! 🥳
You will need a token with the following permissions to create and use artefacts on GitHub Packages.
GitHub will then automatically check the other needed permissions for you. Which are:
If you need help on how to create a token, here comes a guide to help:
Creating a personal access token — GitHub Docs
If you use GitHub CLI to authenticate to GitHub on the command line, you can skip generating a personal access token…
Artefact Producer Side
To successfully publish artefact, the only other thing you have to do is to define the repository as stated in the my example underneath:
Replace viascom with your GitHub user or organisation name and aluna-spring-boot-starter with your project name.
Note: If you need to get to know the basics of publishing: here is my complete guide on that topic:
Complete Guide: Publish with Gradle to Maven Central (native)
Do you remember your first time publishing a library on Maven Central? — If you don’t or never had to until now…
Artefact Consumer Side
It’s even easier to make use of a published artefact. Once again, following my
build.gradle configuration part. And again, replace
viascom with your GitHub user or organisation name.
Problem: Own repository definition for each artefact
Usually, you would point to a repository with the URL. And the official GitHub Packages documentation suggests its use as follows:
url = uri("https://maven.pkg.github.com/OWNER/REPOSITORY")
But this would come with the downside: That you can’t just use a shared repository definition block in all your projects and fetch those artefacts. And you would have to add for each artefact you like to add a repository configuration too. It’s just awful, from my point of view.
I experimented and figured out that you can use the asterisk at the end of the URL instead of the project/repo name.
url = uri("https://maven.pkg.github.com/OWNER/*")
At the beginning of this experiment, I was hyped to have something easy to use next to my code and hopefully easy to share with my audience. Unfortunately, I got disappointed by the following facts and have not found an alternative for Maven Central with GitHub Packages.
Issue 1: Only authorised access is allowed to the repository
Even though I can reach the artefacts and download them over a browser by f.e. visiting, in my case, the following URL: https://github.com/viascom/spring-boot-starter-maintenance/packages/1424240, I can’t use the corresponding repository without authorisation.
Results in the need for a registered GitHub user account and the issuing of a personal access token (by the user) for everyone willing to use my library,
Issue 2: Need to specify the Maven-repository user/organisation specific
To have the repository ready for use, we must specify its configuration. There is nothing wrong so far, but to use them from GitHub Packages, we have to do this several times for each user and each organisation we plan to use dependencies.
I would have appreciated a global GitHub Packages repository. Usable for anyone without a login, and only the publishers would have to own an account and stick to the registered group ids.
Benefit 1: Shared libs within the same organisation
Still, I found one valid use case, which I will continue to use: Sharing private artefacts across our organisation. It is straightforward to publish, and with a common parent-pom, the organization-specific URL with the asterisk-hack is convenient.
I’m always trying to live from the earnings I make by doing stuff I sincerely love ❤️. Writing tech articles 📝 become one of those things I’m passionate about. If my article supported you, I would be honoured to receive a tip ☕.
Your donation would enable me to spend even more time writing such articles and boost my motivation. Follow me here on Medium for more tech articles and bonus material 😃.
Following is the link to support me or to say thanks by buying me a coffee: https://ko-fi.com/botscripter
References, Useful links
- GitHub Packages, Working with a GitHub Packages registry