Update CI to conform to a standard template and test all supported, non-EOL LTS Node.js releases #549
Conversation
This doesn't really save us much effort and breaks CI on forks. Connects pelias/pelias#951
We will have to upgrade better-sqlite3 before we can support Node.js 22 This also rewrites our CI config so that all Node.js versions are on one line for ease of future grepping. Connects pelias/pelias#950
A lot of our repositories have diverged from our intended template, so this copies a templated version over whatever was here before Connects pelias/pelias#951
BREAKING CHANGE: The Docker baseimage has been updated to use Node.js 18.20.5, so this repository's Docker image will also use it. pelias/pelias#950
| @@ -20,5 +16,6 @@ jobs: | |||
| node-version: '${{ matrix.node-version }}' | |||
| - name: Run unit tests | |||
| run: | | |||
| [[ -f ./bin/ci-setup ]] && ./bin/ci-setup | |||
There was a problem hiding this comment.
This is a new line i added to our template so that repos can define CI setup steps in a script. For now it's specifically so that the interpolation repo can (soon) use the same exact template as other repos, while keeping some dependency installs in a script.
I think we could get at least pbf2json to use that same template too, if we want to manage installing go ourselves.
There was a problem hiding this comment.
Would it be worth hiding this behind an npm run ci-setup || true script so the file name and path may be varied in each repo?
There was a problem hiding this comment.
Yeah that's an option: I was weighing the possibilities when considering the implementation and actually this is the main things I'm looking to iterate on with feedback.
- First and foremost I'm looking to preserve consistency across Github Workflow files, having them identical across all our repos is a huge time saver when we update things.
- In the past, we've been pretty good about using
npm runas the entrypoint for most scripts, so maintaining that consistency has some value for sure. - On the flip side, I was actually thinking of avoiding the npm middleware layer, as it's caused problems in the past (see the signal swallowing in Docker that made us move away from
npm startto./bin/start). Though there is also a new builtin Node.js feature in v22 that could help with that some day, or at least mean theres one less process running - Being able to modify the path and filename, personally I don't see when we would need that, let me know if there's a particular case I'm forgetting
There was a problem hiding this comment.
Gonna merge this for now to unblock other repos but we can change it later if we come up with a better idea
This PR includes a bunch of commits made by a script that standardizes as much as possible our CI config across all repositories.
Along the way it also ensures we test all Node.js versions that are an LTS release, not EOL, and currently work with this repository. Any Github Actions that were out of date or used old Node.js versions (checkout and setup-node @v2) are also updated.
For the whosonfirst repository that means Node.js 18 and 20. We need to update better-sqlite3 for Node.js 22 support.
Also, the CI OS version is now hardcoded to
ubuntu-22.04. We fooled around with an organization wide CI variable to configure that, but it broke CI in forks and doesn't really help us much, so it's now undone.If there are any other differences in Github Actions Workflow files, they are also now removed by using a standard template.
Finally, because this repository has a Dockerfile and we just updated the Docker baseimage to support Node.js 18, there is an empty commit to trigger a new major version release.
Connects pelias/pelias#950
Connects pelias/pelias#951