[Jenkins] Passing parameters to build-artifacts.sh

Nir Soffer nsoffer at redhat.com
Wed Jun 22 16:21:54 UTC 2016


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?

Nir



More information about the Infra mailing list