Bumping global-jjb


Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
 

Hello.

 

Is there a document describing the steps needed

to upgrade global-jjb (as a submodule of ci-management git repository)?

 

Motivation:

"git describe" says we are currently using v0.53.1,

but .2 has a fix [0] we want.

After looking at git history, we probably want .3.

 

Update:

After reading a random tutorial [1],

I was able to create the Change [2].

But I am still not sure how I would review such a Change from another contributor.

 

Vratko.

 

[0] https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/release-notes.html#v0-53-2

[1] https://www.vogella.com/tutorials/GitSubmodules/article.html

 


Andrew Grimberg
 

On 2020-06-11 02:02, Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at
Cisco) via lists.fd.io wrote:
Hello.

Is there a document describing the steps needed
to upgrade global-jjb (as a submodule of ci-management git repository)?

Motivation:
"git describe" says we are currently using v0.53.1,
but .2 has a fix [0] we want.
After looking at git history, we probably want .3.

Update:
After reading a random tutorial [1],
I was able to create the Change [2].
But I am still not sure how I would review such a Change from another
contributor.

Vratko.

[0]
https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/release-notes.html#v0-53-2
[1] https://www.vogella.com/tutorials/GitSubmodules/article.html
So... global-jjb upgrades (as well as common-packer upgrades) are rather
interesting and unique since they're submodule updates.

Firstly I as committer expect that the verify jobs pass (which in
general they should) but if there is anything in the release notes that
talk about upgrades then I will generally do the following:

1) make sure I'm on latest HEAD of ci-management with all the submodules
at their proper version
2) run a `jenkins-jobs test -o target/ jjb/` with the current setup
3) pull the change and update the submodules
4) run a `jenkons-jobs test -o target2/ jjb/` with the new setup
5) compare what changed between the job runs using diff

If nothing is really nasty standing out, then I accept the change.

If there is nothing really extraordinary in the release notes that
concerns me I generally just take the update after verifying it really
is pointing at the version it's supposed to ;)

-Andy-

--
Andrew J Grimberg
Manager Release Engineering
The Linux Foundation