Repository navigation
Package revision race #395
Description
Activity
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 inst2-packagesand a couple of times/day forst2in average).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.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.
Update: the race happened one more time during the 2.4 release when we trigger the build for both
st2-packages+st2repos at the same time.
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.