Hello,
I'd like to upgrade Jenkins on the production to be close to sandboxes (which always use latest) and local development to be performed per this milestone's blueprints. android-build.linaro.org runs 1.400, latest is 1.418. Interim versions were tested regularly on sandboxes, and I reviewed changelog and saw no backwards-incompatible changes which might affect us. Actually, it has few nice fixes and features useful for us, including those which raised discontent with using Jenkins for our usage patterns:
* Label expression logic wasn't supporting a binary operator sequence like "a || b || c" (issue 8537)
* Move Jenkins URL setting from E-mail Notification to its own section in the main configuration.
* Added an extension point to allow prodding the NodeProvisioner into taking action faster than it might usually.
* When there are absolutely no executors for a specific label, there was an unnecessary delay in provisioning the first node for that label.
* Added a new build parameter type that shows a text area
So, I'd propose to perform upgrade European morning on Thursday, 7th.
Please let me know if there're any concerns.
Hi,
This sounds good to me.
I wonder if we should have the testing sandboxes use the same version of Jenkins though? If it doesn't we could have deployment failures due to using features from the new version.
Thanks,
James
On Tue, 5 Jul 2011 16:39:26 +0300, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
Hello,
I'd like to upgrade Jenkins on the production to be close to sandboxes (which always use latest) and local development to be performed per this milestone's blueprints. android-build.linaro.org runs 1.400, latest is 1.418. Interim versions were tested regularly on sandboxes, and I reviewed changelog and saw no backwards-incompatible changes which might affect us. Actually, it has few nice fixes and features useful for us, including those which raised discontent with using Jenkins for our usage patterns:
- Label expression logic wasn't supporting a binary operator sequence
like "a || b || c" (issue 8537)
- Move Jenkins URL setting from E-mail Notification to its own section
in the main configuration.
- Added an extension point to allow prodding the NodeProvisioner into
taking action faster than it might usually.
- When there are absolutely no executors for a specific label, there was
an unnecessary delay in provisioning the first node for that label.
- Added a new build parameter type that shows a text area
So, I'd propose to perform upgrade European morning on Thursday, 7th.
Please let me know if there're any concerns.
-- Best Regards, Paul
On Tue, 05 Jul 2011 15:27:01 -0400 James Westby james.westby@linaro.org wrote:
Hi,
This sounds good to me.
I wonder if we should have the testing sandboxes use the same version of Jenkins though? If it doesn't we could have deployment failures due to using features from the new version.
Well, I don't know if we reasobaly could hit such situation - we don't really use many of peculiar Jenkins features, so for us, it's mostly core update and bugfixes. It would be better just to upgrade regularly, because there're indeed nice fixes coming in. On the other hand, I remember I knew how to install specific package version with yum, but figure I don't really know how to do it with apt-get, so may be a good occasion to learn ;-).
Thanks,
James
On Wed, 6 Jul 2011 22:00:24 +0300, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
On Tue, 05 Jul 2011 15:27:01 -0400 James Westby james.westby@linaro.org wrote:
Hi,
This sounds good to me.
I wonder if we should have the testing sandboxes use the same version of Jenkins though? If it doesn't we could have deployment failures due to using features from the new version.
Well, I don't know if we reasobaly could hit such situation - we don't really use many of peculiar Jenkins features, so for us, it's mostly core update and bugfixes.
Yeah, it's not that I think that there's a particular thing we are doing that is likely to hit it, it's just the principle of least surprise.
It would be better just to upgrade regularly, because there're indeed nice fixes coming in. On the other hand, I remember I knew how to install specific package version with yum, but figure I don't really know how to do it with apt-get, so may be a good occasion to learn ;-).
apt-get install jenkins=version
Of course this only works if the old version is still available in the archive that we get jenkins from. If that is generally not true then we may want to getting it from a PPA that we control.
That means that upgrade is more than just changing that "=version" as we have to update the PPA too, but it's the direction I think we should be going in.
Thanks,
James
On Wed, 06 Jul 2011 15:26:57 -0400, James Westby james.westby@linaro.org wrote:
On Wed, 6 Jul 2011 22:00:24 +0300, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
It would be better just to upgrade regularly, because there're indeed nice fixes coming in. On the other hand, I remember I knew how to install specific package version with yum, but figure I don't really know how to do it with apt-get, so may be a good occasion to learn ;-).
apt-get install jenkins=version
Of course this only works if the old version is still available in the archive that we get jenkins from.
http://pkg.jenkins-ci.org/debian/
seems to have versions going back at least two years (although only the latest version is in the corresponding Packages file, so maybe wget ; dpkg -i is needed).
Cheers, mwh
Hello Michael,
On Thu, 07 Jul 2011 09:36:38 +1200 Michael Hudson-Doyle michael.hudson@canonical.com wrote:
On Wed, 06 Jul 2011 15:26:57 -0400, James Westby james.westby@linaro.org wrote:
On Wed, 6 Jul 2011 22:00:24 +0300, Paul Sokolovsky paul.sokolovsky@linaro.org wrote:
It would be better just to upgrade regularly, because there're indeed nice fixes coming in. On the other hand, I remember I knew how to install specific package version with yum, but figure I don't really know how to do it with apt-get, so may be a good occasion to learn ;-).
apt-get install jenkins=version
Of course this only works if the old version is still available in the archive that we get jenkins from.
http://pkg.jenkins-ci.org/debian/
seems to have versions going back at least two years (although only the latest version is in the corresponding Packages file, so maybe wget ; dpkg -i is needed).
We could use official prebuilt .war's from Jenkins site too, so in general, it shouldn't be a problem.
Cheers, mwh
Hello,
Jenkins upgrade to 1.419 went well, downtime was ~5mins, few builds after that went ok. Let me know if you notice anything suspicious.
On Tue, 5 Jul 2011 16:39:26 +0300 Paul Sokolovsky Paul.Sokolovsky@linaro.org wrote:
Hello,
I'd like to upgrade Jenkins on the production to be close to sandboxes (which always use latest) and local development to be performed per this milestone's blueprints. android-build.linaro.org runs 1.400, latest is 1.418. Interim versions were tested regularly on sandboxes, and I reviewed changelog and saw no backwards-incompatible changes which might affect us. Actually, it has few nice fixes and features useful for us, including those which raised discontent with using Jenkins for our usage patterns:
- Label expression logic wasn't supporting a binary operator sequence
like "a || b || c" (issue 8537)
- Move Jenkins URL setting from E-mail Notification to its own section
in the main configuration.
- Added an extension point to allow prodding the NodeProvisioner into
taking action faster than it might usually.
- When there are absolutely no executors for a specific label, there
was an unnecessary delay in provisioning the first node for that label.
- Added a new build parameter type that shows a text area
So, I'd propose to perform upgrade European morning on Thursday, 7th.
Please let me know if there're any concerns.
-
James Westby -
Michael Hudson-Doyle -
Paul Sokolovsky