In this new series, I'll be sharing what are the Workflows I use that help me maintain my projects. Not only I'll be sharing what actions I use and how they work, but I'll also give tips on how to trigger them, as well as the advantages and the drawbacks they have. Maybe some of them will not be ready to use in your project, but they might have some cool ideas for you to reproduce in your environment.
Update dependencies
In this first article, I'll be talking about the workflow for automatically updating the dependencies in a node-based project. I'm confident it can be useful for different stacks too.
I think we all can agree that it's important to keep dependencies updated, right? The updated version of the libraries includes security and bug fixes, as well as some really good enhancements, and we want to take advantage of that all. If you are one of the few that doesn't believe that, I suggest reading this page from Dependabot on why bother keeping dependencies up-to-date before continuing.
Dependabot: What GitHub gives you for free
Now that we are all on the same page on why updating the dependencies is important, let's talk about how.
GitHub has acquired Dependabot, a tool that does automated dependency updates, in 2019, and made it free for all public open-source projects in the platform.
If you have a project that fits the criteria, most likely you have received a PR at some point from Dependabot, probably regarding an updated that fixes a security vulnerability, something that looked like:
From thamara/time-to-leave/pull-320
Drawbacks:
- The focus are updates that improve security
- Sometimes it was trying to update some dependencies that were not directly the ones I had in my package.json, but instead, dependencies of my dependencies, which is not the correct flow.
Not-so-automatic solution: Npm Check Updates
If you use node, it's possible you know about the package that reads your dependencies and searches for updates, optionally changing your package.json directly. That's npm-check-updates.
It's extremely easy to use, and as far as I can tell, pretty reliable too. You just install it, call ncu -u
, and you'll see what are the changes available (with colors), and it will update your package file accordingly automatically.
Drawbacks: You have to run it and commit the changes manually.
(Almost) The one: Action package update
I wanted something that would combine ncu
with a workflow, and that's when I found taichi/actions-package-update. To summarize, it's an action that runs ncu
, and, when determining there's an update, will automatically create a PR on your repository.
The way they suggest to use (and also the way I use) is to have it as a workflow that runs on a schedule, which is defined using cron's notation. (Check out the complete code for the workflow at the end of the article). If there's any update, you'll get a PR that will look like:
From thamara/time-to-leave/pull-341
You can follow the README on the action's repository and configure it as suggested, but continue reading for some observations and more details on the setup I use.
taichi / actions-package-update
keeps npm dependencies up-to-date by making pull requests from GitHub Actions or CI.
actions-package-update
This tool keeps npm dependencies up-to-date by making pull requests from GitHub Actions or CI.
This tool is the successor of taichi/ci-yarn-upgrade.
Basic Usage
GitHub Action for package.json update.
GitHub Actions
Below is the complete workflow example:
name: Update
on:
schedule:
- cron: 0 0 * * 3
jobs:
package-update:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@master
- name: set remote url
run: git remote set-url --push origin https://$GITHUB_ACTOR:${{ secrets.GITHUB_TOKEN }}@github.com/$GITHUB_REPOSITORY
- name: package-update
uses: taichi/actions-package-update@master
env:
AUTHOR_EMAIL: john@example.com
AUTHOR_NAME: john
EXECUTE: "true"
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
LOG_LEVEL: debug
with:
args: -u --packageFile package.json --loglevel verbose
Notes:
- this workflow runs every Wednesday at midnight.
- all
args
are passed to npm-check-updates. -
AUTHOR_NAME
andAUTHOR_EMAIL
are use for the commit. - if you set
EXECUTE
astrue,
then…
Drawbacks:
- Sometimes it creates an "empty" PR, without real modifications
- Following the suggested configuration, it will not trigger other workflows you have set up for PRs, for example, running some tests. And this for me was a show stopper.
- This is not specific of this action, it happens to any action that will open PRs in your repository, using the default GITHUB_TOKEN.
The ultimate combination: taichi/actions-package-update + GitHub Apps
After some research, I found out how to allow the PRs created by actions-package-update to trigger my PR checks. Basically I needed to combine the package update action with a GitHub App, which may sound difficult, but it's quite simple in practice. What you need to do is to create an alternative token, that will have some permissions to your project, thus being able to create a PR. Because it will come with a different user, it will trigger all other workflows you have for your PRs.
To setup this GitHub App, follow the instructions available here. If you followed the instructions, you'll be left with two new secrets on your project: APP_ID
and APP_PRIVATE_KEY
, which can be used in the actions-package-update.
The final workflow
So, let's look at how the final workflow looks like:
From thamara/time-to-leave/.../UpdateDependencies.yml
- On lines 1-3 we see when the Workflow is run: every 0h of every day
- On line 7 we see that the job is run on an ubuntu machine
- Steps:
- Lines 10-14 sets up the token to be used when creating the PR
- Line 15-18 sets the repository remote, which will be used to create the PR and also install my application, a step that is necessary in order for ncu to run correctly
- Line 19-28 configures the action-package-update, setting the author name and email, execute = true (true means I want a PR for this, otherwise it will just run and do nothing), the token is retrieved from the previous setup token step, and some other arguments as specified (for debug purposes).
Final thoughts
- I was able to complete my goal of having an automatic flow that checks for updates, and when there is any available create a PR for me to just merge it or not. Because the update comes as a PR, and I have some other workflows that run tests, I can have the guarantee that no update gets checkout if any test fails.
- It's possible that Dependabot does all of this, but I came up with this solution first and it works great!
- Sometimes the action still tries to create some empty PRs, but I don't think this is a big issue. On such occasions, I just drop the PR.
- The screenshots where you see GitHub in a dark theme is because of this Chrome Extension
Let me know what are your thoughts on GitHub workflows and what are the ones you cannot live without.
Top comments (0)