Having multiple workflow runs simultaneously can cause unexpected cache deletions

[Bzomak]

If two workflows are running at the same time, it is possible for one workflow to delete the cache of another.

Example: the clearup of all Oolite caches at the end of one job will delete any Oolite caches made but not yet used of another job.

[Bzomak]

Can try to restrict multiple workflows from running simultaneously by using concurrency groups

[Bzomak]

Allowing only one iteration of the workflow to run at a time could theoretically slow up development, as anything in the queue would have to wait for all previous builds to finish. However, practically speaking, there is unlikely to ever be that amount of activity at a time on Oolite, so this should not be a problem.

[Bzomak]

When a concurrent job or workflow is queued, if another job or workflow run using the same concurrency group in the repository is in progress, the queued job or workflow run will be pending. Any pending job or workflow run in the same concurrency group will be canceled when a new job or workflow run is queued.

Turns out that using concurrency jobs doesn't create a FIFO queue. Careful management of cache-keys might prove the answer instead.

[Bzomak]

The Clear Oolite caches job must only run on the caches generated during it's own workflow run.

Regarding the dependencies, if two jobs running at the same time both try to save a cache with the same name, the second job will not be able to save the cache. This does not fail the workflow. We must therefore ensure that these caches would be identical, by ensuring that any possible file that could affect the cache build is checked in the hashFiles function (see #31). The second job will then throw a warning annotation, and in the next steps will use the cache generated by the first job.