Upgrade Path for Jenkins/Hudson

[Thomas Dunlap]

I have inherited an AccuRev Jankins/Hudson CI.  Jenkins version 1.472.  The previous developer stopped programming in 2012.  I am trying to 

determine the best way to upgrade the software. Since the development is old I thought it would be best to see if I can get the 2 applications to talk.

I have updated the licensing for Accurev and can access the CI development platform through the AccurRev WebGUI.  So half the problem is functioning.

We are operating in the Windows OS environment.  I tried to execute Jenkins with  no luck.

I checked the Hudson services and the Event Viewer and have determined that the service will not start. From the Services.cpl I start the Hudson services and it immediately crashes. Whether run as a location system account or an admin account.

Can it be fixed by replacing the Hudson WAR file with the same version WAR file.  

Any help would be appreciated.

 

[John Mellor]

I sympathize with you. I have one Jenkins instance in the same scenario, stuck back at Jenkins 1.656 release. I cannot move it forward without breaking 300+ mission-critical jobs.

<rant mode=on/>

One of the most serious problems with Jenkins today is that API breakage is routine, making it very difficult to even do minor upgrades without breaking your builds. The root cause appears to be the team not checking that a change works against all 2000+ plugins. Test cases are usually inadequate or nonexistant, which does not help. Virtually every upgrade breaks something unexpectedly. Backward compatibility seems to be a new concept for some reason. E.g. the decision to change a blacklist into a whitelist without fixing the 2000+ dependent plugins is clearly irresponsible. Or git or gerrit or github breakage because someone does not understand it. Or the repeated security "cleanups" that break selected builds without fixup changes. IMHO, its a bunch of amateurs driving the bus.

Another part of the problem is probably the language that Jenkins is written in.   Bugs per kloc is essentially fixed, independent of the language, so it is clear that Java is not the correct choice, resulting in far too much code to get the job done correctly.

<rant mode=off/>

Realistically, in order to move up to current, you are going to have to revisit every one of your workflows and redesign them as either the underlying assumptions have been broken, or the API no longer works the same way. Many will port forward easily, while others will need a complete redesign. Keeping on top of updates is a full-time dedicated job here for one person, which tells youjust how bad the issue is. If there was a better-managed orchestration engine, we would have moved there a long time ago in order to fix the complacency about the routine breakages.

[Slide]

I haven't had the same experience as you with updates. I track the LTS release of Jenkins and the breakage, if any, has been very minimal. If you aren't tracking the LTS, I can definitely see you running into lots of issues. The weekly releases are tested over a period of time and with many plugins and then become LTS releases. They are much more stable. I do maintenance on my Jeep kind server pretty INfrequently (mainly with new LTS releases) and it's definitely a part time thing for me. We have a few hundred or so jobs running on the system with minimal impact.

--
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/1522678461.3049.113.camel%40esentire.com.
For more options, visit https://groups.google.com/d/optout.

[Kohsuke Kawaguchi]

Hi, John,

Thank you for your perspective. There are a few things in here that I wanted to respond, as the creator of Jenkins.

First, I totally understand the frustration you and Thomas, the original poster have. This feeling of fear of upgrade and breakage it might create is something we hear from many people. Your Jenkins is mission critical, and when an upgrade breaks Jenkins admins like you and Thomas would be under a lot of pressure to resolve it quickly. One breakage is one too many. Believe it or not, a lot of contributors deeply care about not making that happen.

So the part of your message that tries to call them out is appreciated, and so is illustration of the pain it’s causing and why that’s important to you. Please keep those coming. However, an insult like “it’s a bunch of amateurs driving the bus” shouldn’t be a part of that message and it doesn't belong in this community. For one, at a practical level, it doesn’t help you move your cause forward, and if anything it distracts away from your core message. But perhaps more importantly to me, it also goes against the philosophy and the ethos of this project. This open-source community critically depends on volunteer contributors, and it is very important for me that this project be a welcoming, vibrant, and open community. Without everyone’s continued participation, and influx of new people, we simply won’t be able to solve the kind of challenges you are raising. This is so important to us that we even created code of conduct.

I saw that you put the “rant” marker to block the segment of your message that contained that phase, so I think you just slipped a bit too far in your frustration, in a moment of heat. And that happens to all of us.


Now, I mentioned that a lot of contributors actually deeply care about not breaking people’s installations. I wanted to shed some light into what we are actually doing there.

Changes to the core gets a great deal of scrutiny to explore the backward compatibility impact. Look at this one PR that started yesterday and you’ll see discussion about fallback, backward compatibility, etc. Here’s another one and I’ll throw in one more. This is the norm and not the exception.

From time to time, we have no choice but to break backward compatibility. Many of those are security related, because those tend to be the kind of bugs that require a fix at the design level. But we do this very cautiously knowing the impact it can cause. JEP-200 is the most recent one, so let me explain how we approached this. First, we worked on a design document, convincing ourselves collectively that this must be done and this is the best way to do it. Each code change was reviewed carefully. There was a wiki page used to track changes in plugins and to collaborate with plugin maintainers. Announcements are made to users & contributors calling out what this means and what steps to take, and yet another one as the change landed to LTS. Slides and videos are created. This has been a recurring topic on our official twitter account. Oleg and Jesse led a heroic effort to contain the impact as much as possible.

