CI improvements #288
CI improvements #288
Conversation
CI now fails if packages aren't compatible with the specified engines.
While npm@8 doesn't support devEngines, this'll stop npm>=10.9.0 from installing and messing stuff up.
A minor security improvement when using corepack.
Always set `persist-credentials` to false, it's a major security risk. It gives any code that executes afterward the same access as the GITHUB_TOKEN. While we explicitly set `permissions`, if you change it, you might overlook this. See also: actions/checkout#485.
I can't figure out why Dependabot isn't updating these, but I can at least bump them manually.
| @@ -113,7 +113,7 @@ | |||
| "turbo": "^2.1.2", | |||
| "typescript": "~5.6.2" | |||
| }, | |||
| "packageManager": "[email protected]", | |||
| "packageManager": "[email protected]+sha512.dc700d97c8bd0ca9d403cf4fe0a12054d376f048d27830a6bc4a9bcce02ec42143cdd059ce3525f7dce09c6a4e52e9af5b996f268d8729c8ebb1cfad7f2bf51f", | |||
There was a problem hiding this comment.
Can you explain how to find the hash for this?
So that if I want to update it some point I know how to keep this security improvement.
Do you also have more information/resources on why this is a good idea?
There was a problem hiding this comment.
I wrote it manually originally, but remembered a few days ago (in a personal project) that there's a cli, so getting the hash is as simple as corepack use [email protected], and it'll add the hash in automatically.
| @@ -60,13 +60,17 @@ jobs: | |||
| with: | |||
| path: ~/.elm | |||
| key: elm-${{ runner.os }}-${{ hashFiles('**/elm.json', 'elm-tooling.json') }} | |||
| restore-keys: | | |||
| elm-${{ runner.os }}- | |||
There was a problem hiding this comment.
I've read https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/caching-dependencies-to-speed-up-workflows but I still don't get how this is not dangerous.
If elm.json has changed, then recovering from other caches seems like a recipe for problems, though I don't understand what it recovers. What am I missing?
There was a problem hiding this comment.
Say I've got an elm.json with [email protected] and [email protected]. I bump elm-syntax, so the old cache is invalidated, but it'll still grab the last cache from the same branch, then main (so you can't get a cache from a fork and get a supply-chain attack), so elm make doesn't have to redownload the unchanged elm-review. Then, it'll upload the new cache (with the new elm-syntax) with a new hash.
It has the potential to create larger caches, but if it becomes a problem, you can just clear the cache.
| @@ -50,13 +50,13 @@ jobs: | |||
| set-safe-directory: true | |||
|
|
|||
| - name: Setup Node.js environment | |||
| uses: actions/setup-node@60edb5dd545a775178f52524783378180af0d1f8 # v4.0.2 | |||
| uses: actions/setup-node@39370e3970a6d050c480ffad4ff0ed4d3fdee5af # v4.1.0 | |||
There was a problem hiding this comment.
Maybe dependabot is not updating them because of the hash? Or because of the comment. Not sure either 🤷♂️
There was a problem hiding this comment.
Dependabot is smart enough for it to work on my other projects. If the comment is wrong, it'll also override it (rather than ignoring it or not updating), which is nice.
(Otherwise, I wouldn't use this. I prefer security updates+possible supply chain attack over old versions)
This reverts commit 4d90fd8.
|
Nice! Thank you! Btw heads up, I delete all GitHub Actions cache, because some other PRs started failing for very odd reasons, so I'm suspecting that some PRs CI tests affect each other. I hope I'm wrong because that would suck. So the cache cleanup is not related to this PR, and you might get slower builds than expected if you were hoping to see them be real quick thanks to the cache. |
Hm.
That was (mostly) a joke. Thanks for letting me know though. |
Way back a long time ago in jfmengels#186 (comment), @jfmengels asked me to write some comments. I also updated the workflows to align with recent changes to our test workflow in jfmengels#288.
Way back a long time ago in jfmengels#186 (comment), @jfmengels asked me to write some comments. I also updated the workflows to align with recent changes to our test workflow in jfmengels#288.
Way back a long time ago in jfmengels#186 (comment), @jfmengels asked me to write some comments. I also updated the workflows to align with recent changes to our test workflow in jfmengels#288.
Way back a long time ago in #186 (comment), @jfmengels asked me to write some comments. I also updated the workflows to align with recent changes to our test workflow in #288.
Endlessly chasing that 1min ci time...