Can you automate dependency management?

Spoiler alert…. Yes you can, and that’s what we’re going to do in this, the first tutorial in a series of Renovate dependency management tutorials. 

At one point or another, you’ve been responsible for managing the third party code or publicly available docker images used in your projects….. If you haven’t, why on earth are you reading this article?

Recently I built out infrastructure for our team which included a self hosted Forgejo git instance. Forgejo is a fork of GitHub (well, a fork of Gitea, which is a fork of GitHub) so its CI/CD tool, Forgejo actions, is very similar (almost blooming identical in truth) to GitHub Actions. As a certified github actions engineer, this was music to my ears. What I did find a little frustrating though, is that some of the github native tools, like Dependabot, obviously aren’t available in Forgejo. That’s where Renovate comes in. Throughout this article/ tutorial, I’ll walk you through how you can set up Renovate in a relatively simple, safe way, completely free of charge and without messing up your repos. You’ll get dependency management for almost all of your dependencies. For the other few more unique dependencies, my later blog posts will explain how to create custom configurations to update ANY dependency. You can use renovate on github, gitlab and bitbucket too, but these instructions are specifically for Forgejo.

To get started you just need 3 things:

• A Forgejo (or Gitea) instance

• Actions enabled with a runner configured (follow this first if not)

• Admin account for Forgejo / Gitea

Step 1

Log into the admin account and go to the menu in the top right hand corner (click your avatar). 

Select:  Site Administration > Identity & access > User accounts

From here you make a new user called "renovate-bot". For the email, I simply put my current email and used the Google Mail ‘+’ trick. This new account will be used by Forgejo to create the PRs etc. You could, in theory, use another account that already exists but this is a nice way to separate the concerns and ensure that it’s really obvious that the bot has made changes. Also, the docs suggest you should do this, so who am I to argue with them?

Step 2

Sign out of the admin user and login into the new ‘renovate-bot’ account.

Select: Settings > Applications > generate a new Access Token. Call the token whatever you want and save the key somewhere.

Step 3

Now you can log out of the ‘renovate-bot’ account and log back into your normal user account. We now need to create a repo that will do all the heavy lifting. It doesn’t need much in it, just 2 files actually. I called it ‘renovate-config’ because, again, that’s what the docs suggested I should call it. I know, very creative.

I pushed 2 files to the new "renovate-config" repo:

1. config.js - This tells renovate where the API is and which account should raise the PRs / do the magic. I set autodiscover to true, because I want Renovate to go out and find all my repos. Without this, I would need to manually add a JSON file to my repos before Renovate will see them. It seems counter intuitive to give myself some manual steps when configuring a tool designed to remove manual steps… I also set optimizedForDisabled to true, too. If you want to understand what this does, read this.

2. forgejo/workflows/renovate.yml - This is the actions workflow. It’s the pipeline definition for Renovate. As far as Actions workflows go, it’s about as simple as it gets. We give the workflow a name, define that it can be run manually using the workflow_dispatch syntax, set it to run every day with the schedule syntax & set it to run if any push to the main branch occurs. We then define what will happen if any of those conditions are met. Namely, it’ll run on our self hosted runner which, imaginatively, I called Docker back when I set it up last year. I then define that I want to use the Renovate bot container image, use a reusable GitHub actions workflow to checkout code, tell the workflow what scope it has and finally, tell the workflow which secret it should use to have the permission to use the bot account.

Step 4 

Our last step is to create the repository secret that we reference in the last step. For this, we’re going to take the key we generated in step 2 and save that value to the variable name we set in the last step. 

In the repo, go to Settings > Actions > Secrets.

Create a secret named RENOVATE_TOKEN and set the value to the key we generated earlier in the code you saved at step 2.

Now you’re all set up.

In a nutshell, out of the box, here’s how it works after following this tutorial:

The ‘renovate-config’ repo runs an intuitive tool designed to:

• Dig through target repositories

• Find dependency definition files

• Go out to the source of those dependencies and find out if there are updates available

Raise a PR in order to update the dependencies to the new version

The bot will run when you first merge the code for the renovate-config repo. It will pick up all repos within the scope (as configured in the tutorial), including the repo you’ve created for Renovate, providing that’s in scope too.

Right now, if we specifically focus on the renovate-config project (the one we create in the tutorial), you’ll notice that a pull request was raised against this repo, on a new branch. If you inspect the PR a little, you’ll see a stock “Welcome to renovate” block. This is the first PR that renovate will raise and it will show the dependency definition files it has found including Dockerfiles, other files that have Docker images defined, node dependency files, Python files, you name it. Renovate will then tell you what it has found within those files where there is a new version available. 

If we close this PR at this stage, we’ll never hear from Renovate on this repo again. If we merge the PR, it will go ahead and begin managing this repository, raising further PRs with suggested dependency upgrades. In addition to the above info in the PR, you'll see a new file called 'renovate.json'. This file is essentially the green light for Renovate to go ahead and start raising PRs to upgrade dependencies. Without this file the bot cannot begin raising these PRs.

Crucially, at this point, if you approve this first PR, it will begin to raise 2 PRs per hour, every hour (that can be changed but this is the out of the box behaviour) with a view to updating all dependencies that you are happy for it to approve and on an ongoing basis. It will keep track of what is outdated and aim to bring everything up to date.

What you’ll notice from my screenshot is that the first PR already noticed that there was a new version of Renovate available. In my original renovate.yml I had defined an old version (because a tutorial I followed was from 2024). Proof here that it gets to work instantly. 

It can be further configured to ignore specific things (like if we don’t want to update a particular image / package) OR configure it to look out for specific things, but out of the box, this is how it will work.

One ‘Gotcha’ i ran into was this: You can quickly end up with merge conflicts if multiple PRs are raised on a particular file (think about a requirements.txt file for a python project, where you have multiple dependencies that are out of date). For this, my work around was to add  "rebaseConflictedPrs": true, to the target repository’s renovate.json file. This file is automatically generated by Renovate so don’t worry, you haven’t missed the step where we created it. You simply need to edit that file. When this is enabled, there will be a check box on PRs which can be used to rebase the PR.

I then rerun the ‘renovate-config’ workflow and the PR is updated and rebased, avoiding the merge conflict.

Things to note

• Renovate will only look at the main branch by default. This can be changed as set out in this article.

• We can decide how often the tool will check for updates. This can be set to any frequency via cron expression. In this tutorial we set it to 'daily' but feel free to play around with hourly, too, if you’re not very busy...

What’s next in this series? Next we’ll look at custom datasources and custom managers to help us to help renovate in managing Oracle resources such as Oracle APEX, ORDS & SQLCL. After all, if RADAPEX can’t configure an automation tool to manage Oracle dependencies, what on earth are we doing here??