Christopher Willis-Ford 650464c778 ci: ensure tests use build output and simplify CI/CD workflow ... Thanks, @takaokouji, for making me take a closer look at the caching behavior in this workflow. Subtle and dangerous! In the previous version, the `build/` directory was cached with this key: ```yaml key: ${{ runner.os }}-build-${{ hashFiles('package-lock.json') }} ``` As @takaokouji observed, this means that if a commit or PR doesn't change `package-lock.json`, the cache key will not change. Two unrelated builds, possibly with very different content in `src/` or elsewhere, could share the same build cache. In this case, when the later testing steps restore the cache, they'll both be testing the same build output. One of them won't be testing what you expect! Luckily, the deploy steps also used the same cache keys, so they also didn't deploy what you expect. I say "luckily" because the alternative is to release something that didn't run any tests. All the caching and retrieval steps also took a lot of time, enabled only a tiny amount of extra parallelism (in the deploy steps), and added a lot of complexity to the workflow. Removing all of that means a faster, easier-to-understand workflow with no sneaky gremlins making us test or deploy the wrong thing.		2024-08-26 14:09:34 -07:00
..
workflows	ci: ensure tests use build output and simplify CI/CD workflow	2024-08-26 14:09:34 -07:00
CONTRIBUTING.md
ISSUE_TEMPLATE.md
PULL_REQUEST_TEMPLATE.md