gh-pages branch protection rules in conflict with PR merge rules

[hlapp]

The gh-pages branch is under a branch protection rule that requires changes to come through a PR. I don't know whether this had been active for some time, but the most recent PR merge (#15), which must have used a squash merge, wasn't honored as satisfying the branch protection rule, resulting in a build failure.

I suspect that this gh-pages branch protection rule is a problem if allowing squash and rebase merges, but maybe this needs to be investigated.

I've for this time bypassed the issue by disabling the branch protection, re-triggering the previously failed Github Action, and then re-enabling branch protection.

[egrace479]

Yes, it seems like maybe I didn't need to create one for gh-pages, though I did exempt deploy keys (or do we need to create a deploy key?).

[egrace479]

When we figure this out, we should also update the guide on this topic.

[hlapp]

It seems like the API key automatically made available within GitHub Actions doesn't count as a deploy key.

It could be that we could create a deploy key and then add it as a secret to the environment for the GitHub Action. However, that also sounds to me like adding one security risk to circumvent another security tie-down.

[egrace479]

I think another option would be to use the repo admin override (since it did show me as deploying). I don't recall us having this issue with classic branch protections (we still have access to those, so that could be another option). I asked @wang2989 to look into this.