[Biopython-dev] Protecting master branch on GitHub?

[Peter Cock]

Thank you everyone - including the off list replies,
master branch protections are now live!

I have deliberately NOT required the codecov checks
to pass - the test coverage numbers have proved far
too noisy to use as a simple yes/no check.

Also since there are two AppVeyor entries, I may
not have ticked the right one(s) - but initially the
setup is as follows (see below).

Question for later: Should we go further and require
a pull request be reviewed prior to merging? See also:

http://mailman.open-bio.org/pipermail/biopython-dev/2017-September/021871.html

Regards,

Peter

--

Branch protection for *master*
Protect this branchDisables force-pushes to this branch and prevents it
from being deleted.
Require pull request reviews before mergingWhen enabled, all commits must
be made to a non-protected branch and submitted via a pull request with at
least one approved review and no changes requested before it can be merged
into master.
Require status checks to pass before mergingChoose which status checks
<https://developer.github.com/v3/repos/statuses/> must pass before branches
can be merged into master. When enabled, commits must first be pushed to
another branch, then merged or pushed directly to master after status
checks have passed.
Require branches to be up to date before mergingThis ensures the branch has
been tested with the latest code on master.
Status checks found in the last week for this repository
 codecov/patch
 codecov/project
 continuous-integration/appveyor/branch
 continuous-integration/appveyor/prRequired
 continuous-integration/travis-ciRequired
Restrict who can push to this branchSpecify people or teams allowed to push
to this branch. Required status checks will still prevent these people from
merging if the checks fail.
Include administratorsEnforce all configured restrictions for
administrators.


On Wed, Aug 30, 2017 at 11:24 PM, Christian Brueffer <christian at brueffer.de>
wrote:

> On 2017-08-24 12:34, Peter Cock wrote:
> > On Wed, Nov 11, 2015 at 5:19 PM, Peter Cock <p.j.a.cock at googlemail.com>
> wrote:
> >> On Fri, Sep 4, 2015 at 11:20 AM, Peter Cock <p.j.a.cock at googlemail.com>
> wrote:
> >>> On Fri, Sep 4, 2015 at 10:07 AM, Christian Brueffer
> >>> <christian at brueffer.de> wrote:
> >>>> On 2015-09-04 11:02, Peter Cock wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> GitHub have rolled out some interesting new functionality:
> >>>>> https://github.com/blog/2051-protected-branches-and-
> required-status-checks
> >>>>>
> >>>>> The ability to protect the main branch should prevent any accidental
> >>>>> rewriting of the history (from a forced push), which would cause
> >>>>> widespread inconvenience now we have so many forks. I'd like to
> >>>>> enable this if no one objects.
> >
> > We turned this on in November 2015.
> >
> >>>>> The second new feature would disable the web-GUI merge button
> >>>>> until our TravisCI tests have passed. I usually do the merges at
> >>>>> the command line anyway (sometimes rebasing, often to add a
> >>>>> note to the NEWS and CONTRIB files), but again these seems like
> >>>>> a sensible precaution? What do people think?
> >>
> >> ...
> >>
> >> Right now I have not enabled this higher level of protection, the
> >> text for which reads:
> >>
> >> "Require status checks to pass before merging.
> >> Choose which status checks must pass before branches can be
> >> merged into master. When enabled, commits must first be pushed
> >> to another branch, then merged or pushed directly to master after
> >> status checks have passed."
> >
> > Many times we as a group have broken the builds on the master
> > branch (TravisCI and/or AppVeyor tests were failing). This can
> > cause work for each other, but worse it causes false-positives for
> > testing pull requests which may deter new contributors.
> >
> > If anyone can push directly to the master branch this is all too
> > easy to do, even a "harmless" edit can sometimes surprise us
> > (e.g. fails a style check, or impacts a doctest), and I'm guilty of
> > this too.
> >
> > How do people feel about changing our policy to say changes
> > should all happen via pull requests (and take advantage of the
> > GitHub settings to enforce this)?
> >
>
> +1 from me, seems like a good idea.
>
> Chris
> _______________________________________________
> Biopython-dev mailing list
> Biopython-dev at mailman.open-bio.org
> http://mailman.open-bio.org/mailman/listinfo/biopython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.open-bio.org/pipermail/biopython-dev/attachments/20170921/82cfe07a/attachment.html>