Pitfalls of upgrading from 1.642.4 to 2.46.2?

47 views
Skip to first unread message

Owen B. Mehegan

unread,
May 10, 2017, 8:33:33 PM5/10/17
to Jenkins Users
I have been given the unenviable task of mapping out a process for upgrading from Jenkins 1.642.4 to the latest LTS (currently 2.46.2). If I had to do this blind and unsupported, I'd start by creating a sandbox Jenkins with a clone of our existing jobs, plugin, and configuration, then drop the upgrade on it and see what exploded. We have a little over 100 plugins installed, so if I had to guess what's going to cause problems, I would expect it to be plugins which are broken by the upgrade, which then must be upgraded themselves, and before I know it I'm in dependency hell.

If anyone has experience with this, whether version-specific or just general tips on how to approach this, I'd love to hear them. Thanks!

Mark Waite

unread,
May 10, 2017, 9:19:29 PM5/10/17
to Jenkins Users
Your technique matches the method I've seen used in the past.  Clone it, upgrade the clone to latest plugins, verify it still works, upgrade core to latest Jenkins, verify it still works, upgrade plugins to latest plugins, verify it still works, repeat until successful, then schedule downtime for the production instance, do the same steps with the production instance.

If the history of jobs inside your running version is not critical to you, you could try making this your time to switch to Docker.  That transition will be much more work than the upgrade path you described, but it will make future upgrades easier and will make it easier to construct sandbox versions of your Jenkins server.

A basic example of that technique is in https;//github.com/MarkEWaite/docker-lfs/ in the lts-with-plugins branch.  I keep a much more involved version of that technique in a private docker repository (since it includes sensitive information).

Mark Waite

On Wed, May 10, 2017 at 6:33 PM Owen B. Mehegan <ow...@nerdnetworks.org> wrote:
I have been given the unenviable task of mapping out a process for upgrading from Jenkins 1.642.4 to the latest LTS (currently 2.46.2). If I had to do this blind and unsupported, I'd start by creating a sandbox Jenkins with a clone of our existing jobs, plugin, and configuration, then drop the upgrade on it and see what exploded. We have a little over 100 plugins installed, so if I had to guess what's going to cause problems, I would expect it to be plugins which are broken by the upgrade, which then must be upgraded themselves, and before I know it I'm in dependency hell.

If anyone has experience with this, whether version-specific or just general tips on how to approach this, I'd love to hear them. Thanks!

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/8e627b69-d2ee-4325-864c-3043dcafedd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

sweeney

unread,
May 16, 2017, 6:52:28 AM5/16/17
to Jenkins Users


On Thursday, May 11, 2017 at 1:33:33 AM UTC+1, Owen B. Mehegan wrote:
I have been given the unenviable task of mapping out a process for upgrading from Jenkins 1.642.4 to the latest LTS (currently 2.46.2). If I had to do this blind and unsupported, I'd start by creating a sandbox Jenkins with a clone of our existing jobs, plugin, and configuration, then drop the upgrade on it and see what exploded. We have a little over 100 plugins installed, so if I had to guess what's going to cause problems, I would expect it to be plugins which are broken by the upgrade, which then must be upgraded themselves, and before I know it I'm in dependency hell.

If anyone has experience with this, whether version-specific or just general tips on how to approach this, I'd love to hear them. Thanks!

We run Jenkins on real (i.e. non-virtual) machines and for upgrade testing I have a VM cluster which tracks the server O/S and Jenkins versions.  It has a subset of the builds in the main Jenkins such that it exercises as many of the plugins as possible.  I am in the process of testing an upgrade from 1.609.3 -> 2.46.2, and the process I follow is broadly as you describe.  Drop in the new master, discard unreadable data, update master and slaves with new security recommendations, upgrade all plugins, discard newly unreadable configuration data, update with any new securty recommendations.  We have over 200 plugins, and I haven't (yet) found a breaking change with this upgrade.  One thing of note is that there is an upgrade wizard that comes up on the startup page.  I was unable to get this to do anything useful as I suspect it requires a higher Jenkins 1.x.y version for the upgrade to work correctly.

Reply all
Reply to author
Forward
0 new messages