On Fri, 2018-03-30 at 11:01 -0700, Thomas Dunlap wrote: 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. 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. -- 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+unsubscr...@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.
