Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

change(dev doc): Document how to change branch protection rules #7773

Merged
merged 5 commits into from
Oct 22, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 20 additions & 3 deletions book/src/dev/continuous-integration.md
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought this would include actual details (and possibly screenshots) of where and how these can be changed in github. e.g from the repo go to Settings > Branches and click "Edit" on the main branch entry.

I was able to figure this out myself but I was a bit nervous clicking around unsure of what would happen...

Original file line number Diff line number Diff line change
Expand Up @@ -33,17 +33,34 @@ We try to use Mergify as much as we can, so all PRs get consistent checks.
Some PRs don't use Mergify:
- Mergify config updates
- Admin merges, which happen when there are multiple failures on the `main` branch
- Manual merges
(these are disabled by our branch protection rules, but admins can remove the "don't allow bypassing these rules" setting)
- Manual merges (these are usually disabled by our branch protection rules)

We use workflow conditions to skip some checks on PRs, Mergify, or the `main` branch.
For example, some workflow changes skip Rust code checks.
For example, some workflow changes skip Rust code checks. When a workflow can skip a check, we need to create [a patch workflow](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks#handling-skipped-but-required-checks)
with an empty job with the same name. This is a [known Actions issue](https://github.com/orgs/community/discussions/13690#discussioncomment-6653382).
This lets the branch protection rules pass when the job is skipped. In Zebra, we name these workflows with the extension `.patch.yml`.

Branch protection rules should be added for every failure that should stop a PR merging, break a release, or cause problems for Zebra users.
We also add branch protection rules for developer or devops features that we need to keep working, like coverage.

But the following jobs don't need branch protection rules:
* Testnet jobs: testnet is unreliable.
* Optional linting jobs: some lint jobs are required, but some jobs like spelling and actions are optional.
* Jobs that rarely run: for example, cached state rebuild jobs.
* Setup jobs that will fail another later job which always runs, for example: Google Cloud setup jobs.
We have branch protection rules for build jobs, but we could remove them if we want.

When a new job is added in a PR, use the `#devops` Slack channel to ask a GitHub admin to add a branch protection rule after it merges.
Adding a new Zebra crate automatically adds a new job to build that crate by itself in [ci-build-crates.yml](https://github.com/ZcashFoundation/zebra/blob/main/.github/workflows/ci-build-crates.yml),
so new crate PRs also need to add a branch protection rule.

### Pull Requests from Forked Repositories

GitHub doesn't allow PRs from forked repositories to have access to our repository secret keys, even after we approve their CI.
This means that Google Cloud CI fails on these PRs.

Unril we [fix this CI bug](https://github.com/ZcashFoundation/zebra/issues/4529), we can merge external PRs by:
Until we [fix this CI bug](https://github.com/ZcashFoundation/zebra/issues/4529), we can merge external PRs by:
1. Reviewing the code to make sure it won't give our secret keys to anyone
2. Pushing a copy of the branch to the Zebra repository
3. Opening a PR using that branch
Expand Down
Loading