Azure-pipelines-agent: Why are environment variable names converted to uppercase?

[simonhaenisch]

Agent Version and Platform

Hosted macOS Preview

VSTS Type and Version

VisualStudio.com

What's not working?

I was trying for hours to figure out why my environment variables weren't picked up by my tests on VSTS on a hosted macOS, until I printed them out...

Setting them in the "Variables" tab of the build definition:

Then running

node -e "console.log(JSON.stringify(process.env, null, 2))"

within a "Command Line Script" gave me:

{
  // ...
  "CYPRESS_CI": "true",
  // ...
}

They are being converted to uppercase. Is that expected bahaviour?

I looked at https://docs.microsoft.com/en-nz/vsts/pipelines/build/variables?view=vsts&tabs=batch#environment-variables. I know WiNdOwS doesn't care about upper and lower case but the rest of the world does.

[TingluoHuang]

@simonhaenisch By design, the agent replace . with _ and toUpper() every definition variables when it run every task.
The new Commandline task allow you provide lowercase environment variables.

[simonhaenisch]

I actually was aware that the variables were working within the command line task settings (I tried that during my debugging), however I need the same variables for multiple tasks and that is unmaintainable that way.

By design, the agent replace . with _ and toUpper() every definition variables when it run every task.

Would be nice if that was at least mentioned somewhere in the docs I linked. Might help other developers not waste hours on debugging this (and maybe they won't hate Microsoft after all).

IMO this behavior is kind of ok on a hosted windows machine (even though i don't see any benefits in converting them, but I know it's normal on windows to use uppercase), but not on hosted macOS, since I expect my env setup to work the same way whether I run it on my local macOS or a hosted macOS. I think this should be made platform-agnostic.

[TingluoHuang]

@simonhaenisch
thanks for your feedback.
We replace . since it's not valid on linux, we .toUpper() everything is also trying to make thing easy on linux. So when you consume your variable, you don't have to worry about casing.

The doc is kind of talked about that, but i don't think it is super clear.
I already talked with our doc author, he will fix it soon.

[bryanmacfarlane]

Answered

[willmorgan]

This is still not ideal. Elsewhere in the Microsoft ecosystem - Function Apps as an example - connection strings are case-sensitive, and _Microsoft sets the name, including case, for you_.

Ironically by trying to make things easy on Linux, it's actually made it a lot more difficult.

Can this functionality please be reviewed and fixed?

[hbuckle]

Agreed - this behaviour is not helpful. I'd like to read all environment variables and pass the names and values through to various tools, which are case sensitive.

[andreacassioli]

Definitely agree with @willmorgan . I think you should not touch what users manually define. It is very confusing to be able to define variables name that do not actually hold. Moreover you might have a tool that expect some env variable with lower case names. How do you go for that?