On Thu, Mar 08, 2018 at 08:26:30PM -0800, Kevin Fenzi wrote:
> On 03/08/2018 07:53 PM, Kevin Kofler wrote:
> > Randy Barlow wrote:
> > > It may be possible to automate the process a bit to make it
> > > less heavy
> > > for developers, though there is some complication for multi-
> > > package
> > > updates
> >
> > Some automation would help, sure. But if we are going to do
> > things
> > automatically, why bother with Bodhi at all?
>
> Well, we don't currently have another tool to show results and
> allow
> waving of them. We could come up with another app and have yet a
> different place and workflow from regular releases, but why not
> stick to
> the same workflow and avoid making yet another app.
> >
> > We are already building into a pending tag for the autosigning,
> > from which
> > the packages are moved into the final tag when they are signed.
> > The same
> > process should work for autotesting. Just add it before or after
> > the
> > autosigning in the pipeline, possibly with another intermediate
> > tag.
> >
> > I think that Bodhi is really the wrong tool for the job here.
> > What you are
> > trying to hit with your shiny hammer may look like a nail to you,
> > but it is
> > really a screw. ;-)
>
> I don't think thats the case here, it's more than we don't want to
> build
> another different tool for something that could work with the
> hammer we
> have.
>
> To be fair, there was a suggestion that we show results in
>
pagure/src.fedoraproject.org, but to me, that definitely sounds
> like the
> wrong place for such things. We want tests tied to a specific
> update,
> not the entire package as a whole. (Even thought we could fudge
> this by
> having git tags or something to tie results to).
For regular Fedora releases I definitely agree with you, but for
rawhide where
the only time we bundle package together would be via side-tags, I
think
reporting test results to src.fp.o would be a valid approach.
We could take a hint from how we make software upstream these days:
1. submit a pull request for the package in src.fp.o on the master
branch
2. a CI automatically builds this package in Koji
3. merge the pull request into master
4. the build (from step 2) is tagged for Rawhide, without a rebuild
Gating is achieved by preventing merges if the build/tests fail.
--
Mathieu