Re: Rolling out Phase I of rawhide package gating

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxx> 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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux