I believe we can add GH actions on plugin_template, then we would have: $ ./plugin-template --travis PLUGIN_NAME or $ ./plugin-template --ghactions PLUGIN_NAME it is not implemented yet on plugin_template, but my experience with pulp_file (https://github.com/pulp/pulp_file/pull/353) makes me think it will be easy to create a template for it since I didn't change many files, and I have not removed travis. This way, we can make plugin_template run both, travis and GH actions. Working with GH actions was a good exercise, I struggled to find a replacement for TRAVIS_COMMIT_RANGE, and got some config issues with kubectl and httpie. I personally think changing to GH is totally optional for plugins, but I believe ansible-pulp and pulp_rpm_prerequisites should move to GH actions, as both not use plugin_template and consume a lot of time. And make plugin_template run in both travis and GH actions, for pushing us to be more agnostic.
Best regards, Fabricio Aguiar Software Engineer, Pulp Project Red Hat Brazil - Latam <https://www.redhat.com/> +55 11 999652368 On Wed, Feb 5, 2020 at 2:16 PM David Davis <davidda...@redhat.com> wrote: > Brian, > > Thanks for the feedback. Responses inline below. > > On Wed, Feb 5, 2020 at 10:31 AM Brian Bouterse <bmbou...@redhat.com> > wrote: > >> I'm concerned about the move to GH actions and also the timing. The >> benefits of lowering the CI runtime are really great, but I'm worried it >> isn't helping us towards our goals and even takes us further from them. >> >> I'm worried about double the outage risk. There are outages, and >> structurally repo CI pipelines that require more services are at more risk >> for total outage. This raises the risk of "total CI pipelines halting" in a >> concerning way for me. Trading runtime for risk I don't think is an overall >> win; I'd like to find a way to lower the runtime and keep risk the same or >> lower. >> > > We've been plagued by Travis outages and bottlenecks over the past year. > Our plugin_template is currently tied to Travis so one option would be to > allow plugin writers to choose which CI to use and divorce Pulp from being > tied to a single one. This ought to reduce risk and the impact of outages. > > >> >> Whatever we do I want to make sure we're doing it fully through the >> plugin template. Is this through the plugin template? If it isn't, or it >> requires additional steps to configure it than they had before, then I'm >> concerned about it taking us further from our goals of having the plugin >> writer take as much burden from the plugin writer as possible. I use this >> thinking to answer the question posed from daviddavis. My take is that the >> plugin template's goal is to make writing a plugin with great CI as easy as >> possible. It's design to be a quality improver and a time saver. >> > > Agreed, the goal is to update the plugin_template. The plan is to start by > moving ansible-pulp to Github Actions first and test out Github Actions as > a viable replacement for Travis. Then move pulpcore and plugins (via the > plugin_template). The ansible-pulp repo doesn't use plugin_template for its > CI configuration so we don't have to change the plugin_template in testing > out Github Actions for ansible-pulp and also ansible-pulp is the main hog > of our Travis resources consuming job runners for 1+ hours. > > To your point about the plugin_template, supporting Github Actions > shouldn't add additional burden to the plugin writer. The two options are > to either move to Github Actions wholesale or let plugin writers choose > which CI to use (which we could default). Either option would require zero > extra steps for plugin writers. And the latter would give more flexibility > to plugin writers if they want to use a different CI. > > >> >> Having the lower runtime is nice, but if we're going to put effort in the >> CI, I'd like to bring up prioritizing getting the plugin_template >> integrated with https://ci.centos.org/ as a high-value goal. I'm >> concerned that we're about to ship the SELinux policy and we have no way to >> test it. Similar concerns with certguard's dependency and its dependencies >> not being packaged on Ubuntu (so it's hard to run on Travis). Also, I'm >> concerned we don't have an environment to evaluate FIPS compatibility with. >> Relatively speaking if we can only do one of these two initiatives at this >> time, I believe we should do the CentOS CI. >> > > I don't see moving to CentOS CI and Github Actions as mutually exclusive. > In fact, I think moving to Github Actions could make it easier to use to > CentOS CI by making our CI/CD code more CI agnostic. Moreover, much of the > hard work to move to Github Actions was already completed by Fabricio last > week. > > >> Lowering the runtime I'm really in favor of, so I hope these concerns >> prompt discussion more than stop the initiative. What do you all think? >> >> On Wed, Feb 5, 2020 at 9:05 AM David Davis <davidda...@redhat.com> wrote: >> >>> Great question. IMO the main benefit in continuing to support Travis is >>> that we could better separate our test/deployment code from the CI specific >>> bits so that most of the plugin_template code could be CI agnostic. That >>> said, this would be more work. I think it comes down to whether we want our >>> plugin_template to be more opinionated or more configurable. >>> >>> David >>> >>> >>> On Wed, Feb 5, 2020 at 8:18 AM Dana Walker <dawal...@redhat.com> wrote: >>> >>>> +1 to moving to Github Actions. >>>> >>>> Can anyone think of reasons a plugin would want to stay with Travis >>>> specifically? As fao89 pointed out on the issue, at least each plugin that >>>> does choose to move takes some of the workload with them to free up job >>>> runners for plugins that choose to remain. >>>> >>>> Dana Walker >>>> >>>> She / Her / Hers >>>> >>>> Software Engineer, Pulp Project >>>> >>>> Red Hat <https://www.redhat.com> >>>> >>>> dawal...@redhat.com >>>> <https://www.redhat.com> >>>> >>>> >>>> >>>> On Tue, Feb 4, 2020 at 10:26 AM David Davis <davidda...@redhat.com> >>>> wrote: >>>> >>>>> Over the past year, we've experienced several growing pains with using >>>>> Travis as our CI/CD environment. Perhaps the biggest has been the >>>>> limitation of having only 3 concurrent job runners[0] across our entire >>>>> Pulp organization. At times, it has slowed development by bottlenecking >>>>> the >>>>> merging of PRs and delayed numerous releases of Pulp. >>>>> >>>>> Last year, Github introduced Github Actions which offers open source >>>>> projects 20 concurrent jobs[1]. I've filed an issue here to get feedback >>>>> on >>>>> moving our repos and plugins to Github Actions: >>>>> >>>>> https://pulp.plan.io/issues/6065 >>>>> >>>>> Also, @fao89 has opened a couple PoC PRs to demonstrate using Github >>>>> Actions: >>>>> >>>>> https://github.com/pulp/pulp_file/pull/353 >>>>> https://github.com/pulp/ansible-pulp/pull/217 >>>>> >>>>> You'll notice for example that the ansible-pulp build time went from >>>>> more than 1 hour[2] to 27 minutes[3] as all the jobs ran in parallel on >>>>> Github Actions. >>>>> >>>>> Unless there are objections, we plan to merge the ansible-pulp PR this >>>>> week since it's CI configuration is independent from other pulp and plugin >>>>> repos (ie it doesn't use the plugin_template's Travis files). >>>>> >>>>> We're hoping though to get feedback on whether we should move pulpcore >>>>> and plugin repos to Github Actions. If so, should we provide plugins with >>>>> the option to continue using Travis if they want? >>>>> >>>>> If there's no objections by February 11, 2020, we'll proceed with >>>>> moving pulp_file to Github Actions and look at updating plugin_template. >>>>> >>>>> [0] https://travis-ci.com/plans >>>>> [1] >>>>> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#usage-limits >>>>> [2] https://travis-ci.org/pulp/ansible-pulp/builds/645651353 >>>>> [3] >>>>> https://github.com/fabricio-aguiar/ansible-pulp/actions/runs/33601847 >>>>> >>>>> David >>>>> _______________________________________________ >>>>> 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
