I am trying to create an environment variable that represents the build version in the format x.y where
x is some fixed value and
y is incremented by azure per build
I've tried creating a variable that is a concatenation of fixed value and Azure's built-in variable Build.BuildId (see docs):
1.${Build.BuildId}
I was hoping it would get extrapolated into e.g. 1.1 but when I ran the pipeline it failed on docker push with the following error:
Error parsing reference: "private.registry.com/app:1.${Build.BuildId}" is not a valid repository/tag: invalid reference format
so clearly the extrapolation did not work. Any ideas how to properly reference Build.BuildId inside the variable definition?
you need to wrap the predefined variable in $() not ${} in your environment variable definition.
BUILD_NUMBER = 1.$(Build.BuildId)
Related
I've run into a specific problem while trying to automate a tagging process in terraform. I've set an environment variable that is essentially a list of all the tags we'd be using for all resources provisioned in the apply. It looks like this...
export TF_VAR_taglist='{JiraEpic = "ETOS-56","AssignedResearcherPri" = "Isaac",AssignedResearcherSec = "Matt"}'
After setting the environment variable I added a variable called "taglist" in the variables.tf file that grabs the aforementioned environment variable. It looks like this...
variable "taglist"{}
Lastly, I have another locals.tf file where i set a common_tags variable. Like so...
locals { common_tags ="${var.taglist}" }
When i terraform apply, the build fails while trying to map the tags properly. This is the error i receive...
Error: Incorrect attribute value type
on kube_master_worker_nodes_ec2.tf line 9, in resource "aws_instance" "master":
9: tags = local.common_tags
|----------------
| local.common_tags is "{JiraEpic = \"ETOS-56\",AssignedResearcherPri = \"Isaac \",AssignedResearcherSec = \"Matt\"}"
Inappropriate value for attribute "tags": map of string required.
I then decided to define the type of the variable as map(string in the variables.tf file like this
variable "taglist"{ type = map(string) }
I had hoped that this would allow terraform to recognize this variable as a map of strings and not just a string literal, but I was wrong, and these are the errors I get when that definition is applied.
Error: Missing attribute separator
on <value for var.taglist> line 1:
(source code not available)
Expected a newline or comma to mark the beginning of the next attribute.
Error: No value for required variable
on variables.tf line 11:
11: variable "taglist"{
The root module input variable "taglist" is not set, and has no default value.
Use a -var or -var-file command line argument to provide a value for this
variable.
I'm really stuck on this, and I feel like I'm close. Can anyone provide some insight into this and how I should go about solving it?
I want to first thank Martin Atkins for giving me the idea of using colons instead of equal signs in my environment variable, because that was the ONLY issue. The variable was not properly represented as a JSON object so terraform was interpreting it as a string.
I changed
export TF_VAR_taglist='{JiraEpic = "ETOS-56","AssignedResearcherPri" = "Isaac",AssignedResearcherSec = "Matt"}'
to this
export TF_VAR_taglist='{"JiraEpic":"ETOS-56","AssignedResearcherPri":"Isaac", "AssignedResearcherSec":"Matt"}'
The build purrs like a kitten on catnip now.
Terraform uses the type constraint of a variable to decide how to interpret a string representation of its value. By default, Terraform will assume the value expects a primitive type such as a string or number, because that's the most typical case for variables set via the command line or environment variables.
Since your tag list is a list you need Terraform to interpret it as a map expression rather than as a string. You can tell Terraform to do that by telling Terraform which type of value you expect:
variable "taglist" {
type = map(string)
}
You can read more about this in the Terraform documentation section Complex-typed Values.
You then need to make sure that the value in the environment variable is a valid object expression in order to avoid a syntax error. If you're setting the environment variable from the shell command line then you need to be mindful of escaping/quoting to ensure that Terraform will see the value with all of the quotes intact, and without any extra metacharacters.
The result is often hard to read clearly, which is why the Terraform documentation recommends using a .tfvars file to set complex-typed variables, instead of the -var command line option or environment variables. However, since you are using automation you might find it easier to generate a .tfvars.json file instead, which uses standard JSON format and is therefore easier to generate using JSON libraries available in most programming languages. Here's the .tfvars.json equivalent of the value you showed in your question:
{
"taglist": {
"JiraEpic": "ETOS-56",
"AssignedResearcherPri": "Isaac",
"AssignedResearcherSec": "Matt"
}
}
Note that subjectively I'd find it pretty confusing to have a variable whose name ends in list when it actually expects a map. A more typical name for this variable would be just tags, though if it's useful to mention its type in order to distinguish it from other variables then I'd suggest tag_map instead, to make it less confusing.
In the TravisCI webapp, I've specified an environment variable called "BUILD_BRANCH". I would like to use this variable in the .travis.yml branch declaration, but TravisCI is reading it as a literal string "$BUILD_BRANCH".
I've looked for examples and references of this type of usage online and couldn't find any. I've also emailed them for support but they haven't gotten back to me yet.
branches:
only:
- $BUILD_BRANCH
I've tried both "$BUILD_BRANCH" and "${BUILD_BRANCH}".
Environment variables are expanded in the build, not in the place where the build matrix is expanded in jobs to be run. You would need to hard code this value.
TFS release management has a concept of variables. They're set in the release definition at design time. Is there a way for tasks to change variables so that other tasks see the changes?
The Windows SET command only affects the environment of the currently executing instance of cmd.exe, it doesn't affect the enclosing process' environment.
Passing info from step to step in a temp file in the working folder is possible, but crude.
I believe so. I have not tested this, but take a look at this VSO Build Task:
https://marketplace.visualstudio.com/items?itemName=jessehouwing.jessehouwing-vsts-variable-tasks
It has a task where it can set the variable. Here is the specific powershell script it calls:
https://github.com/jessehouwing/vsts-variable-tasks/blob/master/vsts-variable-set/vsts-variable-set.ps1
Line 22:
Write-Host "##vso[task.setvariable variable=$($VariableName);]$Value"
UPDATE:
I have since found Microsoft documentation here:
https://github.com/Microsoft/vsts-tasks/blob/master/docs/authoring/commands.md
Specifically:
vso[task.setvariable]value
variable=variable name (Required)
issecret=true (Optional)
Sets a variable in the variable service of taskcontext. The first task can set a variable, and following tasks are able to use the variable. The variable is exposed to the following tasks as an environment variable. When issecret is set to true, the value of the variable will be saved as secret and masked out from log. Secret variables are not passed into tasks as environment variables and must be passed as inputs.
Examples:
##vso[task.setvariable variable=testvar;]testvalue
##vso[task.setvariable variable=testvar;issecret=true;]testvalue
I need use the $(Rev) property in an argument passed to MSBuild as part of my build process. I have defined MajorVersion, MinorVersion and PatchVersion as variables in my build definition, and I can use these in my arguments. If I pass an argument to MSBuild that contains this string: $(MajorVersion).$(MinorVersion).$(PatchVersion)-beta$(Rev:r) it evaluates to something like 1.3.2-beta$(Rev:r), which causes problems. If I pass this argument: $(MajorVersion).$(MinorVersion).$(PatchVersion)-beta$(Build.BuildId) then it correctly resolves to something like 1.3.2-beta204. I also in time would like to replace the SemVer tag with a variable, e.g. beta, rc, etc., so I can adopt a git-flow approach to my builds and versioning.
Any ideas why $(Rev) isn't usable?
Don't confuse build number format tokens with build variables.
$(Rev:.r) is a one of the tokens, resolved by the TFS build in runtime. You were correct to pass the resolved variable which encapsulates the build number format.
Alternatively, you can use $(Build.BuildNumber) in MSBuild with build number format 1.3.2-beta$(Rev:.r)
I'd like to pass some variables into my .nsi script. Either from the environment or the command line, how do I do this?
I found a section in the documentation that suggests I can use the syntax $%envVarName% to use environment variables in my script, but this doesn't seem to work, when I have
File "/oname=$pluginsdir\inst.msi" "$%VERSION%-Installer-64bit.msi"
I get the error
File: "$%VERSION%-Installer-64bit.msi" -> no files found.
$VERSION is in my environment.
Is there something I'm doing wrong with trying to read environment variables, or some other way of passing values into my script?
$%VERSION% should work if you used set VERSION=1.2.3.4
Or you can create defines: makensis -DVERSION=1.2.3.4 myscript.nsi and File: "${VERSION}-Installer-64bit.msi"