ReplaceTokens v6.0.4 doesn't pick up same env variables as v3,4,5

[joaquin386]

Hi,

I have realise on the AzureDevOps Tasks 6.0.4 that if you try to replace a ADO Env Variable like BUILD_DEFINITONNAME it fails in v6 but not in v5,4,3 so making it backwards incompatible.

v6:
##[warning]variable 'BUILD_DEFINITIONNAME' not found
BUILD_DEFINITIONNAME:
v5:
BUILD_DEFINITIONNAME: dal-appmesh-test

if I put it in the file as BUILD.DEFINITIONNAME works in both versions.
I realize that before running the replacetokens in v6 there is a step load variables

Env variables when I bash into the agents with an env:
BUILD_DEFINITIONNAME=dal-appmesh-test

So is there something missing from my end or just that this is a behaviour change which is uncompatible from what we have as we have in ALL our repos the BUILD_DEFINITIONNAME not the . (and can not replace _ for . as there might be legitimate custom env variables with _)

Screenshot v6:

Screenshot v5:

Env variable after executing env in the agent:

BR

Joaquin

[joaquin386]

Same when loading env variables:
Works:

    additionalVariables: |
      $BUILD.DEFINITIONNAME

Doesn't work:

    additionalVariables: |
      $BUILD_DEFINITIONNAME

Error:

loading variables from env 'BUILD_DEFINITIONNAME'
##[error]SyntaxError: Unexpected token d in JSON at position 0

Seems as the only option you are allowing is the . for the env variables when on the older versions the _ was also allowed.

[qetza]

Hi @joaquin386,
You are correct that this is a change from the previous versions as the v6 is reading the azure pipelines variables with their real names (with dot) and there is no automatic rename as before; this is due to internal changes to make the code compatible with GitHub Actions and local CLI.

If you cannot change the name of your tokens you have the following options:

• use the v5
• add the variable with the name you use as additional variables, here is the correct syntax:

  additionalVariables: |
    BUILD_DEFINITIONNAME: $(Build.DefinitionName)

  this will add to the list of variables the variable BUILD_DEFINITIONNAME with the build definition name as the value.
  (using the $BUILD_DEFINITIONNAME syntax tells the task to read the environment variable BUILD_DEFINITIONNAME and parse it as a JSON containing a list of key/value pairs which is not what you want 😄)

[joaquin386]

Hi, Thanks for the explanation!!! Most likely we will be using v5 as I do not know how many _ env variables have been set around all our projects.
I assume this incident can be close now.

[qetza]

I'll keep it open as a reminder for me to update the README of v6 to make it clearer that the task is now using the real variable names (the names defined in variables, variable groups and the default variables in the MS documentation) and doesn't support anymore the normalized names done by MS internally.

[qetza]

Hi, Thanks for the explanation!!! Most likely we will be using v5 as I do not know how many _ env variables have been set around all our projects. I assume this incident can be close now.

Note that for a variables with the name BUILD_DEFINITIONNAME or BUILD.DEFINITIONNAME are the same as the agent is normalizing all names to create environment variables so the variable BUILD.DEFINITIONNAME will become BUILD_DEFINITIONNAME whatever the version of the task.

The difference is on how the task is getting the values using the MS lib

• in v3, v4 and v5 the task is reading the token name and then getting through the MS lib the value, the lib will normalize the name and look for an environment variable with this name (so asking for a.b or a_b will result in the same value returned)
• in v6 the task is first getting all the variable name and values through the MS lib which is returning the real names and the values (so a.b and a_b will still have the same value but they are 2 different variables) and then will parse the tokens.

[qetza]

Hi @joaquin386,
I've release a new patch on v6 (6.0.5) with a reworked core lib which now allows to used normalized names in your token as in the previous versions.
So using BUILD_DEFINITIONNAME in your files will now be replaced correctly.

[joaquin386]

Thats amazing, thanks for the patch release. Will test it next week and let you know the result

[joaquin386]

It works as expected version 6.0.5. Thanks for the fix.