If you manage more than a few GitHub repositories, you’ll know that it takes conscious effort to keep them updated. Your project’s dependencies and Gradle version go out of date fast, and probably without you realising. Scale up to 50+ repositories, and you’ve got a big time drain on your hands.
Fortunately, GitHub has features to help. In this article, you’ll discover 3 ways to save time and get organised with your Gradle projects in GitHub.
Developers live in a chaotic world
Popular libraries frequently release new functionality, bug fixes, and security patches. For example, the Spring Boot framework makes at least one release per month.
How will you make sure your project’s always on the latest version?
In my experience, this problem is hard to solve. At least in a non-automated way.
Even if you schedule events in your calendar to manually update everything, they’ll likely be ignored in favour of today’s priority item. Keeping dependencies up-to-date is something we know we should do, but it’s never important enough to do right now.
Frequent Spring Boot releases (from mvnrepository.com)
And what about the Gradle version?
Sure, it’s easy to update on a single project by running the wrapper task, but someone needs to remember to do it. The Gradle team frequently release new features and optimisations, which you’ll want to take advantage of.
Will you do that manually on every single project? Doesn’t sound like much fun.
A GitHub chaos scenario
I recently found myself in a similar situation with 63 GitHub repositories, some of which hadn’t been updated for years. Not only that, but I didn’t have a way to easily organise them into groups that make sense to me.
In the midst of chaos, there is also opportunity.
Sun Tzu
As software developers, we like to automate solutions to problems rather than do tedious work. That’s literally what software does. This frees our time for higher level tasks.
Updating and organising your GitHub repositories is no exception, so let’s bring order to the chaos with 3 awesome GitHub features!
1. Update dependency bot
In any GitHub repository you can enable Dependabot. This bot runs intermittently in the background, and opens pull requests for any dependency versions that need updating.
It’s really simple to add to a Gradle project. Just drop the following dependabot.yml file into a .github directory.
version: 2
updates:
- package-ecosystem: "gradle"
directory: "/"
schedule:
interval: "daily"
Once you push this file, GitHub schedules daily checks on dependencies declared in Gradle build scripts. For each dependency that isn’t on the latest version, it creates an individual pull request.
The cool thing is that each of these pull requests can trigger a GitHub workflow, so you can test that each suggested version update is compatible. In the example above, 2 of the 3 pull requests passed my tests. I can merge them right away, while fixing the failure manually.
Hopefully you see the power of this?
Assuming you’ve got alerts enabled, you’ll get a PR for any new dependency version release within 24 hours. To make things less noisy, you can set a schedule of weekly or monthly.
It’s also worth knowing that Dependabot:
-
supports Groovy and Kotlin build scripts
-
has many configuration options, like ignoring certain dependencies or versions
-
doesn’t yet support Gradle version catalogs
2. Lists to organise your repositories
It’s unfortunate that a repository system like GitHub doesn’t provide a really nice view of all your repositories.
The default view isn’t bad. But when you’ve got 50+ repositories, browsing them in GitHub becomes overwhelming. There’s no easy way to group repositories, other than by language or type (public, private, etc.).
Viewing your repositories in GitHub
In my case, I have repositories for Gradle tutorials, Gradle plugins, my website, and so on. I want to view repositories by category, not as a single, seemingly endless list.
During my research, two GitHub features were suggested to solve this problem:
-
GitHub organizations felt overly complicated, and involved moving off the free-tier
-
GitHub projects actually organises issues rather than repositories
After almost giving up my search, finally I discovered Lists. This feature lets you create lists and add repositories to them. Voila! 👏
Lists are integrated into the Stars area of GitHub, so you can think of a list as a specific type of star.
Just hit the Create List button to get started:
Now, from any repository page click the Starred button and select a list.
On the Your stars page, I now have all my repositories organised into an appropriate list. Neat!
And of course, you can select an individual list to see which repositories it contains.
Some other points to note about lists are that:
-
repositories can be in multiple lists
-
lists appear on your public profile page at
https://github.com/USERNAME?tab=stars -
lists is currently a public beta feature, so is subject to change
3. Auto-update Gradle action
It’s a pain to update all your repositories manually when a new Gradle version is released. Instead, automate the process with the Update Gradle Wrapper Action.
An action is a specific step you add to a GitHub workflow, which does some useful work (see this article on building Gradle projects with GitHub actions). The Update Gradle Wrapper Action checks the current Gradle version and updates the wrapper to the latest version when necessary.
To add this feature into your Gradle project, create the following update-gradle-wrapper.yml workflow file in the .github/workflows directory.
name: Update Gradle Wrapper
on:
schedule:
- cron: "0 0 * * *"
jobs:
update-gradle-wrapper:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Update Gradle Wrapper
uses: gradle-update/update-gradle-wrapper-action@v1
When you push this change, GitHub runs the workflow every day at midnight. If a new Gradle version is available, the action creates a pull request, much like Dependabot we discussed earlier.
Unfortunately, when the action creates this pull request, associated workflows don’t run automatically to test the changes e.g. a workflow to verify ./gradlew build succeeds. A workaround is to close and reopen the pull request, which then runs the workflow.
That’s what I did to this pull request, which now has that comforting green tick.
When you’re happy, merge the changes to incorporate the new Gradle version into your main branch.
You now know 3 ways to organise your Gradle projects in GitHub:
-
Dependabot
-
lists
-
the Gradle Wrapper Update Plugin
In my experience, these features are super-easy to incorporate into a project. Why not try one with your own repositories?
Stop reading Gradle articles like these
This article helps you fix a specific problem, but it doesn't teach you the Gradle fundamentals you need to actually help your team succeed.
Instead, follow a step-by-step process that makes getting started with Gradle easy.
