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 <amacd...@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 <jor...@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 <bbout...@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 <dal...@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 <davidda...@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 <bbout...@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 <mkova...@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 <dal...@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 <jau...@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@redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pulp-dev mailing list >>>>>>> Pulp-dev@redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Pulp-dev mailing list >>>>>> Pulp-dev@redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>>> >>>>>> >>>>> >>>>> _______________________________________________ >>>>> Pulp-dev mailing list >>>>> Pulp-dev@redhat.com >>>>> https://www.redhat.com/mailman/listinfo/pulp-dev >>>>> >>>>> >>>> >>> >> >> >> _______________________________________________ >> Pulp-dev mailing >> listPulp-dev@redhat.comhttps://www.redhat.com/mailman/listinfo/pulp-dev >> >> >> >> _______________________________________________ >> Pulp-dev mailing list >> Pulp-dev@redhat.com >> https://www.redhat.com/mailman/listinfo/pulp-dev >> >> > > _______________________________________________ > Pulp-dev mailing list > Pulp-dev@redhat.com > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
