workflows: Remove potential timing issues with artifacts #10620
Conversation
|
This code was tested in https://github.com/kata-containers/kata-containers/actions/runs/12164116090 and didn't hit the problem, but it might be a low chance of hitting it as my previous branch test didn't either |
1d1cceb to
599df4f
Compare
|
I've re-tested this on the topic branch (https://github.com/kata-containers/kata-containers/actions/runs/12232815654) after rebase and all the test passed except the agent-api and SNP tests that have known issues, so I believe this is good. |
599df4f to
d372680
Compare
|
I've updated this PR to make the remove artefacts only done in the release stage, so re-testing this in https://github.com/kata-containers/kata-containers/actions/runs/12298151219. |
With the code I originally did I think there is potentially a case where we can get a failure due to timing of steps. Before this change the `build-asset-shim-v2` job could start the `get-artifacts` step and concurrently `remove-rootfs-binary-artifacts` could run and delete the artifact during the download and result in the error. In this commit, I try to resolve this by making sure that the shim build waits for the artifact deletes to complete before starting. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
c375fb0 to
32e62db
Compare
|
There was an issue in that the shim's |
| remove-rootfs-binary-artifacts: | ||
| if: ${{ inputs.stage == 'release' }} |
There was a problem hiding this comment.
Nit: how about we rather put this condition in the step (line 215), so that we don't need the always() condition in build-asset-shim-v2?
There was a problem hiding this comment.
That sounds like a better idea. It's a bit ugly with a no-op job, might is nicer that the always. Thanks!
Due to the agent-api tests requiring the agent to be deployed in the CI by the tarball, so in the short-term lets only do this on the release stage, so that both kata-manager works with the release and the agent-api tests work with the other CI builds. In the longer term we need to re-evaluate what is in our tarballs (issue #10619), but want to unblock the tests in the short-term. Fixes: #10630 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
32e62db to
cf8b827
Compare
|
With this update the agent-apis test passing on the manual CI run: https://github.com/kata-containers/kata-containers/actions/runs/12301800878 |
There was a problem hiding this comment.
LGTM, thanks for taking care of this issue @stevenhorsman !
With the code I originally did I think there is potentially a case where we can get a failure due to timing of steps. Before this change the
build-asset-shim-v2job could start the
get-artifactsstep and concurrentlyremove-rootfs-binary-artifactscould run and delete the artifact during the download and result in the error. In this commit, I try to resolve this by making sure that the shim build waits for the artifact deletes to complete before starting.