[rush] rush publish doesn't wait for status checks

[mmkal]

Summary

When running rush publish, the push to the main branch fails when required status checks are turned on.

Repro steps

1. Run rush publish --target-branch main --publish --apply on a repo with required status checks

Expected result:

Rush is smart enough to wait until the status checks have passed on the publish-xyz branch before trying to push.

Actual result:

Error:

remote: error: GH006: Protected branch update failed for refs/heads/main.        
remote: error: 2 of 2 required status checks are expected.

Details

Example run: https://github.com/mmkal/ts/runs/1468013706?check_suite_focus=true
Workflow: https://github.com/mmkal/ts/blob/00c3abe78a91358987b5aa8af4fd1be63dd900c9/.github/workflows/publish.yml

How it could be fixed:

Hitting GitHub APIs to look for status checks might work, but could be a bit complex. A simpler solution could be to just retry the push action until the status checks have passed (at least when certain errors like this are detected, that are likely to resolve within a few minutes).

Standard questions

Please answer these questions to help us investigate your issue more quickly:

Question	Answer
@microsoft/rush globally installed version?	5.34.2
rushVersion from rush.json?	5.34.2
useWorkspaces from rush.json?	true
Operating system?	Ubuntu (GitHub actions)
Would you consider contributing a PR?	Yes, if given some pointers
Node.js version (node -v)?	12.x

[iclanton]

Rush doesn't account for status checks. I don't think we'd want to tie anything directly to GitHub, but we could include an option (maybe a CLI option for publish) that provides a retry interval when pushing.

We exempt publishing from required checks in our repos as the version bumps and changelog updates should never break the main branch. Is that an option for you?

[octogonz]

I believe @ifeanyiecheruo encountered this same issue when trying to publish from one of our repos.

We thought we would need to use an elevated account, or use Oktokit APIs to create a GitHub PR.

Does simply waiting a few seconds and retrying solve the problem? If so I'd be in favor of that.

[mmkal]

@iclanton the problem is usually branch protection is on master/main, so it isn't the push to publish-2020120 that fails, it's when that branch gets merged into main.

A few seconds (I'd guess 10s rather than 1s) would work, as long as the CI is configured to skip basically all checks for publish-.* branches. That could be left to users to figure out, maybe with a hint in the docs.

Re Octokit, in my particular case no need for a PR, since all the meaningful code changes have been reviewed, so I trust rush enough to just merge and push.

[octogonz]

I will look at this very soon.

[octogonz]

This is the specific error we are getting:

* EXECUTING: C:\agents\2.184.2\externals\git\cmd\git.exe push origin HEAD:rush-publish-sandbox --follow-tags --verbose --no-verify 
POST git-receive-pack (237 bytes)
remote: error: GH006: Protected branch update failed for refs/heads/rush-publish-sandbox.        
remote: error: Required status check "CI Build - Pull Requests" is expected. At least 1 approving review is required by reviewers with write access.        
Pushing to https://github.com/XXXX/XXXX
To https://github.com/XXXX/XXXX
 ! [remote rejected]   HEAD -> rush-publish-sandbox (protected branch hook declined)

Seems like it is wanting two things:

• "CI Build - Pull Requests" needs to complete, which takes 5-10 minutes
• At least 1 approving review is required

[octogonz]

I think I have figured this out: Normally these branch protection requirements do not apply to administrator accounts.

For example, the Rush Stack repo exempts its publishing bot like this (on the GitHub settings page for the master branch):

Whereas at my work where I encountered the error, our CI job seems to be connecting to GitHub using a user account that is NOT an administrator. From looking at the Azure DevOps service connection, it's not clear exactly what permissions it has. But when I replaced it with a service connection using my own user account, the publishing completed successfully (because I am an administrator of that repo).

Thus @mmkal it seems that there is no Rush bug to fix here. Instead, we need to improve the Rush documentation to explain that your CI job needs to connect using an account with appropriate permissions. Does that make sense?