Blog Infos
Author
Published
Topics
, ,
Published

Let’s suppose you have a big project, which contains multiple dependencies. Some of them are created by you and they are hosted in separate GitHub repositories. These dependencies have their own dependencies and from my experience, in most cases you forget to maintain them up to date. It becomes a big problem if there’s any bug inside this dependency and you have to find a suitable combination of the inner dependencies to make the dependency build again. Here’s the way how I solved this issue for myself.

Part 1 — Integrate Renovate inside the main project

Renovate is a service that provides a bot which is integrated in your, for example, GitHub repository, and does the following:

  1. Scans your repositories to find package files and their dependencies
  2. Checks if any newer versions exist
  3. Raises Pull Requests for available updates

Here’s the docs about how it can be integrated into your repository. Spoiler — there’s nothing difficult in it. After this step our main repository would start to receive the updates of dependencies.

Part 2 — Create a GitHub action to build (and test) the PR with update inside the dependency repository

For me the most suitable solution is to use GitHub Actions as a CI tool since it provides unlimited usage for open-source projects and it works in cloud. Here’s the script I use to build the PR:

name: Validate PR
on:
pull_request:
branches:
- 'master'
jobs:
build_project:
if: startsWith(github.head_ref, 'renovate')
runs-on: macos-latest
steps:
- name: Checkout
uses: actions/checkout@v4.1.1
- name: Setup java
uses: actions/setup-java@v4
with:
distribution: 'temurin'
java-version: '17'
- name: Build
run: |
./gradlew :dependency:build --no-daemon
view raw build_pr.yml hosted with ❤ by GitHub

As you can see, script is pretty simple — it builds only PR’s into master branch from the branches, which name starts with renovate. You can use any system image you need, since I build KMP libraries, I need to use the macOS. Then the machine downloads the repository, setups Java and just builds the artefact (in case you have tests you can run them too). If this stage is finished successfully the dependency is ready to merge.

Part 3 — Integrate the Renovate inside the dependency project

There’s nothing interesting at this stage, it is the same as Part 1, but in another repository.

Part 4 — Create a GitHub action to build and publish the new version of the dependency

I created the following action for it:

name: Publish new version
on:
push:
branches:
- 'master'
jobs:
build_project:
runs-on: macos-latest
env:
GITHUB_USER: ${{ secrets.GITHUB_USER }}
GITHUB_API_KEY: ${{ secrets.GITHUB_API_KEY }}
steps:
- name: Checkout
uses: actions/checkout@v4.1.1
with:
fetch-tags: true
fetch-depth: 0
- name: Setup java
uses: actions/setup-java@v4
with:
distribution: 'temurin'
java-version: '17'
- name: Set version
run: |
VERSION=$(git describe --tags `git rev-list --tags --max-count=1`)
major=$(echo $VERSION | cut -d'.' -f1)
minor=$(echo $VERSION | cut -d'.' -f2)
fix=$(echo $VERSION | cut -d'.' -f3)
echo "LIBRARY_VERSION=$major.$minor.$(($fix + 1))" >> "$GITHUB_ENV"
- name: Build and publish
run: |
./gradlew buildAndPublish --no-daemon
- name: Create tag
uses: actions/github-script@v7.0.1
with:
github-token: ${{ env.GITHUB_API_KEY }}
script: |
github.rest.git.createRef({
owner: context.repo.owner,
repo: context.repo.repo,
ref: 'refs/tags/${{ env.LIBRARY_VERSION }}',
sha: context.sha
})

Let me explain what this action does. It triggers on each push into master. Then it sets the environmental variables from secrets (I need them to publish the artifact). Next two steps are similar to the previous script. Stage Set version is quite interesting — it fetches the latest tag (which has format minor.major.fix, i.e. 1.2.3) and increments fix version. It allows to create an updated version number. Note — presumably I had to create the first tag manually. Build and publish stage invokes buildAndPublish task, which combines two tasks inside — build and publish, as you can understand :). After the artefact is published, the latest stage is invoked — create new tag in GitHub repository (i.e. 1.2.4).

Part 5 — Handle the PR with dependency update in the main project

When the new version of the dependency is published, Renovate creates a PR with its’ update inside the main repo and here you are free to validate it as you wish.

So, as a conclusion, let’s describe an old and new processes.

Old process was the following: look for the inner dependencies update (manually) -> validate them (manually) -> merge into main branch of the dependency project (manually) -> publish new version (manually) -> validate new dependency version in the main project.

New process looks like this: look for the inner dependencies update (automatically, by Renovate) -> validate them (automatically, by GitHub Action) -> merge into main branch of the dependency project (manually) -> publish new version (automatically, by GitHub Action) -> validate new dependency version in the main project.

I hope that this article increases your development speed!

Thank you for reading! Feel free to ask questions and leave the feedback in comments or Linkedin.

This article was previously published on proandroiddev.com

Job Offers

Job Offers


    Senior Android Engineer

    Carly Solutions GmbH
    Munich
    • Full Time
    apply now

    Senior Android Developer

    SumUp
    Berlin
    • Full Time
    apply now

OUR VIDEO RECOMMENDATION

,

From Chaos to Consistency: Managing Build and Release for 25+ Android Repos with Github Actions

Managing the build and release process for over 25 Android repositories can be a daunting task. With each repository having its own pipeline or workflow, it can become difficult to ensure consistency and quality across…
Watch Video

From Chaos to Consistency: Managing Build and Release for 25+ Android Repos with Github Actions

Shrikant Ballal
Staff Engineer
YML

From Chaos to Consistency: Managing Build and Release for 25+ Android Repos with Github Actions

Shrikant Ballal
Staff Engineer
YML

From Chaos to Consistency: Managing Build and Release for 25+ Android Repos with Github Actions

Shrikant Ballal
Staff Engineer
YML

Jobs

YOU MAY BE INTERESTED IN

YOU MAY BE INTERESTED IN

blog
Using annotations in Kotlin has some nuances that are useful to know
READ MORE
blog
One of the latest trends in UI design is blurring the background content behind the foreground elements. This creates a sense of depth, transparency, and focus,…
READ MORE
blog
Now that Android Studio Iguana is out and stable, I wanted to write about…
READ MORE
blog
The suspension capability is the most essential feature upon which all other Kotlin Coroutines…
READ MORE

Leave a Reply

Your email address will not be published. Required fields are marked *

Fill out this field
Fill out this field
Please enter a valid email address.

Menu