Build.DefinitionName is BUILD_DEFINITIONNAME when I access it outside of the yaml pipeline. Giving what the actual Envrionment Varialbe designation is would be useful as the conventions aren't consistent.
Build.BuildNumber => BUILD_BUILDNUMBER
Build.DefinitionName => BUILD_DEFINITIONNAME
If Build.DefinitionName resolved to BUILD_BUILDDEFINITIONNAME there would be less of a need because I could count on the convention of whatever root node I am looking for would be in the name of the variable. But this isn't the convention. So seeing this information on the docs would be helpful.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Somewhere in the docs I read that all of the dot-notation variables are transformed with a specific rule set when they become environment variables, so they are consistent, just not the way you're expecting them to be.
As far as I can remember, the variable names are uppercased and periods are replaced with underscores. Considering that, the variable names you used as an example are what should be expected.
Okay. That is good to know. Is there still value in putting them on the page? Or making the conversion rule more accessible?
@RLittlesII Thank you for flagging this area of confusion. We've added a section with more details on how variables work that includes how they transform. When pipeline variables are turned into environment variables, variable names become uppercase and periods turn into underscores. You can learn more here.