Open gotson opened 3 years ago
I'm having the same problem. It does not fail but the cache is invalidated and rebuilt because of different node versions coming from the matrix. Example: https://github.com/giggio/node-chromedriver/runs/5439981596?check_suite_focus=true
I experience the same problem: https://github.com/apache/avro/blob/a6c82ac6f4d316e769059adab39a9b39b5ea9f8c/.github/workflows/test-arm64.yml
My workflow has several jobs which run the action in their steps. Since all jobs share the same Docker image they invalidate the image for each other.
I have worked around this issue by overwriting GITHUB_WORKFLOW env var: https://github.com/apache/avro/commit/c635b9ad79392d3c4e40c1d0e8008adb39207dee
I have worked around this issue by overwriting GITHUB_WORKFLOW env var: apache/avro@c635b9a
@martin-g this worked! I am using a matrix, so I had to use matrix values when setting GITHUB_WORKFLOW
. Thanks for the tip!
https://github.com/giggio/node-chromedriver/commit/8255bb51677b1c8f997f3bb942372ccb171cd24e
On the contrary I would like to use the same cache for different workflows. Instead of overwriting GITHUB_WORKFLOW
I would want to allow specifying the full container name:
diff --git a/src/run-on-arch.js b/src/run-on-arch.js
index aeca1b2..ab4362c 100644
--- a/src/run-on-arch.js
+++ b/src/run-on-arch.js
@@ -100,7 +100,7 @@ async function main() {
}
// Generate a container name slug unique to this workflow
- const containerName = slug([
+ const containerName = slug(core.getInput('containerName') || [
'run-on-arch', env.GITHUB_REPOSITORY, env.GITHUB_WORKFLOW,
arch, distro,
].join('-'));
That way more complex usecases could always specify the exact name they want to use and less complex ones can use the default. This solution should go well with #100 and allow a lot more flexibility.
Hi, it seems the name of the container generated after install steps for caching is
ghcr.io/<github_user>/<github_repo>/run-on-arch-<github_user>-<github_repo>-<workflow_name>-<arch>-<distro>
.I am trying to build different images for the same arch/distro, for instance i am using a different version of the JDK inside the image.
My understanding is that all 3 jobs will try to push/pull the same container, which will probably generate conflict.
Can you confirm if that's the case, and if yes, is there something we can do about it?