[Pulp-dev] Github Required Checks

Fri Mar 9 00:08:40 UTC 2018

Cool for pulp and pulp_file this (and the docs updates) are slated to be
added to the sprint tomorrow maybe:  https://pulp.plan.io/issues/3379

On Thu, Mar 8, 2018 at 2:14 PM, Daniel Alley <dalley at redhat.com> wrote:

> +1, that sounds great.  It would alleviate a lot of issues with respect to
> breakages.
>
> On Thu, Mar 8, 2018 at 2:03 PM, Dennis Kliban <dkliban at redhat.com> wrote:
>
>> I want to introduce an ability to specify in the commit message for
>> pulpcore a PR for pulp_file and a PR for pulp-smash. Travis would then
>> checkout pulp_file from that PR and pulp-smash from that PR and test the
>> pulpcore PR in combination with the 2 other PRs. This way we can test
>> changes that require changes in multiple repositories. How does that sound?
>>
>> On Thu, Mar 8, 2018 at 11:48 AM, David Davis <daviddavis at redhat.com>
>> wrote:
>>
>>> I set up the pulp_file tests to install pulp 3.0-dev (although we could
>>> change this to nightly builds once those are being built):
>>>
>>> https://github.com/pulp/pulp_file/blob/master/.travis/install.sh#L6
>>>
>>> In the situation you mentioned, we’d merge the PR to pulp and then rerun
>>> the PR tests against the corresponding pulp_file PR. I’d like to make the
>>> PR tests required in pulp_file (unless anyone objects).
>>>
>>>
>>> David
>>>
>>> On Thu, Mar 8, 2018 at 11:22 AM, Austin Macdonald <amacdona at redhat.com>
>>> wrote:
>>>
>>>> +1 pulpcore +0 pulp_file
>>>>
>>>> -1 Other plugins. I'm thinking about the situation where we need to fix
>>>> a bug with a PR to pulpcore and to a plugin. How is the version of pulpcore
>>>> determined for runnning the plugin tests? In the past, we used nightly
>>>> builds, so plugins would have to wait 24 hours after pulpcore merge just to
>>>> run the tests correctly. Even if the test runner checks out HEAD and runs
>>>> against that, each plugin should choose to add this check at their own
>>>> pace.
>>>>
>>>> On Mon, Mar 5, 2018 at 12:45 PM, Jeff Ortel <jortel at redhat.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> 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>
>>>>> 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
>>>>>>
>>>>>> 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>
>>>>>> 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>
>>>>>>> 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> 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> 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>
>>>>>>>>>> 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
>>>>>>>>>>> > 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
>>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Pulp-dev mailing list
>>>>>>>>> Pulp-dev at redhat.com
>>>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pulp-dev mailing listPulp-dev at redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Pulp-dev mailing list
>>>>> Pulp-dev at redhat.com
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Pulp-dev mailing list
>>> Pulp-dev at redhat.com
>>> 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
>>
>>
>
> _______________________________________________
> 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/20180308/364b6119/attachment.htm>