You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
WARNING: Jenkins update to 2.60.1 requires Java 8 #775
Create a job to run a java -version (and probably a which java/where java) on each machine, so we can see where we're going to have issues. If the job failed on Java <8 that would be ideal
Upgrade ansible scripts for machines which need it.
Apply scripts to machines and get us ready to upgrade
Upgrade and make sure things still work (some machines may not be using the Java in the path for Jenkins connection)
Note for @nodejs/build @nodejs/jenkins-admins considering clicking the shiny red button to update Jenkins
In the changelog for 2.60.1 it notes that it requires Java 8 to be installed on all the hosts.
2.60.1 is the first Jenkins LTS release that requires Java 8 to run. If you're using the Maven Project type, please note that it needs to use a JDK capable of running Jenkins, i.e. JDK 8 or up. If you configure an older JDK in a Maven Project, Jenkins will attempt to find a newer JDK and use that automatically. If your SSH Slaves fail to start and you have the plugin install the JRE to run them, make sure to update SSH Slaves Plugin to at least version 1.17 (1.20 recommended).
I'm pretty sure we don't have Java 8 on all our hosts, so updating will stop those hosts being able to connect.
$ ssh ci java -version java version "1.8.0_131"Java(TM) SE Runtime Environment (build 1.8.0_131-b11)Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)
There's a few older systems like centos5 which doesn't pack it either. If this is only a matter of adding more package source repos then it might not be as bad then.
I improvified it: cross-platform bash execution, use the parent-of-parent to figure out how java is executed (not using which java which may be incorrect). Changing the grep of the version line to be OK with OpenJDK and other types of JRE.
Did someone delete the job? I'm not seeing one called Java.
use the parent-of-parent to figure out how java is executed (not using which java which may be incorrect).
I was going to suggest we make grandparent java != which java an error, unless we're aware of some specific exceptions it'd be nice if the default Java (in the path) was always the one used to run Jenkins.
@nodejs/jenkins-admins FYI I've had to untick "Build if SCM changes" in the Advanced section of the MultiJob sub-jobs in node-test-commit, node-test-commit-arm-fanned and node-test-commit-windows-fanned, I guess this is new, or the default to ticked is new or something, because it's causing problems with the fanned jobs but also it's just plain annoying when testing if something works. I'm not seeing a good case for having it on in our infra.
still got the arm-fanned ESM addon tests failing, @refack is having a play with trying to fix that. It's a @nodejs/build thing rather than a core thing so if there are more of us that can lend him a hand then he'd probably appreciate it.
Looks like it might be the way the agent was started. Don't think /etc/rc.d/rc2.d/S20jenkins start was used as these were not edited on the 2 AIX machines.
Edited and restarted agent and testing now, seems to be getting further.
Looks like it might be the way the agent was started. Don't think /etc/rc.d/rc2.d/S20jenkins start was used as these were not edited on the 2 AIX machines.
Going to close this, there's some ansible work that's left undone from #775 (comment) and the IBM machines but mostly they relate to older distros that we're going to be phasing out soon(ish) and shouldn't need to ansible provision again.
Activity
gibfahn commentedon Jun 28, 2017
I guess the plan would be to confirm that all our machines are running Java 8 and then update.
jbergstroem commentedon Jun 28, 2017
gibfahn commentedon Jun 28, 2017
@jbergstroem sure, but what about the individual hosts? For example I'm pretty sure AIX is using Java 7 (see here).
For background, we upgraded our Jenkins instance, and a bunch of our slaves were suddenly unable to connect, so we had to revert.
jbergstroem commentedon Jun 28, 2017
@gibfahn I didn't get that even agents now require java 8. What kind of crazy is this :(
jbergstroem commentedon Jul 10, 2017
So, anyone with any ideas on how we move forward here? We are out of LTS meaning any security bugs (expect them) will hit us pretty hard.
bnoordhuis commentedon Jul 10, 2017
There is a Java 8 JDK for AIX (link), same for FreeBSD. The only problem might be SmartOS (which frankly I couldn't care less about.)
geek commentedon Jul 10, 2017
SmartOS has Java 8 support https://github.com/proxy/gist.github.com/dekobon/305883fb6d776b0c9fc1
jbergstroem commentedon Jul 10, 2017
There's a few older systems like centos5 which doesn't pack it either. If this is only a matter of adding more package source repos then it might not be as bad then.
gibfahn commentedon Aug 22, 2017
Discussed in the meeting (minutes: #845), consensus was that we need to deal with this. I'll put some concrete steps in the first comment.
joaocgreis commentedon Aug 28, 2017
Here is a first version of the job: https://ci.nodejs.org/view/All/job/check-java-version/2/ (Build WG only) feel free to edit as needed. I left Windows out because all Windows machines already have Java 8.
rvagg commentedon Aug 28, 2017
I improvified it: cross-platform bash execution, use the parent-of-parent to figure out how
javais executed (not usingwhich javawhich may be incorrect). Changing thegrepof the version line to be OK with OpenJDK and other types of JRE.https://ci.nodejs.org/view/All/job/check-java-version/13/ is the latest run. A quick visual inspection suggests that discounting the Pi's, we're more than 1/2 way there.
gibfahn commentedon Aug 28, 2017
Did someone delete the job? I'm not seeing one called Java.
I was going to suggest we make
grandparent java != which javaan error, unless we're aware of some specific exceptions it'd be nice if the default Java (in the path) was always the one used to run Jenkins.28 remaining items
rvagg commentedon Oct 13, 2017
Thanks everyone for contributing to this so far btw, it's been a tough job so far.
rvagg commentedon Oct 13, 2017
@nodejs/jenkins-admins FYI I've had to untick "Build if SCM changes" in the Advanced section of the MultiJob sub-jobs in node-test-commit, node-test-commit-arm-fanned and node-test-commit-windows-fanned, I guess this is new, or the default to ticked is new or something, because it's causing problems with the fanned jobs but also it's just plain annoying when testing if something works. I'm not seeing a good case for having it on in our infra.
rvagg commentedon Oct 13, 2017
Looking good: https://ci.nodejs.org/job/node-test-commit/13093/
still got the arm-fanned ESM addon tests failing, @refack is having a play with trying to fix that. It's a @nodejs/build thing rather than a core thing so if there are more of us that can lend him a hand then he'd probably appreciate it.
gdams commentedon Oct 13, 2017
okay I have brought both the AIX machine back online using a temporary version of IBM Java 8 located in
/home/iojs/jdk8/mhdawson commentedon Oct 13, 2017
There seems be a problem running the test job on AIX, investigating.
mhdawson commentedon Oct 13, 2017
Looks like it might be the way the agent was started. Don't think /etc/rc.d/rc2.d/S20jenkins start was used as these were not edited on the 2 AIX machines.
Edited and restarted agent and testing now, seems to be getting further.
mhdawson commentedon Oct 13, 2017
Ok, tests jobs on both machines passed so I think we are back to being good.
gibfahn commentedon Oct 13, 2017
We really should document this somewhere.
refack commentedon Oct 13, 2017
Cross-ref #916
doc: add basic troubleshooting guide for machines
doc: add basic troubleshooting guide for machines
doc: add basic troubleshooting guide for machines
doc: add basic troubleshooting guide for machines (#932)
rvagg commentedon Nov 13, 2017
Going to close this, there's some ansible work that's left undone from #775 (comment) and the IBM machines but mostly they relate to older distros that we're going to be phasing out soon(ish) and shouldn't need to ansible provision again.