[
https://issues.apache.org/jira/browse/JDO-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Bouschen updated JDO-792:
---------------------------------
Component/s: site and infrastructure
Fix Version/s: JDO 3.2
> Create branch protection for master branch
> ------------------------------------------
>
> Key: JDO-792
> URL: https://issues.apache.org/jira/browse/JDO-792
> Project: JDO
> Issue Type: Task
> Components: site and infrastructure
> Reporter: Tobias Bouschen
> Assignee: Tobias Bouschen
> Priority: Minor
> Fix For: JDO 3.2
>
>
> 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)
