[Jenkins] Passing parameters to build-artifacts.sh

Mon Jul 18 18:19:58 UTC 2016

On Mon, Jul 18, 2016 at 9:03 PM, Vojtech Szocs <vszocs at redhat.com> wrote:

> 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?
>

I think the best way will be to add logic to build artifacts code (post
merge)
Same as you're doing in the patch, so once you merge a tag, its same as you
would have a merge a code change,
build-artifacts.sh will trigger a new build and create the rpm based on the
logic you will tell him.

Another option will be to add new file called build-official-artifacts.sh
which will only build from tags
and then we can collect it to stable repos instead of snapshot repos, I
will need to see what
does it mean to add another 'build artifacts' job to standard CI, but I
don't believe it should be complicated, probably another stage like we have
check-patch and check-merged.

I actually wanted to suggest this option as a first attempt to automate the
official builds and stop using the manual way of tar.gz,
One more thing you might want to do in the official build artifacts is to
sign the RPM.

As for manual trigger, you can do it today with build-artifacts, just give
it the tag refspec:
http://jenkins.ovirt.org/job/ovirt-engine-dashboard_4.0_build-artifacts-el7-x86_64/build?delay=0sec

instead of: refs/heads/ovirt-engine-dashboard-1.0
put: refs/tags/ovirt-dashboard-tag (replace with real tag)

But i'm not sure this will change the rpm name, you probably will need to
change the job or create the official job for that...

>
> Thanks,
> Vojtech
>
>
> ----- Original Message -----
> > From: "Vojtech Szocs" <vszocs at redhat.com>
> > To: "David Caro" <dcaro at redhat.com>
> > Cc: "infra" <infra at 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 at redhat.com>
> > > To: "Nir Soffer" <nsoffer at redhat.com>
> > > Cc: "infra" <infra at 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 at 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 at 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 at 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 at redhat.com
> > > IRC: dcaro|dcaroest@{freenode|oftc|redhat}
> > > Web: www.redhat.com
> > > RHT Global #: 82-62605
> > >
> > > _______________________________________________
> > > Infra mailing list
> > > Infra at ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/infra
> > >
> > _______________________________________________
> > Infra mailing list
> > Infra at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/infra
> >
> _______________________________________________
> Infra mailing list
> Infra at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra
>
>
>

-- 
Eyal Edri
Associate Manager
RHEV DevOps
EMEA ENG Virtualization R&D
Red Hat Israel

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160718/f934cea5/attachment.html>