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
Field | Original Value | New Value |
---|---|---|
Issue Type | Bug [ 1 ] | Improvement [ 4 ] |
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 |
Assignee | Daniel Beck [ danielbeck ] |
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 ] |
Remote Link | This issue links to "PR 2598 (Web Link)" [ 14970 ] |
Labels | lts-candidate |
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 |
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.