Here are my set of thoughts on many things mentioned.
TL;DR: We still need to run CI on CentOS/Fedora, but using cloud instances
of CentOS/Fedora (interacted with via SSH/Ansible from the GHA Ubuntu
client VM) might be preferable to using Fedora CI for certain tests.
1. "We should test GHA via th
Is this the Software Factory instance of Zuul[0]? I can reach out to them
and see if it would make sense as an option for Pulp.
[0] https://softwarefactory-project.io/zuul/t/local/status
David
On Sun, Feb 9, 2020 at 11:51 AM Neal Gompa wrote:
> On Sun, Feb 9, 2020 at 9:46 AM David Davis wrot
On Sun, Feb 9, 2020 at 9:46 AM David Davis wrote:
> Thanks Brian and Daniel. I agree on the points you both raised.
>
> Brian, to you specific questions/points:
>
> ## We need details on each piece of the Travis workflow, where it will be
> ported to, and a rough estimate of how long each piece w
Thanks Brian and Daniel. I agree on the points you both raised.
Brian, to you specific questions/points:
## We need details on each piece of the Travis workflow, where it will be
ported to, and a rough estimate of how long each piece would take. I think
these things would make a great EPIC.
I ha
Thanks for your response Brian, I think all of those concerns are
reasonable! I'll try to add to/help with some of them.
The approach Fabricio took with his PR to pulp_file is incredibly smart, I
think. In his PR to pulp_file, all of the CI scripts remain unchanged. He
just fakes being in a Tra
Thanks for replying @dalley and @daviddavis, both of your replies make good
points that resonate with me. Rather than inline responses, I'll try to
bring back some of your points and comment on them.
@dalley, your articulation of how we would split up the CI to run each part
on only one CI platfor
I agree that Centos CI should be a high priority, however I think it is
still important to discuss what we want our end-state to look like, because
that will strongly influence our approach going forwards. And FWIW, I
don't think Fabricio's work will do any harm in this respect, especially
given t
I think there is an immediate need to move to Github Actions. Yesterday,
for example, I spent a good deal of time on failing pulp_file jobs, which
are exceeding Travis' 50 minute threshold[0] (Github Actions has a 6 hour
limit). We've also been working for weeks on alleviating the bottlenecks
that
Inline replies to three convos would be too confusing, so I'm going to try
to bring it back to a single thread.
The Pulp team can't afford to do two CI's. I estimate it's taken many
hundreds of hours cumulatively and probably >10 hours a week at least
maintaining the CI for Travis in the plugin te
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
Brian,
Thanks for the feedback. Responses inline below.
On Wed, Feb 5, 2020 at 10:31 AM Brian Bouterse 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
I think we should start by discussing what we ultimately want our CI to
look like. Do we want to replace all of our CI with Centos CI, universally
and exclusively? Do we want to run some tests on Centos CI nightly but
retain something simpler for our standard PR test matrix?
I definitely agree t
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
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
pl
+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 W
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
16 matches
Mail list logo
