Package revision race

[enykeev]

Between fetching a revision number as a part of checkout and uploading a new package with this revision during deploy, every parallel package build will end up with the same revision number and will fail on deploy stage due to package already being present.

[arm4b]

That's what I thought about when implemented existing revision number logic. I wanted to rely on external service like Redis with locking and releasing to avoid any possible race conditions around revision number like this.

But with time, I must admit that it was over-engineering, rather then real case.
Race never happened, because one thing is PR where release number doesn't matter and another thing is Merge.
What's important for us is post-merge build, which happens pretty rarely (a couple of times/month in st2-packages and a couple of times/day for st2 in average).

[arm4b]

Happened for the first time now with @Kami during the year or something 👍
https://circleci.com/gh/StackStorm/st2/4522
If there is less than 10mins between merging 2 PRs into master, - they'll race on package revision.

[arm4b]

I still think by implementing some locking and relying on external service would be overengineering.

Solution for now: don't merge 2 PRs in one go.

If that issue will happen again and again, - then yes worth adding some external Consul or Redis or whatever for revision locking.

[arm4b]

Update: the race happened one more time during the 2.4 release when we trigger the build for both st2-packages + st2 repos at the same time.