Hardcoded cache key prevents multiple workflows or jobs from caching emsdk #20
Comments
I fail to see how the current cache key prevents the use of a cache across multiple jobs. If a job finishes and has the same emsdk version and architecture, it should be fetched successfully by other jobs.
You can manually use actions/cache and set
If I remember correctly, system libraries may be generated after emsdk is used to build files. The action is done running at this point, so if you want to cache these files, you will need to manually use actions/cache. |
|
I got this error when using this action in multiple concurrent workflows (separate YAML files) |
|
I am interpreting 'error' as 'it did not use the cache during a concurrent workflow'. I would assume that this would be the case for any job started before at least one job creates the cache. If this is showing across multiple workflows with the same cache key, could you share some example runs and your configuration? |
|
This is on my main branch after I merged a PR to use this action in two separate workflows. The job was aborted with an error. Loghttps://github.com/artichoke/playground/runs/3257374864?check_suite_focus=true |
|
Is there any update on this? This is also an issue I am experiencing. |
This commit separates "build / test" and "publish" into separate pipelines to prepare for uploading to GitHub Pages with GitHub Actions: - A WebApp build CI step is added which compiles the Rust code to Wasm and builds the TypeScript code into a bundle. This step never uploads to GitHub pages and runs on PRs and merges to trunk. - A "Publish" workflow is added which builds and uploads to GitHub Pages. This workflow only runs on merges to trunk. A concurrency group called "pages" is added with canceling of in flight builds if a newer commit is pushed to trunk. The publish workflow is no longer published on a weekly cronjob. This commit also contains some cleanups: - `actions-rs` GitHub Actions are replaced with bare calls to rustup and clippy, addressing artichoke/project-infrastructure#265 for the playground. - Caching is removed from `setup-emsdk` action due to an upstream bug: mymindstorm/setup-emsdk#20. - `ruby/setup-ruby` is removed from CI jobs where it is not required. - The `CARGO_NET_GIT_FETCH_WITH_CLI` env variable is set, porting a change from `strftime-ruby`. This should speed up build times when the Artichoke git repository is not cached.
This commit separates "build / test" and "publish" into separate pipelines to prepare for uploading to GitHub Pages with GitHub Actions: - A WebApp build CI step is added which compiles the Rust code to Wasm and builds the TypeScript code into a bundle. This step never uploads to GitHub pages and runs on PRs and merges to trunk. - A "Publish" workflow is added which builds and uploads to GitHub Pages. This workflow only runs on merges to trunk. A concurrency group called "pages" is added with canceling of in flight builds if a newer commit is pushed to trunk. The publish workflow is no longer published on a weekly cronjob. This commit also contains some cleanups: - `actions-rs` GitHub Actions are replaced with bare calls to rustup and clippy, addressing artichoke/project-infrastructure#265 for the playground. - Caching is removed from `setup-emsdk` action due to an upstream bug: mymindstorm/setup-emsdk#20. - `ruby/setup-ruby` is removed from CI jobs where it is not required. - The `CARGO_NET_GIT_FETCH_WITH_CLI` env variable is set, porting a change from `strftime-ruby`. This should speed up build times when the Artichoke git repository is not cached.
|
I am also running into this issue. |
|
It's not hard to work around though: make a separate |
|
Also hit to this issue: https://github.com/tree-sitter/tree-sitter/actions/runs/4624890814/jobs/8180161810#step:5:67 Line 31 in ab889da A code like the next is totally enough to create the cache folder in a workspace folder: const fullCachePath = emArgs.actionsCacheFolder; Also it allows to specify a full path to a custom location and prevents situations like bellow: |
|
@ahlinc I'll try to take a look at this on Saturday. |
|
@mymindstorm What did you find during that Saturday? :) |
|
Oops, sorry. |
|
@mymindstorm Maybe Sunday is a better day? :) Just giving the option to control cache key to the user ought to be a very quick hack if you're short on time? |
|
Confirming the issue on godotengine/godot, we've been running into this on and off when merging two PRs shortly after each other, and both would start their Web CI build around the same time. This leads to annoying failed builds. They can thankfully be restarted from the GH Actions UI so it's not too bad. But now we added a second concurrent Web build to our CI pipeline, so we're always going to start two builds in parallel, which is going to lead to seeing this issue many times per day. So we'll really need a workaround. I'll look into what we can implement downstream. Here's an example failure: https://github.com/akien-mga/godot/actions/runs/7567395177/job/20606547300 |
|
@akien-mga |
Thanks! That would work to mitigate the issue with a build matrix having multiple Emscripten jobs indeed. |
…key. Fixes Hardcoded cache key prevents multiple workflows or jobs from caching emsdk #20
* Add option to override cache key. Add workflow name to default cache key. Fixes Hardcoded cache key prevents multiple workflows or jobs from caching emsdk #20 * bump minor versions of dependencies * Update @types/node to 20.x.y * only run CI on master
|
Apologies for the wait. I have released v14, which should address the issues raised here. |
The cache key for the GitHub Actions cache of emsdk is hardcoded:
setup-emsdk/src/main.ts
Line 28 in ca0cef3
This prevents multiple CI jobs or workflows from using this action and caching the results.
Can this key include the workflow name and job? Alternatively, can overriding it be exposed as an action parameter?
The code samples in the README seem to indicate that users should use
actions/cacheon their own. Why does this action also invoke@actions/cache?The text was updated successfully, but these errors were encountered: