[Jenkins] Passing parameters to build-artifacts.sh

David Caro dcaro at redhat.com
Wed Jun 22 16:31:44 UTC 2016


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.

> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/infra/attachments/20160622/526d7604/attachment.sig>


More information about the Infra mailing list