Closed dlemstra closed 4 weeks ago
Hi @dlemstra, I'm very sorry for the regression. I didn't consider successive task runs in my testing. Thank you for reporting the issue.
I have a PR out that I think will fix the issue. It adds support for caching the action's dependencies using GitHub's cache action. See here: https://github.com/Azure/trusted-signing-action/pull/31
Feel free to review if you have time.
Would you also consider testing the action version in the PR with your workflow? It can be used like so:
azure/trusted-signing-action@f590f0db745d292cfdc0ddaeea536d103f384e89
I'd also be curious if you find any speed improvement with the referenced version. It should be about 1 minute from my basic testing.
That looks like a better approach. I tested it with azure/trusted-signing-action@dev/japarson/cache
and we are able to use the action multiple times again. You can view my test run here: https://github.com/ImageMagick/ImageMagick/actions/runs/9257345710. Feel free to ask me to test it if you decide to make any other changes.
This issue is fixed with the latest release.
With the @ImagickMagick project with are signing executables in multiple steps. This no longer works with the latest release and we are getting this error message below due to the changes of this pr: #28.
This could be solved by adding
-Force
toExpand-Archive
as mentioned in the error message but I think we could check if the folder exists instead?Only downside of that approach could be an failed extraction on a runner where that folder is cached?