<div dir="ltr"><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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 <a href="https://ci.centos.org/">https://ci.centos.org/</a> 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.</div><div><br></div><div>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?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2020 at 9:05 AM David Davis <<a href="mailto:daviddavis@redhat.com">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>David<div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 5, 2020 at 8:18 AM Dana Walker <<a href="mailto:dawalker@redhat.com" target="_blank">dawalker@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>+1 to moving to Github Actions.</div><div><br></div><div>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.</div><div><br></div><div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>
<p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:capitalize;font-family:RedHatText,sans-serif">
<span>Dana</span> <span>Walker</span><span style="color:rgb(170,170,170);margin:0px"></span>
</p>
<p style="font-weight:normal;font-size:12px;margin:0px 0px 4px;text-transform:capitalize;font-family:RedHatText,sans-serif">She / Her / Hers</p>
<p style="font-weight:normal;font-size:12px;margin:0px;text-transform:capitalize;font-family:RedHatText,sans-serif">
<span>Software Engineer, Pulp Project</span>
</p>
<p style="font-weight:normal;margin:0px 0px 4px;font-size:12px;font-family:RedHatText,sans-serif">
<a style="color:rgb(0,136,206);font-size:12px;margin:0px;text-decoration:none;font-family:RedHatText,sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span></span></a>
</p>
<div style="margin-bottom:4px">
</div>
<p style="font-weight:normal;margin:0px;font-size:12px;font-family:RedHatText,sans-serif">
<span style="margin:0px;padding:0px"><a style="color:rgb(0,0,0);font-size:12px;margin:0px;text-decoration:none;font-family:RedHatText,sans-serif" href="mailto:dawalker@redhat.com" target="_blank">dawalker@redhat.com</a> </span>
</p>
<div style="margin-top:12px">
<table border="0">
<tbody><tr>
<td width="100px"><a href="https://www.redhat.com" target="_blank"> <img src="https://marketing-outfit-prod-images.s3-us-west-2.amazonaws.com/f5445ae0c9ddafd5b2f1836854d7416a/Logo-RedHat-Email.png" width="90" height="auto"></a> </td>
</tr>
</tbody></table>
</div>
</div><table border="0"><tbody><tr><td width="100px"><br></td>
</tr></tbody></table>
</div></div></div></div></div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 4, 2020 at 10:26 AM David Davis <<a href="mailto:daviddavis@redhat.com" target="_blank">daviddavis@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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.<div><br></div><div>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:</div><div><br></div><div><a href="https://pulp.plan.io/issues/6065" target="_blank">https://pulp.plan.io/issues/6065</a><br></div><div><br></div><div>Also, @fao89 has opened a couple PoC PRs to demonstrate using Github Actions:<br></div><div><br></div><div><a href="https://github.com/pulp/pulp_file/pull/353" target="_blank">https://github.com/pulp/pulp_file/pull/353</a><br></div><div><a href="https://github.com/pulp/ansible-pulp/pull/217" target="_blank">https://github.com/pulp/ansible-pulp/pull/217</a><br></div><div><br></div><div>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.</div><div><br></div><div>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). </div><div><br></div><div>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?</div><div><br></div><div>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.<br></div><div><div><br></div><div>[0] <a href="https://travis-ci.com/plans" target="_blank">https://travis-ci.com/plans</a></div><div>[1] <a href="https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#usage-limits" target="_blank">https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#usage-limits</a></div><div>[2] <a href="https://travis-ci.org/pulp/ansible-pulp/builds/645651353" target="_blank">https://travis-ci.org/pulp/ansible-pulp/builds/645651353</a></div><div>[3] <a href="https://github.com/fabricio-aguiar/ansible-pulp/actions/runs/33601847" target="_blank">https://github.com/fabricio-aguiar/ansible-pulp/actions/runs/33601847</a></div></div><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>David<br></div></div></div></div></div></div></div></div></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>
</blockquote></div>
_______________________________________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com" target="_blank">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/pulp-dev</a><br>
</blockquote></div>