[Jenkins] Passing parameters to build-artifacts.sh
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
On Wed, Jun 22, 2016 at 5:39 PM, Vojtech Szocs <vszocs@redhat.com> wrote:
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?
you should be able to use "git show|grep My-Param" from build-artifacts.sh itself and act on it
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@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
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}
Thanks, Vojtech _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
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? Nir
--qtZFehHsKgwS5rPz Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 al= ready 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 = 2016 18:39,=E2=80=8F "Vojtech Szocs" <vszocs@redhat.com> =D7=9B=D7=AA=D7=91:
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?
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.
=20 Nir _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
--=20 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 --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature; name="signature.asc" -----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----- --qtZFehHsKgwS5rPz--
----- 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
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
On Mon, Jul 18, 2016 at 9:03 PM, Vojtech Szocs <vszocs@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-... 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
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
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
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) &
----- Original Message ----- script script? 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
-- 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)
Thanks guys for your replies! Sandro's advice sounds quite simple and straight-forward, I think we can use it for now: $ foo=`git show -s --format=%B | grep My-Param` # My-Param: 123 $ foo=${foo##My-Param:} # 123 Some more comments inline below. Vojtech ----- Original Message -----
From: "Barak Korren" <bkorren@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "infra" <infra@ovirt.org> Sent: Wednesday, June 22, 2016 5:47:46 PM Subject: Re: [Jenkins] Passing parameters to build-artifacts.sh
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.
Yes - when we're about to make release build, we submit a patch that ensures correct RPM version, I just wanted to avoid having to remove & re-add the "snapshot" part in RPM release string for each release.
A differnt but somewhat common practice is to use git tagging and 'git describe' to set the package version.
Right, with tags one could use `git describe --tags --long`.
We can make build_artifacts trigger when a tag is pushed, AFAIK Lago already does that...
That would be nice to have :)
בתאריך 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}
Thanks, Vojtech _______________________________________________ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
participants (6)
-
Barak Korren -
David Caro -
Eyal Edri -
Nir Soffer -
Sandro Bonazzola -
Vojtech Szocs