🐛 Fix: bump actions to prevent failing workflows #19
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What's this PR do?
Upgrades helper actions in our Github workflows to the latest versions: checkout (v4), setup-python (v5) and cache actions (v4).
Why are we doing this?
This attempts to fix a mysterious dependency bug in our Github workflows. Although they were previously working fine, they suddenly stopped working. The first failure for the Archive job was Tue, 26 Mar 2024, but the last PR was Wed Mar 20. The Archive action ran several times after Mar 20 without failure.
Without doing an extensive deep dive, my guess is that something changed in either the Github-hosted task runner or one of our sub dependencies. Initially, I thought the issue might relate to these warnings about the Node env being used in the Github taskrunner:
Our versions of checkout, setup-python and cache actions in each of our workflows is quite dated at this point. Bumping the versions appears to have fixed things but it's hard to be certain because my new PR caused the Github task runner cache to refresh. Based on my experience with other city-scraper repos that have suffered dependency issues, simply clearing the Github taskrunner cache can sometimes (temporarily) fix the issue. In retrospect, I should have cleared the cache first and re-ran the jobs to see if they still failed.
Steps to manually test
N/A
Are there any smells or added technical debt to note?
See the above notes. It's a bit unclear if this fixes the underlying issue. We'll keep an eye on it.