Why does bors create a staging.tmp branch? Through other GitHub hooks I know that it creates a temporary merge commit [ci skip] -bors-staging-tmp-<no> - bors[bot], but what is its use? Does it check for mergeability? If so, could it do that locally?
1 Like
GitHub provides a web API to merge a “head” branch into a “base” branch, instantly writing the result over the top of the base. We don’t actually want to write the result over the top of the base, however. We want the base to be master, the head to be your PR, and the result to go into staging.
Homu, for example, works around this by force-pushing master to staging, then performing the merge (assuming you’re set to “cloud mode”; it supports local merging, too). Unfortunately, on services that trigger a build every time the staging branch changes, this triggers two builds, one with master’s contents and one with the merge commit.
staging.tmp is a workaround. Master’s contents get pushed there (the Raw Git Data API is used to ensure the commit title is [no ci], to prevent Circle CI from triggering a build), then your PR is merged into that. Then, the contents are copied into staging. This way, only one push to staging occurs.
Bors-NG doesn’t download your source code, so it can’t really do anything locally. That way, the public instance can stay free without having to place an upper limit on how large your repo can get. Bors-NG doesn’t have any mode other than “cloud mode.” No reason it can’t have such a mode; just nobody’s wanted to implement it.
1 Like