[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?
+1
>
> 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