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

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

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

        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 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: