Hello folks,

this was discussed some time ago, but we're gonna make oVirt Dashboard
build-artifacts.sh tag-sensitive (if the commit is tagged, it indicates
release build, so we'll drop the {date}git{commit} part of RPM release).

The relevant Dashboard patch is here: https://gerrit.ovirt.org/#/c/60988/

Question: is it possible to execute build-artifacts.sh after a tag gets
pushed into Gerrit repo? (or at least make it opt-in via the Jenkins job
config somehow?)

Or should we just use Jenkins / Gerrit manual trigger to re-build from
given commit once it's tagged in Gerrit repo?

Thanks,
Vojtech


----- Original Message -----
> From: "Vojtech Szocs" <vszocs@redhat.com>
> To: "David Caro" <dcaro@redhat.com>
> Cc: "infra" <infra@ovirt.org>

> Sent: Wednesday, June 22, 2016 7:04:19 PM
> Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
>
>
>
> ----- Original Message -----
> > From: "David Caro" <dcaro@redhat.com>
> > To: "Nir Soffer" <nsoffer@redhat.com>
> > Cc: "infra" <infra@ovirt.org>
> > Sent: Wednesday, June 22, 2016 6:31:44 PM
> > Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
> >
> > On 06/22 19:21, Nir Soffer wrote:
> > > On Wed, Jun 22, 2016 at 6:47 PM, Barak Korren <bkorren@redhat.com> wrote:
> > > > This could be done, but not trival to do, and also requires you to
> > > > know,
> > > > before merging, that this is the patch you are gonna release.
> > > >
> > > > A differnt but somewhat common practice is to use git tagging and 'git
> > > > describe' to set the package version.
> > > > We can make build_artifacts trigger when a tag is pushed, AFAIK Lago
> > > > already
> > > > does that...
> > > >
> > > > בתאריך 22 ביוני 2016 18:39,‏ "Vojtech Szocs" <vszocs@redhat.com> כתב:
> > > >
> > > >> Hi,
> > > >>
> > > >> I'm just curious whether it's possible to do the following:
> > > >>
> > > >> Let's say we have a project (ovirt-engine-dashboard) built by Jenkins,
> > > >> which means there's a Jenkins job that runs build-artifacts.sh script
> > > >> whenever a patch gets merged via gerrit.
> > > >>
> > > >> Can we somehow pass custom parameters to build-artifacts.sh for such
> > > >> (Jenkins CI) builds?
> > > >>
> > > >> For example, putting something like this into commit message:
> > > >>
> > > >>   My-Param 123
> > > >>
> > > >> would reflect into `My-Param` env. variable when running the script?
> > > >>
> > > >> Motivation: for release builds (which shouldn't contain the "snapshot"
> > > >> part [*] in RPM release string), pass parameter to build-artifacts.sh
> > > >> that ensures the "snapshot" part is empty. This way, we don't need to
> > > >> patch the project prior to release (remove "snapshot" in spec) & then
> > > >> patch it again after the release (re-add "snapshot" in spec).
> > > >>
> > > >> [*] {date}git{commit}
> > >
> > > How about adding a flag to the project yaml?
> > >
> > > For example:
> > >
> > >     version:
> > >       - master:
> > >           branch: master
> > >       - 0.16:
> > >           branch: ioprocess-0.16
> > >           release: true
> > >
> > > Then run build-artifacts with RELEASE=1 environment variable, so we can
> > > tell that this is a release build, and create release friendly rpms?
> >
> > That's not better than adding a commit to the project for each release imo.
> >
> > I'd go for the tag thingie actually, just detecting that you are in a tag
> > to
> > control if the extra 'snapshot' should be added or not.
>
> Yes, this sounds like the most correct approach. We'll need to tag anyway :)
>
> As mentioned above, it would be really nice if build-artifacts was invoked
> also when pushing new tag to remote.
>
> >
> > >
> > > Nir
> > > _______________________________________________
> > > Infra mailing list
> > > Infra@ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> >
> > --
> > David Caro
> >
> > Red Hat S.L.
> > Continuous Integration Engineer - EMEA ENG Virtualization R&D
> >
> > Tel.: +420 532 294 605
> > Email: dcaro@redhat.com
> > IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> > Web: www.redhat.com
> > RHT Global #: 82-62605
> >
> > _______________________________________________
> > Infra mailing list
> > Infra@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> _______________________________________________
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
_______________________________________________
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra