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

Properties not injected and build marked as failed

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Component/s: envinject-plugin
    • Labels:
      None
    • Environment:
      os.name Linux
      os.arch amd64
      os.version 2.6.18-128.1.10.el5xen

      Jenkins 1.426
      EnvInject 0.11
    • Similar Issues:

      Description

      On slaves EnvInject does not inject properties from a file and markes the build FAILED without printing a reason to the console.
      The properties file to read Environment Variables from needs to come from SVN.

      I tried the following on a test job (a matrix configuration configured for master and slave nodes, I also tried it on a parameterized freestyle job, with same results):

      Build Environment > Inject environment variables to the build process > Properties File Path=src/test.properties
      (also tried it with ${WORKSPACE}/src/meta.properties with same result)

      This prints:
      [EnvInject] - Injecting as environment variables the properties file path 'src/test.properties'
      to the console output

      Next, as an Execute shell Buildstep I do:
      echo xxx=${propertySetIn_test.properties_}
      echo WORKSPACE=${WORKSPACE}
      ls -al ${WORKSPACE}/src/test.properties

      This prints 'xxx=' to the console output, the correct workspace on the slave, and proves that the file exists.

      Then, in a second Buildstep of type 'Inject environment variables' I then try to insert from the same file, followed by the same tests.

      This prints
      [EnvInject] - Injecting as environment variables the properties file path '/path/to/my/workspace/test_envinject_Matrix/label/slave1/src/test.properties'
      Build step 'Inject environment variables' changed build result to FAILURE
      Build step 'Inject environment variables' marked build as failure
      Finished: FAILURE

      Further remarks:
      On the master the first pass (in the Build Environment section) does not seem to result in properties being inserted, as they cannot be echoed. After the second pass (injecting as a Build Step) the properties are set on the master, as they can be echoed.
      These results seem unaffected by setting 'Prepare an environmetn for the job (with both Keep options enabled) and the System Configuration 'Prepare jobs environment > Unset System Environment Variables' settings.

        Attachments

          Activity

          Hide
          gbois Gregory Boissinot added a comment -

          Could you also attach your configuration job file (config.xml)?

          Show
          gbois Gregory Boissinot added a comment - Could you also attach your configuration job file (config.xml)?
          Hide
          gbois Gregory Boissinot added a comment -

          You can also test the last version (0.13) to have more logs.

          Show
          gbois Gregory Boissinot added a comment - You can also test the last version (0.13) to have more logs.
          Hide
          josbraaksma Jos Braaksma added a comment -

          Hi Gregory,
          thanks a lot for your efforts. Requested files attached.
          Jos

          Using version 0.13.1

          config.xml and meta.properties are attached, meta.properties lives in SVN.
          A build is created on on either the master or a slave, depending on a NodeLabel parameter 'triggerednode'.
          On the master all runs fine, on the slave (which is actually on the same machine as the master) a 'remote file operation failed' message is printed to the console:

          <quote>
          Started by user Jos
          Building remotely on slave1
          Updating svn://corporate.svn.server/Jenkins/JenkinsTest/trunk
          At revision 10
          no change for svn://corporate.svn.server/Jenkins/JenkinsTest/trunk since the previous build
          [EnvInject] - Injecting as environment variables the properties file path 'src/meta.properties'
          [EnvInject] - [ERROR] - remote file operation failed: /home/jenkins/.jenkinsslave/workspace/test_envinject_parameterizedNode at hudson.remoting.Channel@8ea9cf1:slave1
          Finished: FAILURE
          </quote>

          The grander scheme is to trigger a deployment task on a configurable (through meta.properties) environment, after a build.
          I did not add the config.xml for the triggered job. It is a parameterized job with NodeLabel parameter 'node'. Create this one if needed by copying the attached job and remove the BuildTrigger to avoid a loop.

          Show
          josbraaksma Jos Braaksma added a comment - Hi Gregory, thanks a lot for your efforts. Requested files attached. Jos Using version 0.13.1 config.xml and meta.properties are attached, meta.properties lives in SVN. A build is created on on either the master or a slave, depending on a NodeLabel parameter 'triggerednode'. On the master all runs fine, on the slave (which is actually on the same machine as the master) a 'remote file operation failed' message is printed to the console: <quote> Started by user Jos Building remotely on slave1 Updating svn://corporate.svn.server/Jenkins/JenkinsTest/trunk At revision 10 no change for svn://corporate.svn.server/Jenkins/JenkinsTest/trunk since the previous build [EnvInject] - Injecting as environment variables the properties file path 'src/meta.properties' [EnvInject] - [ERROR] - remote file operation failed: /home/jenkins/.jenkinsslave/workspace/test_envinject_parameterizedNode at hudson.remoting.Channel@8ea9cf1:slave1 Finished: FAILURE </quote> The grander scheme is to trigger a deployment task on a configurable (through meta.properties) environment, after a build. I did not add the config.xml for the triggered job. It is a parameterized job with NodeLabel parameter 'node'. Create this one if needed by copying the attached job and remove the BuildTrigger to avoid a loop.
          Hide
          gbois Gregory Boissinot added a comment -

          I'm afraid I can't reproduce the problem.

          Show
          gbois Gregory Boissinot added a comment - I'm afraid I can't reproduce the problem.
          Hide
          gbois Gregory Boissinot added a comment - - edited

          I tested again with your configuration and there is no problems.
          I marks the issue as fixed.
          Please could you reopen the issue if the problem persists with 0.15

          Show
          gbois Gregory Boissinot added a comment - - edited I tested again with your configuration and there is no problems. I marks the issue as fixed. Please could you reopen the issue if the problem persists with 0.15

            People

            • Assignee:
              gbois Gregory Boissinot
              Reporter:
              josbraaksma Jos Braaksma
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: