Details
-
Type:
Bug
-
Status: Resolved (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: core
-
Labels:
-
Environment:Jenkins 1.580.1
-
Similar Issues:
Description
I noticed that when there is no installer available for a JDK, the JAVA_HOME environment variable will be empty in the environment of a build. This will happen for example when there is no installer configured for a JDK. In that case it's not hard to find the cause. But for the case I describe below it's much harder to find out why JAVA_HOME is empty.
Therefore I think logging should be improved when a specific JDK is configured for that build and no installer is available for that JDK. Furthermore JAVA_HOME should be set to match the default JVM.
Here are the steps to reproduce:
- Configure two JDK's, named JDK1 and JDK2 (because if you have only one JDK you can't select one in a job)
- Add an 'Extract .zip/.tar.gz' installer to JDK1 and set the label for this installer to 'jdk1', so it won't be available for installation on nodes to which this label is not assigned
- Create a freestyle job and select JDK1 as JDK
- Run the job and check that JAVA_HOME is empty
Attachments
Issue Links
- links to
Activity
Wilco Greven
created issue -
What bothers me is that the behaviour of the job is changed unexpectedly. When I configure a job to use a specific JVM, I expect that it will always use that JVM. This is especially important for test jobs. Logging it would already be a big improvement.
BTW, I do think the fact that JAVA_HOME is set empty is an actual bug. If Jenkins falls back to the system JDK, JAVA_HOME should be set accordingly.
Wilco Greven
added a comment - What bothers me is that the behaviour of the job is changed unexpectedly. When I configure a job to use a specific JVM, I expect that it will always use that JVM. This is especially important for test jobs. Logging it would already be a big improvement.
BTW, I do think the fact that JAVA_HOME is set empty is an actual bug. If Jenkins falls back to the system JDK, JAVA_HOME should be set accordingly. Wilco Greven
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
Wilco Greven
made changes -
| Description |
I noticed that when there is no installer available for a JDK, the JAVA_HOME environment variable will be empty in the environment of a build. This will happen for example when there is no installer configured for a JDK. In that case it's not hard to find the cause. But for the case I describe below it's much harder to find out why JAVA_HOME is empty. Therefore I think a build should fail or JAVA_HOME should not be set when a specific JDK is configured for that build and no installer is available for that JDK. Here are the steps to reproduce: - Configure two JDK's, named JDK1 and JDK2 (because if you have only one JDK you can't select one in a job) - Add an 'Extract *.zip/*.tar.gz' installer to JDK1 and set the label for this installer to 'jdk1', so it won't be available for installation on nodes to which this label is not assigned - Create a freestyle job and select JDK1 as JDK - Run the job and check that JAVA_HOME is empty |
I noticed that when there is no installer available for a JDK, the JAVA_HOME environment variable will be empty in the environment of a build. This will happen for example when there is no installer configured for a JDK. In that case it's not hard to find the cause. But for the case I describe below it's much harder to find out why JAVA_HOME is empty. Therefore I think logging should be improved when a specific JDK is configured for that build and no installer is available for that JDK. Furthermore JAVA_HOME should be set to match the default JVM. Here are the steps to reproduce: - Configure two JDK's, named JDK1 and JDK2 (because if you have only one JDK you can't select one in a job) - Add an 'Extract *.zip/*.tar.gz' installer to JDK1 and set the label for this installer to 'jdk1', so it won't be available for installation on nodes to which this label is not assigned - Create a freestyle job and select JDK1 as JDK - Run the job and check that JAVA_HOME is empty |
BTW, I do think the fact that JAVA_HOME is set empty is an actual bug. If Jenkins falls back to the system JDK, JAVA_HOME should be set accordingly.
The 'Default' or 'System' option of all tools means it uses whatever is on PATH. This has been discussed to death before. For reference see e.g. JENKINS-755, https://github.com/jenkinsci/jenkins/pull/1528, https://github.com/jenkinsci/jenkins/pull/1451.
When I configure a job to use a specific JVM, I expect that it will always use that JVM. This is especially important for test jobs. Logging it would already be a big improvement.
Try the following: Configure a JDK, set it to NOT auto-install, and leave the path empty. That's what you're effectively doing here. I would be very surprised if the behavior is different from what you're seeing.
How about this?
Started by user anonymous Building in workspace /Users/danielbeck/Projects/Jenkins/jenkins_daniel-beck/war/work/jobs/JENKINS-26940/workspace Tool installer "Install from http://archive.apache.org/dist/ant/binaries/apache-ant-1.9.4-bin.tar.gz" cannot be run on the node "Jenkins" FATAL: Cannot find executable from the chosen Ant installation "foo" Build step 'Invoke Ant' marked build as failure Finished: FAILURE
I added the third line. The issue is that the label expression does not match. Unfortunately, ToolInstallers can check for any number of constraints, so I cannot just write "The label doesn't match".
| Assignee | Daniel Beck [ danielbeck ] |
Duplicates JENKINS-24788, let's continue there.
| Resolution | Duplicate [ 3 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Workflow | JNJira [ 161124 ] | JNJira + In-Review [ 196648 ] |
| Resolution | Duplicate [ 3 ] | |
| Status | Resolved [ 5 ] | Reopened [ 4 ] |
| Status | Reopened [ 4 ] | Open [ 1 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Review [ 10005 ] |
Reopened this, I created the PR referencing this issue.
| Remote Link | This issue links to "PR 2598 (Web Link)" [ 14970 ] |
Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/tools/InstallerTranslator.java
core/src/main/resources/hudson/tools/Messages.properties
test/src/test/java/hudson/tools/InstallerTranslatorTest.java
http://jenkins-ci.org/commit/jenkins/ae29e6b2463754778c3988e62292a07a846ffe57
Log:
JENKINS-26940 Print message when installer isn't applicable (#2598)
JENKINS-26940Print message when installer isn't applicable
JENKINS-26940Only print when none found, add test
https://github.com/jenkinsci/jenkins/pull/2598 has been merged towards 2.28.
Daniel Beck do you feel other parts of this PR apart of diagnostics really need to be fixed? I doubt
| Labels | lts-candidate |
The main problem here is installers, and that got diagnostic messages, so considering this resolved.
| Resolution | Fixed [ 1 ] | |
| Status | In Review [ 10005 ] | Resolved [ 5 ] |
| Issue Type | Improvement [ 4 ] | Bug [ 1 ] |
| Summary | JAVA_HOME is empty when no installer is available for a JDK | No feedback why no installer was found for a given node |
Code changed in jenkins
User: Daniel Beck
Path:
core/src/main/java/hudson/tools/InstallerTranslator.java
core/src/main/resources/hudson/tools/Messages.properties
test/src/test/java/hudson/tools/InstallerTranslatorTest.java
http://jenkins-ci.org/commit/jenkins/e85e3e2b907f894b536332d80b997711f73c4174
Log:
JENKINS-26940 Print message when installer isn't applicable (#2598)
JENKINS-26940Print message when installer isn't applicable
JENKINS-26940Only print when none found, add test
(cherry picked from commit ae29e6b2463754778c3988e62292a07a846ffe57)
Compare: https://github.com/jenkinsci/jenkins/compare/6edd35d11b38...e85e3e2b907f
| Labels | lts-candidate | 2.19.3-rejected lts-candidate |
| Labels | 2.19.3-rejected lts-candidate | 2.19.4-fixed |
Why is this a bug? It's not difficult to imagine this being a deliberate setup ("If not on a 'jdk1' node, use the system default JDK").
Maybe logging could be improved (if there's really none), but that's it.