Closed joaquin386 closed 5 months ago
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.
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:
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 :smile:)
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.
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.
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
a.b
or a_b
will result in the same value returned)a.b
and a_b
will still have the same value but they are 2 different variables) and then will parse the tokens.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.
Thats amazing, thanks for the patch release. Will test it next week and let you know the result
It works as expected version 6.0.5. Thanks for the fix.
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 BUILDDEFINITIONNAME 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