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 <davidda...@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 <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 > >
_______________________________________________ Pulp-dev mailing list Pulp-dev@redhat.com https://www.redhat.com/mailman/listinfo/pulp-dev
