Photo by Headway on Unsplash
Github Actions is one of the most useful things to come out for developers in a long time as they’re cheap and incredibly flexible. Allowing for code to configure the continuous integration service with reusable docker services is quite the game changer. Often we just look to use Github Actions to simply check the quality of commits and pull requests but then overlook just how extensively they can be used for other things.
There’s also another feature in Github often under utilised within repositories, and that is Dependabot for version update. Dependabot is pretty neat in that it supports most package dependencies including my two most needed as a Laravel developer which is PHP’s Composer and Node’s NPM.
Please note if you’re totally new to using Github actions or Dependabot, this article might be a bit overwhelming and will potentially require a bit of additional research.
Configurating Dependabot to create PRs
Setting up dependabot within a GitHub repository is reasonably straightforward. In fact I’ll share an example from one of my projects below:
We only need to create a .github folder and commit the dependabot.yml config into our project. From there dependabot will begin to create new PRs.
You’ll see from the config it includes GitHub actions themselves being updated as well as both composer and npm.
This config is quite a large step in that it will start producing lots of PRs and this might be too noisy for a lot of teams. One thing that you may want to do is look at what configuration options look right for your project and team.
One such option is a versioning strategy. A versioning strategy will give you the advantage of being able to set it so that NPM and Composer are only updated from the lock file which would be the standard practise for most commercial projects. Without this Dependabot will upgrade packages directly in composer.json and package.json, even if you have fixed a dependency to a particular patch or minor version.
You may want to only look at updating for one package, for instance, just Laravel and none of the other dependencies. This is also possible by setting up allow options on each repository. This can help in reducing some of the noise from dependabot. Another thing is potentially changing the schedule.interval to weekly instead of daily as it’s rare that changes to Laravel will happen that quickly.
One last thing to point out from my example is that private repositories are possible to set up as well. For instance if you use Laravel Nova or Spark, you’ll be used to this process but maybe don’t know how to configure it for dependabot. All you need to do is setup secrets in your GitHub repository which you likely already have for any CI processes and then configure the registries to be used. If you’re using my example and don’t need Laravel Spark you should remove this from the config.
Automating the merging of Dependabot PRs
Now the next part is for those who really really trust their CI processes. We can actually make all of our dependabot PRs auto merge, once all of our CI checks have passed on the PR, of course.
The following is a GitHub action config we can create inside the .github/workflows folder.
Now, I will confess, I didn’t write this from scratch as it was originally taken from the Spatie package template repository. But overall the logic is pretty simple in that, when a PR is produced by the dependabot user it will run.
Then an action is run to fetch the metadata from the PR itself allowing for the next steps to only run depending on the versions involved. In the example the only things auto merged will be minor or patch updates.
Conclusion
Once these steps are in place you only need to make sure that your PRs are running CI tasks. There is always a risk that installing a new version of a dependency brings about an error. Having automated tests run to block the PR in the event of a failure is a very important step. I was hit by this when one of my projects installed a new minor version of Laravel Sanctum which in fact required a change to the database via a migration. If I had not had any tests to run this could have broken my app in a number of unexpected ways but because I did have tests I was able to push a quick commit to the PR and then merge it manually.
I really can’t state enough how groundbreaking things like this are. I myself have started to do this with personal projects, and have had little to no issues. This has meant my projects stay fresh.
At a time where Laravel has now entered a phase of mostly lots of minor incremental improvements being added regularly every week, that makes it hard to keep up in a commercial environment. Hopefully this removes one of those chores and helps in forcing you to keep up to date in the long run.
I’m Peter Fox, a software developer in the UK who works with Laravel among other things. Thank you for reading my article, I’ve got several more on both Medium and Dev.to. If you want to know more about me, head over to https://www.peterfox.me. I’m also now also Sponsorable on GitHub. If you’d like to encourage me to write more articles like this please do consider dropping a small one off donation.
Top comments (0)