Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26940

No feedback why no installer was found for a given node

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • core
    • Jenkins 1.580.1

      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

          [JENKINS-26940] No feedback why no installer was found for a given node

          Wilco Greven created issue -

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          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 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 -
          Issue Type Original: Bug [ 1 ] New: Improvement [ 4 ]
          Wilco Greven made changes -
          Description Original: 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
          New: 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

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          Daniel Beck added a comment -

          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".

          Daniel Beck added a comment - 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".
          Daniel Beck made changes -
          Assignee New: Daniel Beck [ danielbeck ]

          Daniel Beck added a comment -

          Duplicates JENKINS-24788, let's continue there.

          Daniel Beck added a comment - Duplicates JENKINS-24788 , let's continue there.
          Daniel Beck made changes -
          Resolution New: Duplicate [ 3 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

            danielbeck Daniel Beck
            wgreven Wilco Greven
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: