Tobias Bouschen created JDO-792:
-----------------------------------
Summary: Create branch protection for master branch
Key: JDO-792
URL: https://issues.apache.org/jira/browse/JDO-792
Project: JDO
Issue Type: Task
Reporter: Tobias Bouschen
Assignee: Tobias Bouschen
In order to enforce certain restrictions for specific branches, GitHub provides
the concept of 'branch protection'. Such restrictions can take many forms, for
example enforcing a linear history or requiring specific GitHub actions to pass
before allowing a pull-request to merged on the branch.
I would suggest also creating such restrictions for the master branch of both
the main JDO and the JDO site repository. My suggested rules are as follows:
* *Require a linear history* – This will disallow merge commits on the branch.
As a result
** pushes to the protected branch containing a merge commit will be rejected
by the repository. This will most likely only apply to GitHub and not GitBox,
so pushing a merge commit to a protected branch through GitBox will most likely
break the mirror. I would recommend against it.
** the option "Create a merge commit" to merge a pull request for this branch
is disabled.
** pull-requests for this branch containing a merge commit can only be merged
using the "Squash and merge" option to remove this merge commit in the process.
* *Require status checks before merging* – This will require the selected
status checks (i.e. GitHub actions) to pass before the pull requests for this
branch can be merged.
* *Require branches to be up-to-date* – This will require a PR to always be
up-to-date with its base branch. This is a sub-option of "Require status
checks" and is meant as a way to enforce that the checks are always run on the
current version of the base branch. This ensures that a combination of new
commits on the master and the commits of the pull request create a build
failure which is not visible with either of the two separately.
As requiring branches to be up-to-date creates the most overhead when there are
frequent other activities on the repository, this requirement should be
considered carefully. Especially with long-running checks, always having to
rebase pull-requests on the current master before being able to merge them can
be cumbersome.
Another possible option would be requiring approvals (of members with write
access) before a pull request can be merged. I did not suggest this by default
as this rule is binding since none of us have administrative privileges on the
repository. As a result, it would be impossible to create a pull requests for a
trivial fix and merge it without any approval. (This restriction does not apply
to direct pushes to the branch.)
Lastly, as merge commits are not desired and are generally disallowed by the
branch protection rule, I would suggest to completely disable the option to
create a merge commit when merging a pull request.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
