search

nanocurrency / nano-node

Nano is digital currency. Its ticker is: XNO and its currency symbol is: Ӿ
https://nano.org
BSD 3-Clause "New" or "Revised" License
3.47k stars 785 forks source link

Multiple action (unit test) runs for the same OS may conflict each other when saving the build cache #4214

Open thsfs opened 1 year ago

thsfs commented 1 year ago

Got this error message when running the unit test action for Windows:

2023-04-13T13:28:46.1799852Z [command]"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/nano-node/nano-node --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
2023-04-13T13:33:53.4897476Z Failed to save: Unable to reserve cache with key Windows-build-cache, another job may be creating this cache. More details: Cache already exists. Scope: refs/heads/develop, Key: Windows-build-cache, Version: 9352ba4f6b71ec8e4ca8f12a0f5d010417706bef05ab0ce4ad1255966527e853
2023-04-13T13:33:53.5961746Z ##[warning]Cache save failed.

The actions try to save the build cache for the same key.

thsfs commented 1 year ago

This is minor, it didn't affect the build, only affected saving the cache for the run it failed.

pwojcikdev commented 1 year ago

Is this an actual issue? Looks like the intended behaviour, since both caches are for the same build type one needs to be discarded and one stored.

pwojcikdev commented 1 year ago

In one of the recent runs, both caches were discarded for some reason, it's definitely a problem if that happens. https://github.com/nanocurrency/nano-node/actions/runs/4720247737/jobs/8372055401

thsfs commented 1 year ago

From the warning "Unable to reserve cache with key macOS-build-cache, another job may be creating this cache". For MacOS there are two jobs in parallel and for Linux, four jobs, all trying to save a cache for the same key for each OS type.

Fix suggestion: for MacOS and for Windows we just need one of the jobs saving the cache. For Linux we need one from each compiler type. This won't avoid collisions with jobs from other workflows if they happen to be running at the same time, but would avoid them for jobs in the same workflow. Dealing with the concurrency problems from only within the workflow should be enough to avoid most of the conflicts.

pwojcikdev commented 1 year ago

I don't think the error message is accurate in this case, since both actions were not running concurrently in a run I linked. There is more info in a discussion regarding this exact problem here https://github.com/actions/toolkit/issues/658