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} Thanks, Vojtech _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

On Wed, Jun 22, 2016 at 6:47 PM, Barak Korren <bkorren(a)redhat.com&gt; 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 al=

> does that... > > =D7=91=D7=AA=D7=90=D7=A8=D7=99=D7=9A 22 =D7=91=D7=99=D7=95=D7=A0=D7=99 =

> >> 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} =20 How about adding a flag to the project yaml? =20 For example: =20 version: - master: branch: master - 0.16: branch: ioprocess-0.16 release: true =20 Then run build-artifacts with RELEASE=3D1 environment variable, so we can tell that this is a release build, and create release friendly rpms?

=20 Nir _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXar1wAAoJEEBxx+HSYmnD3jQH/0ovKOIdHfT2IUUflfnaf+eR DyfOt5za8ePO1vbbiRWEiFlTKkLDCg4BEaurSfIr8+jsOg7j5qLTua3M1gmVbLn8 yw7rZxCrw2SKR3ggTaGDuGUZWG2BW1j2Kns3mYh6z5fawlELXw+AmXJBbPmWE8PX gmtZ1gQWd6WVJmvi9rdKb4OQrpRzgIklui6e4Pgi/1m8g+yLKGvROGVvwHRzC3/C LKkYU2yf9dI4m/LaZBeg/xfTWCy6Hs18nGrTiCCpRBmUa6A28wx2XFvAGBZzRJU8 XTpf6RPnisbzU3mHa89tVeYzzR6X7vT5/SopwRr1HUEIKkKOwOOd1siDcXCPUpY= =b0f8 -----END PGP SIGNATURE-----

From: "David Caro" <dcaro(a)redhat.com&gt; To: "Nir Soffer" <nsoffer(a)redhat.com&gt; Cc: "infra" <infra(a)ovirt.org&gt; 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(a)redhat.com&gt; 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(a)redhat.com&gt; כתב: > > > >> 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(a)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(a)redhat.com IRC: dcaro|dcaroest@{freenode|oftc|redhat} Web: www.redhat.com RHT Global #: 82-62605 _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra

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(a)redhat.com&gt; > To: "David Caro" <dcaro(a)redhat.com&gt; > Cc: "infra" <infra(a)ovirt.org&gt; > Sent: Wednesday, June 22, 2016 7:04:19 PM > Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh > > > > ----- Original Message ----- > > From: "David Caro" <dcaro(a)redhat.com&gt; > > To: "Nir Soffer" <nsoffer(a)redhat.com&gt; > > Cc: "infra" <infra(a)ovirt.org&gt; > > 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(a)redhat.com&gt; 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(a)redhat.com&gt; כתב: > > > > > > > >> 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(a)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(a)redhat.com > > IRC: dcaro|dcaroest@{freenode|oftc|redhat} > > Web: www.redhat.com > > RHT Global #: 82-62605 > > > > _______________________________________________ > > Infra mailing list > > Infra(a)ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > _______________________________________________ > Infra mailing list > Infra(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > _______________________________________________ Infra mailing list Infra(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/infra