[Pulp-dev] Github Required Checks

Jeff Ortel jortel at redhat.com
Mon Mar 5 17:45:17 UTC 2018

On 03/02/2018 03:20 PM, Brian Bouterse wrote:
> I had neglected to write up the temporary enable/disable part of the 
> issue, so I just updated it here: https://pulp.plan.io/issues/3379
> In short, one of the pulp org owners (ipanova, ttereshc, rchan, 
> jortel, bmbouter) can temporarily enable/disable required checks. This 
> issue would also add this process to both the pulp2 and pulp3 docs.
> What do you all think about an idea like this?


> On Fri, Feb 16, 2018 at 1:33 PM, Brian Bouterse <bbouters at redhat.com 
> <mailto:bbouters at redhat.com>> wrote:
>     +1 to enabling checks for the 'pulp' and 'pulp_file' repos in
>     Github with the ability to temporarily disable them. I wrote up
>     this issue here to do that: https://pulp.plan.io/issues/3379
>     <https://pulp.plan.io/issues/3379>
>     I think we should enable these because we have a human-enforced
>     policy that expects failed checks to not be merged, but in
>     practice code that is merged breaks things that quality checks
>     also identified. I think Pulp would benefit from a stronger
>     pre-merge enforcement of our existing checks. In the case where
>     our quality checks are failing, I'm hoping we can focus on fixing
>     them before continuing on with the merge in all but exceptional cases.
>     On Thu, Feb 15, 2018 at 8:55 PM, Daniel Alley <dalley at redhat.com
>     <mailto:dalley at redhat.com>> wrote:
>         +0 on required github-enforcement, +1 to a strict
>         human-enforced policy about tests passing for PR merges
>         Reason being, an issue has occurred which would block valid
>         PRs twice within the last month.  The first being the test
>         certs expiring on January 25th, the second being when we
>         switched the PR unittest runners over to new versions of
>         Fedora this morning.
>         I'm not against the idea by any means, I'm just not entirely
>         convinced that the exceptions requiring intervention will be
>         very infrequent, and I can imagine it leading to a fair amount
>         of frustration.
>         On Thu, Feb 15, 2018 at 7:34 PM, David Davis
>         <daviddavis at redhat.com <mailto:daviddavis at redhat.com>> wrote:
>             +1 to enabling the checks for the core pulp repos in
>             Github. The only concern I have is that perhaps something
>             happens outside of our control (e.g. Travis goes down) and
>             we can’t merge PRs. In those cases though, we can
>             temporarily disable checks.
>             David
>             On Thu, Feb 15, 2018 at 4:38 PM, Brian Bouterse
>             <bbouters at redhat.com <mailto:bbouters at redhat.com>> wrote:
>                 I want to adjust my proposal to only be for core, and
>                 not a requirement for any plugin. I think the plugin
>                 policy is something the committers should decide along
>                 with their users. I overall believe enabling these
>                 kinds of checks is a good idea so I encourage plugins
>                 do it. We should make sure each team has a github
>                 admin in place who could make such a change.
>                 I like option 1, which to retell my understanding
>                 means that we'll enable github to require the checks
>                 to pass and you can't merge or push without them
>                 passing. Is that good, would there be any -1's for a
>                 change on core like this?
>                 To share my perspective about plugins being in the
>                 Pulp organization, they are there only for a clear
>                 association with Pulp on github. Any open source
>                 plugin that creates value with Pulp and does it with a
>                 debatable level of responsibility towards its users I
>                 think is probably ok to include. I don't expect them
>                 to give up any control or autonomy if they do that.
>                 The benefit of bringing these different plugin
>                 communities closer together through the organization
>                 is hopefully towards common services like automated
>                 testing and such over time.
>                 On Tue, Feb 13, 2018 at 8:28 AM, Milan Kovacik
>                 <mkovacik at redhat.com <mailto:mkovacik at redhat.com>> wrote:
>                     > Option 1:  Nothing merges without passing PR runner tests, ever, even if the issue is
>                     rooted in the configuration or infrastructure of
>                     the test runners or an expired certificate etc. 
>                     This would light a fire to get these issues
>                     resolved ASAP because nothing can happen without them.
>                     I like this option for the same reasons Daniel
>                     mentioned; it also implies an up-to-date
>                     infrastructure and better reliability: both false
>                     negative and false positive (test/build) failures
>                     will still happen in all the three options
>                     regardless, but at least false negatives won't be
>                     ignored.
>                     This might also help catching environment issues
>                     sooner in the process (such as a third-party
>                     library update causing a legitimate failure
>                     because of e.g backwards incompatibility).
>                     When it comes to plugin independence, we could
>                     state that only plugins conforming with these
>                     (core) PR criteria can be "adopted" and tagged as
>                     Pulp-approved/compatible and kept under the Pulp
>                     project.
>                     --
>                     milan
>                     On Mon, Feb 5, 2018 at 7:21 PM, Daniel Alley
>                     <dalley at redhat.com <mailto:dalley at redhat.com>> wrote:
>                         Jeremy, I don't think David was continuing our
>                         line of discussion on policy, but rather
>                         rebutting the original idea that Github's
>                         "required checks" be enforced for all plugins.
>                         That goes back to the whole difference between
>                         having a policy that requires green tests and
>                         making it physically impossible to merge PRs
>                         without them. Maybe some plugins want a policy
>                         and some plugins are fine with hard required
>                         checks on Github, but the latter shouldn't be
>                         enforced on everyone - is what I think David
>                         was saying.
>                         Also, my understanding is that pulp_deb is not
>                         strictly under our control, but that we're
>                         hosting it specifically to let misa use our QA
>                         infrastructure, and because we might want to
>                         productise it at some point in the future.
>                         On Mon, Feb 5, 2018 at 12:55 PM, Jeremy Audet
>                         <jaudet at redhat.com <mailto:jaudet at redhat.com>>
>                         wrote:
>                             > Regarding the plugin repos, last year we
>                             talked about plugins being completely
>                             autonomous (aside from abiding by our Code
>                             of Conduct). Wouldn’t setting the required
>                             checks for projects like pulp_file,
>                             pulp_python, pulp_deb, etc violate this
>                             autonomy? In other words, shouldn’t we let
>                             plugin teams decide their own policy and
>                             what checks to enable?
>                             Are pulp_file, pulp_python, pulp_deb, and
>                             so on autonomous projects? The fact that
>                             they're hosted on GitHub under the pulp
>                             organization [1] indicates that they're
>                             under our control. Since they're under our
>                             control, we get to set the rules. If any
>                             of these projects really are autonomous,
>                             then somebody please kick them out of the
>                             pulp organization.
>                             If I was writing paychecks to a team of
>                             devs, and they refused to adopt basic QA
>                             processes for their projects, I'd happily
>                             fire the entire dev team. I can't be the
>                             only one who's had this thought.
>                             [1] https://github.com/pulp
>                         _______________________________________________
>                         Pulp-dev mailing list
>                         Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>                         https://www.redhat.com/mailman/listinfo/pulp-dev
>                         <https://www.redhat.com/mailman/listinfo/pulp-dev>
>                     _______________________________________________
>                     Pulp-dev mailing list
>                     Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>                     https://www.redhat.com/mailman/listinfo/pulp-dev
>                     <https://www.redhat.com/mailman/listinfo/pulp-dev>
>                 _______________________________________________
>                 Pulp-dev mailing list
>                 Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>                 https://www.redhat.com/mailman/listinfo/pulp-dev
>                 <https://www.redhat.com/mailman/listinfo/pulp-dev>
>             _______________________________________________
>             Pulp-dev mailing list
>             Pulp-dev at redhat.com <mailto:Pulp-dev at redhat.com>
>             https://www.redhat.com/mailman/listinfo/pulp-dev
>             <https://www.redhat.com/mailman/listinfo/pulp-dev>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180305/b893eed4/attachment.htm>

More information about the Pulp-dev mailing list