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

Variables resolved alphabetically rather than order found in content/file. ${WORKSPACE} not always getting resolved as result

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Blocker
    • Resolution: Fixed
    • Component/s: envinject-plugin
    • Labels:
      None
    • Environment:
      Windows Server 2003
    • Similar Issues:

      Description

      This is two related bugs I have found that are most likely caused by a similar issue if not the same one.

      --------------------------------------------------------------------------
      First:
      When doing multiple sequential substitutions, variables are getting resolved alphabetically rather than in the order that they were found in the properties content/file.

      ***Example properties content:
      VAR1=VALUE
      VAR2=$

      {VAR1}

      VAR3=$

      {VAR2}

      VAR4=$

      {VAR3}

      VAR9=VALUE
      VAR8=$

      {VAR9}
      VAR7=${VAR8}
      VAR6=${VAR7}

      ***Example Output:
      VAR1=VALUE
      VAR2=VALUE
      VAR3=VALUE
      VAR4=VALUE

      VAR6=${VAR8} <-- Should be resolved to VALUE
      VAR7=${VAR9}

      <-- Should be resolved to VALUE
      VAR8=VALUE
      VAR9=VALUE

      It seems like the implementation puts all the variables in an alphabetically sorted list and then steps through
      the list and tries to resolve each variable resolving 1 extra step deep. For example, since this is done seemingly alphabetically, VAR6 is resolved before VAR7 (incorrectly). It seems then that since VAR6=$

      {VAR7}

      , which is not resolved, the code goes one step further total to resolve VAR7 to $

      {VAR8} and then quits (not recursive) to yield VAR6=${VAR8}

      .
      Implementing the resolving sequentially as found in the properties file/content would resolve this issue entirely. This gives the build step implementer control over the variable resolution order as well as prevents a circular resolving problem that occurs when doing an alphabetical resolution process (which I'm guessing is why resolving only goes 2 total steps deep).

      --------------------------------------------------------------------------
      Second:
      This bug only occurs when using a properties file, but not a properties content section. If the $

      {WORKSPACE} variable is used in a properties file and comes alphabetically after the variable being assigned it will not be resolved.

      ***Example properties file:
      VAR_FILE_Z=${WORKSPACE}

      VAR_FILE_Y=$

      {VAR_FILE_Z}
      VAR_FILE_X=${VAR_FILE_Y}

      ZVAR_FILE_Z=${WORKSPACE}
      ZVAR_FILE_Y=${ZVAR_FILE_Z}
      ZVAR_FILE_X=${ZVAR_FILE_Y}

      ***Example output (WORKSPACE=D:\jenkins_\temp)
      VAR_FILE_X=${VAR_FILE_Z}

      <-- Same as problem #1 above
      VAR_FILE_Y=$

      {WORKSPACE}

      <-- Should be resolved to D:\jenkins_\temp.
      VAR_FILE_Z=D:\jenkins_\temp

      ZVAR_FILE_X=$

      {ZVAR_FILE_Z}

      <-- Same as problem #1 above
      ZVAR_FILE_Y=D:\jenkins_\temp
      ZVAR_FILE_Z=D:\jenkins_\temp

      If that same content in the properties file is pasted into the properties content section, than the WORKSPACE is resolved correctly. It seems to be related to problem #1 above because it does not occur when re-ordered alphabetically as shown (that is making WORKSPACE come before the variable name ZVAR...)

        Attachments

        1. asdf_alpha_rev.txt
          0.1 kB
        2. asdf_alpha.txt
          0.1 kB
        3. config.xml
          3 kB
        4. workspace_alpha_rev.txt
          0.2 kB
        5. workspace_alpha.txt
          0.1 kB

          Activity

          pixman20 pixman20 created issue -
          pixman20 pixman20 made changes -
          Field Original Value New Value
          Description This is two related bugs I have found that are most likely caused by a similar issue if not the same one.

          --------------------------------------------------------------------------
          First:
          When doing multiple sequential substitutions, variables are getting resolved alphabetically rather than in the order that they were found in the properties content/file.

          ***Example properties content:
          VAR1=VALUE
          VAR2=${VAR1}
          VAR3=${VAR2}
          VAR4=${VAR3}

          VAR9=VALUE
          VAR8=${VAR9}
          VAR7=${VAR8}
          VAR6=${VAR7}

          ***Example Output:
          VAR1=VALUE
          VAR2=VALUE
          VAR3=VALUE
          VAR4=VALUE

          VAR6=${VAR8} <-- Should be resolved to VALUE
          VAR7=${VAR9} <-- Should be resolved to VALUE
          VAR8=VALUE
          VAR9=VALUE

          It seems like the implementation puts all the variables in an alphabetically sorted list and then steps through
          the list and tries to resolve each variable resolving 1 extra step deep. For example, since this is done seemingly alphabetically, VAR6 is resolved before VAR7 (incorrectly). It seems then that since VAR6=${VAR7}, which is not resolved, the code goes one step further total to resolve VAR7 to ${VAR8} and then quits (not recursive) to yield VAR6=${VAR8}.
          Implementing the resolving sequentially as found in the properties file/content would resolve this issue entirely. This gives the build step implementer control over the variable resolution order as well as prevents a circular resolving problem that occurs when doing an alphabetical resolution process (which I'm guessing is why resolving only goes 2 total steps deep).


          --------------------------------------------------------------------------
          Second:
          This bug only occurs when using a properties file, but not a properties content section. If the ${WORKSPACE} variable is used in a properties file and comes alphabetically after the variable being assigned it will not be resolved.

          ***Example properties file:
          VAR_FILE_Z=${WORKSPACE}
          VAR_FILE_Y=${VAR_FILE_Z}
          VAR_FILE_X=${VAR_FILE_Y}

          ZVAR_FILE_Z=${WORKSPACE}
          ZVAR_FILE_Y=${ZVAR_FILE_Z}
          ZVAR_FILE_X=${ZVAR_FILE_Y}

          ***Example output (WORKSPACE=D:\jenkins\_\temp)
          VAR_FILE_X=${VAR_FILE_Z} <-- Same as problem #1 above
          VAR_FILE_Y=${WORKSPACE} <-- Should be resolved to D:\jenkins\_\temp.
          VAR_FILE_Z=D:\jenkins\_\temp

          ZVAR_FILE_X=${ZVAR_FILE_Z} <-- Same as problem #1 above
          ZVAR_FILE_Y=D:\jenkins\_\temp
          ZVAR_FILE_Z=D:\jenkins\_\temp

          If that same content in the properties file is pasted into the properties content section, than the WORKSPACE is resolved correctly. It seems to be related to problem #1 above because it does not occur when re-ordered alphabetically as shown.
          This is two related bugs I have found that are most likely caused by a similar issue if not the same one.

          --------------------------------------------------------------------------
          First:
          When doing multiple sequential substitutions, variables are getting resolved alphabetically rather than in the order that they were found in the properties content/file.

          ***Example properties content:
          VAR1=VALUE
          VAR2=${VAR1}
          VAR3=${VAR2}
          VAR4=${VAR3}

          VAR9=VALUE
          VAR8=${VAR9}
          VAR7=${VAR8}
          VAR6=${VAR7}

          ***Example Output:
          VAR1=VALUE
          VAR2=VALUE
          VAR3=VALUE
          VAR4=VALUE

          VAR6=${VAR8} <-- Should be resolved to VALUE
          VAR7=${VAR9} <-- Should be resolved to VALUE
          VAR8=VALUE
          VAR9=VALUE

          It seems like the implementation puts all the variables in an alphabetically sorted list and then steps through
          the list and tries to resolve each variable resolving 1 extra step deep. For example, since this is done seemingly alphabetically, VAR6 is resolved before VAR7 (incorrectly). It seems then that since VAR6=${VAR7}, which is not resolved, the code goes one step further total to resolve VAR7 to ${VAR8} and then quits (not recursive) to yield VAR6=${VAR8}.
          Implementing the resolving sequentially as found in the properties file/content would resolve this issue entirely. This gives the build step implementer control over the variable resolution order as well as prevents a circular resolving problem that occurs when doing an alphabetical resolution process (which I'm guessing is why resolving only goes 2 total steps deep).


          --------------------------------------------------------------------------
          Second:
          This bug only occurs when using a properties file, but not a properties content section. If the ${WORKSPACE} variable is used in a properties file and comes alphabetically after the variable being assigned it will not be resolved.

          ***Example properties file:
          VAR_FILE_Z=${WORKSPACE}
          VAR_FILE_Y=${VAR_FILE_Z}
          VAR_FILE_X=${VAR_FILE_Y}

          ZVAR_FILE_Z=${WORKSPACE}
          ZVAR_FILE_Y=${ZVAR_FILE_Z}
          ZVAR_FILE_X=${ZVAR_FILE_Y}

          ***Example output (WORKSPACE=D:\jenkins\_\temp)
          VAR_FILE_X=${VAR_FILE_Z} <-- Same as problem #1 above
          VAR_FILE_Y=${WORKSPACE} <-- Should be resolved to D:\jenkins\_\temp.
          VAR_FILE_Z=D:\jenkins\_\temp

          ZVAR_FILE_X=${ZVAR_FILE_Z} <-- Same as problem #1 above
          ZVAR_FILE_Y=D:\jenkins\_\temp
          ZVAR_FILE_Z=D:\jenkins\_\temp

          If that same content in the properties file is pasted into the properties content section, than the WORKSPACE is resolved correctly. It seems to be related to problem #1 above because it does not occur when re-ordered alphabetically as shown (that is making WORKSPACE come before the variable name ZVAR...)
          Hide
          pixman20 pixman20 added a comment -

          Updating priority to blocker since this prevents main functionality

          Show
          pixman20 pixman20 added a comment - Updating priority to blocker since this prevents main functionality
          pixman20 pixman20 made changes -
          Priority Critical [ 2 ] Blocker [ 1 ]
          Hide
          gbois Gregory Boissinot added a comment -

          Could you upload your job configuration file?

          Show
          gbois Gregory Boissinot added a comment - Could you upload your job configuration file?
          gbois Gregory Boissinot made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          pixman20 pixman20 made changes -
          Attachment config.xml [ 21303 ]
          Attachment asdf_alpha.txt [ 21304 ]
          Attachment asdf_alpha_rev.txt [ 21305 ]
          Attachment workspace_alpha.txt [ 21306 ]
          Attachment workspace_alpha_rev.txt [ 21307 ]
          Hide
          pixman20 pixman20 added a comment -

          Sure, I uploaded the job config and the 4 properties file's it references (really should have been 1, but oh well)

          Show
          pixman20 pixman20 added a comment - Sure, I uploaded the job config and the 4 properties file's it references (really should have been 1, but oh well)
          Hide
          gbois Gregory Boissinot added a comment -

          EnvInject 1.1 fixes the bug.
          Thanks

          Show
          gbois Gregory Boissinot added a comment - EnvInject 1.1 fixes the bug. Thanks
          gbois Gregory Boissinot made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 142356 ] JNJira + In-Review [ 190097 ]

            People

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

              Dates

              • Created:
                Updated:
                Resolved: