bors r+ work well on multiple PRs (ex.: PR#1 and PR#2) that are ready to be merged around the same time.
But as soon as that staging branch is merged by bors onto master, quickly following up with another bors r+ on another PR(#3) fails. Bors will correctly create a new staging branch and start building it, and builds successfully but the merge is “cancelled” by bors, probably since it is out-of-date with master. So we need to go back to PR#3 issue another bors r+.
I had hoped bors would able to update branch #3 with master, then requeue another bors r+ staging build, that would eventually be merged, without user intervention.
Let me know if this is the expected behavior, or if you have any suggestion so we don’t have to issue multiple bors r+ in that situation. Also, I’ll be happy to open a new thread or use another channel if this isn’t the right place!
To add more details to @vathanalen issue (I work with him), the problem occurs because when a PR is merged to master, a new commit in master branch is added to bump our package version.
So when bors tries to merge the next PR it fails as it’s not up to date. However, we did deactivate “Require branches to be up to date before merging” option in Github, so the merge should not fail.
Maybe this solution to bump version on master doesn’t fit best with bors, but what alternative would there be?
We also tried to automatically bump the version on the “staging” branch as well, but bors doesn’t like it either.
Thanks,
Corentin
1 Like
Yeah, this is a known problem. Bors really isn’t designed to have anything but itself updating the master branch.
If you want to explore alternatives that mesh better with bors, I’m going to have to ask the tough questions:
- What exactly are you using your version numbers for?
- How often do you release, and what exactly goes into your releases?
I went ahead and split this topic off from Private Bors-ng returning 400 Internal server error - #6 since a new thread is probably the right way to do this. 
@notriddle bors could just restart the staging when a fast-forward merge fails. I think that’d work fine under the assumption that such situation should be pretty rare (e.g. emergency fix or some such).
I’ve got to say bypassing bors after every single commit it makes seems less than wise.
1 Like
We have a web app which takes around 9 minutes to build and test in our CI, is released in prod between 3 to 8 times per day. It’s public facing behind a CDN so there can be multiple versions of the app currently used by our end-users. We can use version numbers in order to activate feature flags on other services for features that are only available since a certain version of the app. We can also rollback the app easily since we have versions for every build, and application logs expose the version to help troubleshoot. Releases can include new features, bug fixes or non-customer impacting updates.
So we currently have operational requirements that leverage version numbers and ideally bors would fit in our deployment pipeline with those constraints in mind.
Okay, my recommendation is to use git tags instead of putting the version number in your source code. Creating tags for your version numbers is a good idea in any case, whether you do anything else or not, because being able to git checkout v103 to go from a version number to the corresponding source code is kinda nice.
Beyond that, what I’d do is:
- Set up a bot that creates a new git tag whenever the master branch gets updated. This takes the place of the bot you currently have that’s bumping the version number by making a commit.
- Set up your deploy pipeline to do a deployment whenever a new tag is created. Most CI/CD software supports this, though it may be treating branches and tags as equivalent and thus be hiding behind a more general “build whenever a new branch is created” setting.
- The first step in your deploy pipeline, then, is to fetch the current git tag name and inject it into your build system as the version number.
- As a result, nothing should change for your ops folks, since the resulting built package has a version number embedded in it just like it used to.
This is very similar to what bors-ng itself uses, though I’ve just been using commit hashes instead of bothering to create numbers and tags.
1 Like
Following your recommendation we push a new git tag from our CI when it builds a master branch, instead of pushing a version number in the codebase. This results in no commit possible into master from anyone else but bors, which is what we want. We can then re-enable GitHub protected branch settings to require branches to be up to date with master before pushing.
We're very excited to see this working in our setup, thanks a bunch for your valuable input! 
2 Likes