On Wed, Jul 24, 2019 at 10:27:35AM +0100, Peter Robinson wrote:
> On Wed, Jul 24, 2019 at 09:14:05AM +0100, Peter Robinson wrote:
> > On Wed, Jul 24, 2019 at 9:10 AM Pierre-Yves Chibon <pingou(a)pingoured.fr>
wrote:
> > >
> > > On Tue, Jul 23, 2019 at 10:35:13PM +0100, Tom Hughes wrote:
> > > > On 23/07/2019 21:51, Pierre-Yves Chibon wrote:
> > > >
> > > > > When you run `fedpkg build` on Rawhide, your package will be
built in a new koji
> > > > > tag (which will be the default target for Rawhide). The package
will be picked
> > > > > up from this koji tag, signed and moved onto a second tag. Bodhi
will be
> > > > > notified by koji once this new build is signed and will
automatically create an
> > > > > update for it (you will be notified about this by email by bodhi
directly) with
> > > > > a “Testing” status. If the package maintainer has not opted in
into the CI
> > > > > workflow, the update will be pushed to “Stable” and the build
will be pushed
> > > > > into the regular Rawhide tag, making it available in the Rawhide
buildroot, just
> > > > > as it is today.
> > > >
> > > > Do we have an estimate of how much extra latency this is likely to
add
> > > > both with and without gating enabled? ie how much more delay there
is
> > > > likely to be before new builds are available?
> > >
> > > Currently the extra latency is about 3 minutes. It's the frequency at
which the
> >
> > What is that based upon? What level of capacity is there to run the CI etc
> >
> > > cron job pushing the updates having past CI to stable runs. We do want to
make
> >
> > I'm assuming you mean passed and not past here, the later gives it
> > quite a different meaning.
>
> Sorry, I wasn't clear, the 3 minutes extra latency is for non-gated packages.
> For gated packages, this highly depends on the tests you run. On my canary test
> that is just call the "fail" method of ansible, it takes about 8 minutes
to have
> the tests set up, ran and tear down.
> So that makes an extra 8 minutes for the tests + up to 3 minutes for the update
> to be pushed to stable (assuming tests passed).
Is there documentation on the failure work flow? What does a packager
need to do to get it resubmitted etc?
I've been meaning to add that question to the FAQ since this morning but still
haven't got to it :(
We do want to have a mechanism to allow all packagers to re-trigger tests for
their package.
However, at this point we do not have it.
There are thus two ways to move forward, either bump the release and rebuild
(that will re-trigger the tests) or waive the missing tests (that will let the
build go through gating).
We're not fond of that situation since we're teaching our packagers to waive
tests, but this is targeting early-adopters and we hope they can forgive us for
this.
I'll made a PR to the doc for this right now :)
Best,
Pierre