GitHub user bossenti edited a discussion: Do we want tom improve our branch protection?
So far we don't have a lot of rules in place with respect to our git flow and branch protection. Therefore, I've screened the documentation of the [`.asf.yaml`](https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features) file to discover what opportunities we are provided with from Apache INFRA side. I've come up with some suggestions on how we could improve our workflow. To be honest, some of them might be rather opinionated and some of them might not be suitable or practical in a small(er) open source project. That's why I would like to start a discussion on the proposal below and am happy to here your opinion. | config parameter | proposed value | outcome/consequences | | ------------- | ------------- | - | | `del_branch_on_merge` | `true` | Branches are automatically deleted when a PR is merged, this prevents a cemetery of stale branches | | `enable_merge_buttons.squash` | `true` | Enables `squash` as merge strategy in PRs (related to `required_linear_history`, see below) | | `enable_merge_buttons.merge` | `false` | Disables `merge` as merge strategy in PRs | | `enable_merge_buttons.rebase` | `false` | Disables `rebase` as merge strategy in PRs | | `protected_branches` | `dev, master` | Disables `rebase` as merge strategy in PRs | | `required_status_checks.strict` | `true` | Requires branches to be up to date (no commits behind target) before they can be merged | | `required_status_checks.contexts` | `validate_pr` | Checks (GitHub workflows) that need to be passed before a PR can be merged (enforces successful tests etc.) | | `required_pull_request_reviews.dismiss_stale_reviews` | `true` | Approvals are withdrawn when commits are added to the PR (not sure whether this is applicable in a project of our size) | | `required_pull_request_reviews.require_code_owner_reviews` | `true` | Reviews need to be performed from people with write access to the repository ( | | `required_pull_request_reviews.required_approving_review_count` | `1` | Minimum number of approvals required before a PR can be merged | | `required_linear_history` | `true` | Enforces a linear history of commits | Besides the configuration changes itself it would like to hear your thoughts on: - Do we want to have different branch protection rules for `dev` and `master` (e.g., we could only allow signed commits additionally on `master`)? - Do we want to have the same rules for `streampipes-website`? One outcome I'd like to get out of this discussion is a set (this might also be empty) of permission that we want to adapt soon. Therefore, I'd create a follow-up issue to apply the changes and document the new workflow properly (e.g. in our `contributing.md` or ` developing.md`) GitHub link: https://github.com/apache/streampipes/discussions/882 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