And we are also not stopping there. The contributors of the project agrees that this requires a bigger measure. We want to move away from the need of assembling plugins and we want to offer something that just works and will keep working. Take a look at the goal and the mission of Jenkins Essentials. One of the key motivations of this ongoing effort is to speak directly to the pain you raised. I invite you and others to join in those conversations in a constructive way.


Hope that helps,

--
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/1522678461.3049.113.camel%40esentire.com.
For more options, visit https://groups.google.com/d/optout.

--

Kohsuke Kawaguchi

[Spriggs, Jim]

Jo! What the man said, in spades.

 

FWIW: I also use the LTS version.

Quite frankly, for a piece of software which hasn’t cost me a penny, and to which I (to my chagrin) yet have to contribute, it’s as near “perfect” as I’ll ever want.

I can happily live with the (very rare) hiccoughs: we’re all only human, after all.

 

Big thanks to everyone involved for making my life easier!

 

--

jim

 

---

RAYLASE GmbH
Argelsrieder Feld 2+4
82234 Wessling
Germany
Tel.: +49-(0)8153/88 98-0
Fax: +49-(0)8153/88 98-10
http://www.raylase.de

District Court Munich, HRB 234738

Management: Dr. Philipp Schön (CEO), Berthold Dambacher (CTO)


Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

[Thomas Dunlap]

All:

After some digging in the documents and looking at my current installation, I get the feeling the getting back my current v1.472 installation, I should be able to rename the config.xml file to config_original.xml then install jenkins-war-1.472.war using 

java -jar jenkins-war-1.472.war --httpPort=8080

in the D:\Hudson folder. Ensuring that no versions of Jenkins are running before execution

After the installation I will set up Jenkins as a windows service from the Manage Configuration. This could also be accomplished using the using the SC,exe command

Then I should be able to replace the NEW config.xml with the Original.xml 

Execute the localhost:8080 and be back in business

Then cleanup all the other settings.

Is this feasible or did I miss something,?

--

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-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/28cf5b1b6a4644798129f58f0d7a4944%40raylase.de.

For more options, visit https://groups.google.com/d/optout.

--

Best Regards

 

Thomas A Dunlap

[Victor Martinez]

Hey Thomas, most likely the hudson folder should be backed up:

- https://wiki.eclipse.org/Using_Hudson/Administering_Hudson which matches with the Jenkins one too: https://wiki.jenkins.io/display/JENKINS/Administering+Jenkins

As a suggestion: I'd rather consider to upgrade on batches firstly, moving from 1.4 to 1.5, then 1.6 then 2.0,... based on the LTS ones and https://jenkins.io/doc/upgrade-guide/ might help you, as Slide also suggested

Cheers

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/28cf5b1b6a4644798129f58f0d7a4944%40raylase.de.

For more options, visit https://groups.google.com/d/optout.

[Thomas Dunlap]

All:

Thanks for all the tips.  I thought I was successful by reinstalling my old 1.472 version.  Was able to access through the local host and saw all the jobs, etc.  This was accomplished using the java -DJENKINS_HOME=/Hudson -jar jenkins-war.1.472.war. Once I gained access I started the process of getting the old nodes added to the configuration.  Something went wrong and lost the ability to access through the browser. Tuis is a windows install on Server 2003.

Then decided to make a new installation using  java -DJENKINS_HOME=/Jenkins -jar jenkins-war.1.472.war. all went well.  Decided to try the latest update to become current.  Had to go to the CLI to restart Jenkins but noted that the Jenkins.exe was not in the folder. Deleted all the files and did another install. Same issue.

One note is that I have JAVA 1.6 on the server.  After rebooting the system i tried the install one more time. Now I get the error that Java 8 is required you have 1.6.

Naturally Java 8 cannot be installed on a Server 2003 SP2 machine.  Think I have boxed myself in.  

What is does tell me is that I CANNOT update to the latest version of Jenkins because of the version of Java. This is an important fact that should be known when trying to upgrade old Hudson installations. I will check to see which version is the highest that I can install.

How do I overcome this Java 8 Error.  

Thanks for all the support thus far.  

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e44e853f-2e31-4ce7-8d0b-9c58dc48b9ae%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Baptiste Mathus]

In short, Java 6 is not supported anymore by recent versions of Jenkins.

So, as was said already above at least by Slide and Victor, your best bet is already to upgrade to the closest LTS to your version. 

You want to study: https://jenkins.io/changelog-stable/ so in your case the fist jump would be 1.480.3.

Then bump for LTS to next LTS progressively, backing up each time.

If you are *really* stuck to Java 6, then anyway you will be stuck at 1.609.3 max too. The next version, 1.625.1 requires Java 7. And then 2.60.1 requires Java 8.

Cheers

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/CAG5JO-CLuGQLRu9L3B%2B%2BGiauRswchcmn6aPwbWCoMtXmgoOH2A%40mail.gmail.com.