On Fri, Apr 6, 2018 at 11:00 AM, Stef Walter <stefw@redhat.com> wrote:

Three reasons:

* dist-git repositories do not necessarily produce a package of the
same name. They usually do.

* dist-git repositories can produce multiple sub-packages, as you can
see in the case of cockpit. Any and all of those sub-packages should
be tested and/or gated by tests that live in that dist-git repo.

In this case there are 5 sub-packages from the cockpit dist-git repo in
the Atomic Host that should trigger the pipeline.

Although I understand current effort is on the All Package Pipeline, I
believe this might still be a problem going forward:

* There is no defined way to discover which dist-git repos to look for
tests related to a certain package in the standard test
specification.

Does that make sense? Dominik, did you have any ideas on how we might
fix this?

Cheers,

Stef

On 06.04.2018 15:22, Johnny Bieren wrote:
> I'm not sure what you mean by fix it. If it isn't part of atomic host,
> shouldn't it not be tested by the atomic host pipeline?
>
> Cockpit *is* picked up by the All Package Pipeline. You can see one
> commit from cockpit here
> https://jenkins-continuous-infra.apps.ci.centos.org/blue/organizations/jenkins/upstream-fedora-f28-pipeline/detail/upstream-fedora-f28-pipeline/375/pipeline
>
> Unfortunately, that build is many builds ago so the artifacts have been
> discarded so you cannot see the package test logs anymore. But, wouldn't
> this be the solution, not having the atomic pipeline test it?
>
> The integration with pagure for the All Packages Pipeline is still WIP I
> believe
>
> On Fri, Apr 6, 2018 at 7:35 AM, Stef Walter <stefw@redhat.com
> <mailto:stefw@redhat.com>> wrote:
>
> On 03.04.2018 15:57, Johnny Bieren wrote:
> > Hey all,
> >
> > To clear up some of the questions on this thread:
> >
> > - Why no cockpit testing?
> > "cockpit" as a package name is not
> > in https://pagure.io/fedora-atomic/blob/f27/f/fedora-atomic-host-base.json
> <https://pagure.io/fedora-atomic/blob/f27/f/fedora-atomic-host-base.json>
> > for example, so if the distgit repo name is "cockpit" the commit by
> > design would not have been picked up by the Atomic Pipeline.
>
> How do we fix that?
>
> I guess this gap is because "Discovery" section of
>
> https://fedoraproject.org/wiki/Changes/InvokingTests
> <https://fedoraproject.org/wiki/Changes/InvokingTests>
>
> Does not address how to find the dist-git repo for a given subpackage?
>
> Stef
>
>
> >
> > - Atomic Pipeline doesn't test f28?
> > The Atomic pipeline is currently set up for f26 and f27. I have been
> > working on getting it working for f28, but I am hitting a bug and
> > haven't resolved it yet, so it is not ready yet.
> >
> > - What is the All Packages Pipeline
> >
> (https://jenkins-continuous-infra.apps.ci.centos.org/view/Fedora%20All%20Packages%20Pipeline/
> <https://jenkins-continuous-infra.apps.ci.centos.org/view/Fedora%20All%20Packages%20Pipeline/>)

> > ?
> > As alluded to, this is different than the Atomic pipelines. The
> Atomic
> > pipeline does the following: trigger on distgit commit to a repo of
> > interest (see question 1 for package lists), build rpm, compose
> ostree,
> > compose qcow2 atomic image with ostree, boot sanity tests, package
> > tests, atomic host integration tests, openshift e2e tests, report all
> > results from all stages on fedmsg under org.centos.prod.ci.pipeline.*
> > topics. The All Packages Pipelines do the following: trigger on
> distgit
> > commit to any package to branch [fXX | master] AND the repo contains
> > standard-test-roles defined tests in that branch, build the rpm in
> koji,
> > construct cloud qcow2 image while injecting the rpm at build time, run
> > package tests, report all results from all stages on fedmsg under
> > org.centos.prod.allpackages.pipeline.* topics.
> >
> > - Is the All Packages Pipeline production ready?
> > I think it is. If you look
> >
> here https://jenkins-continuous-infra.apps.ci.centos.org/view/all/job/upstream-fedora-f28-pipeline/
> <https://jenkins-continuous-infra.apps.ci.centos.org/view/all/job/upstream-fedora-f28-pipeline/>
> > it is passing when it should. There even seem to be some legitimate
> > package test failures found. If you go back in the build history, you
> > will likely find some bugs that have since been fixed, but most of the
> > latest builds are legit. We still need the linkage setup between these
> > fedmsgs and pagure, though, to the best of my knowledge.
> >
> > If I can clear anything else up, feel free to ask.
> > Best,
> > Johnny Bieren
> >
> > On Mon, Mar 26, 2018 at 4:21 PM, Dominik Perpeet
> <dperpeet@redhat.com <mailto:dperpeet@redhat.com>

> > <mailto:dperpeet@redhat.com <mailto:dperpeet@redhat.com>>> wrote:
> >
> > On 03/26/2018 05:34 PM, Ari LiVigni wrote:
> >>
> >>
> >> -== @ri ==-
> >>
> >> On Mon, Mar 26, 2018 at 10:40 AM, Pierre-Yves Chibon
> >> <pingou@pingoured.fr <mailto:pingou@pingoured.fr>

> <mailto:pingou@pingoured.fr <mailto:pingou@pingoured.fr>>> wrote:
> >>
> >>
> >>
> >> For one, I'd need a green light that the allpackages pipeline
> >> is running as
> >> expected and ready for production use. Then I'll see to
> adjust
> >> the tools for
> >> this new pipeline.
> >> This does mean we will announce it broadly and that we can
> >> expect its load to
> >> increase as more people opt-in.
> >>
> >
> > I agree. Let's make sure it's stable and production ready, then
> > announce it and help people when the inevitable issues and
> questions
> > arise. :)
> >
> >>
> >> Do we want to discontinue the Atomic CI one? I thought the
> >> idea was to have both
> >> running (see what I said above about the two pipelines being
> >> complementary).
> >>
> >>
> >> Let's have that discussion when Johnny is back from PTO. I am
> >> fine having both if it makes sense and there is no duplication,
> >> which I don't think there is since in the atomic one
> >>
> >>
> >>
> > I think both pipelines have merit, since they test different
> > deliverables. I would prefer to keep the Atomic one around,
> but also
> > have the "regular" one once that is stable.
> >
> > -Dominik
> >
> >
> > _______________________________________________
> > CI mailing list -- ci@lists.fedoraproject.org
> <mailto:ci@lists.fedoraproject.org>

> > <mailto:ci@lists.fedoraproject.org
> <mailto:ci@lists.fedoraproject.org>>
> > To unsubscribe send an email to ci-leave@lists.fedoraproject.org
> <mailto:ci-leave@lists.fedoraproject.org>
> > <mailto:ci-leave@lists.fedoraproject.org

> <mailto:ci-leave@lists.fedoraproject.org>>
> >
> >
> >
> >
> > _______________________________________________
> > CI mailing list -- ci@lists.fedoraproject.org
> <mailto:ci@lists.fedoraproject.org>
> > To unsubscribe send an email to ci-leave@lists.fedoraproject.org
> <mailto:ci-leave@lists.fedoraproject.org>
> >
>
>
>
>
> _______________________________________________
> CI mailing list -- ci@lists.fedoraproject.org
> To unsubscribe send an email to ci-leave@lists.fedoraproject.org
>