This is definitely a very rare case, but I've seen that where speeding up builds on the new commit resulted in that deploying earlier than build triggered by older commit.
I think that makes sense, but I am not sure how to create a concurrency key such that it will still allow two different packages in the same universe to be built at the same time, but not the same package.
This is definitely a very rare case, but I've seen that where speeding up builds on the new commit resulted in that deploying earlier than build triggered by older commit.
New commit: https://github.com/r-universe/rpolars/actions/runs/6683577725 Old commit: https://github.com/r-universe/rpolars/actions/runs/6683254119
To prevent such cases, it may be better to set
concurrency
in GitHub Actions workflows.