In TFS 2015 and later, is it possible to resolve a user-defined variable in the build definition demands?
Context
A build definition requires certain software A on its build agent, so I set the an custom agent capability A = path/to/A.
I want to use this path in my build definition and make sure that the build definition uses the correct path before starting a build.
Since TFS does not support referencing the values of agent capabilities inside steps of a build definition or release definition, I'm trying to create a workaround. I don't want to use the custom environment variable on the build machine since I want to avoid the additional build step which is required to pass the env variable to TFS build steps.
The planned workaround
Having a variable SoftwareA in build definition containing path/to/A which can be used by the build steps.
In build definition -> general -> demands check if A equals $(SoftwareA).
However $(SoftwareA) seems not to be resolved by TFS and instead is taken literally.
No, unfortunately the variable is never expanded outside the build/release environment.
So you need to change the demand value manually to match the path you defined in agent capabilities.
That means add demands A equals path/to/A.
There is a user voice here to suggest this feature, but it's archived. You can submit a new user voice again to suggest this feature.
Related
According to my post:
Build Definition XAML -> TFS2015
which is duplicated with:
How to handle multiple configurations in VSTS Release management?
I have one more question about Build Proces in TFS 2015. can someone tell me how can I set two outputs path after build? I mean one for x64 bit and second for x32 bit during one build process?
../Release/x64/..
../Release/x32/..
Build Platform is set to "MixedPlatform". I did try also with "Any CPU" without result...
My configuration is in the first link.
I'm assuming you have a multiplier set up on the BuildConfiguration or BuildPlatform variables, or on both, so that the build process runs multiple times for each permutation.
In that case, you just need to override your output path (usually /p:OutDir=(some path)). In this case, you'd override it to $(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform). That will put the outputs for the current permutation of your build to a specific folder for that permutation.
Then, in your publish artifacts task, make sure you're publishing an artifact pointing to $(Build.ArtifactStagingDirectory)\$(BuildConfiguration)\$(BuildPlatform) with a unique name, like Web_$(BuildConfiguration)-$(BuildPlatform)
Then, when the builds are all done, you'll have multiple sets of artifacts attached to the build, one for each permutation. You can then consume those artifacts down-stream in a release definition.
I'm working with TFS on-premise.
My issue is that during a release I have two agent phases separated by a manual intervention.
In the first agent phase, I set a variable with:
Write-Verbose $("##vso[task.setvariable variable={0};]{1}" -f $variablename, $variable)
Problem is that in the second agent phase, this variable doesn't exist anymore, even if the same agent is used for the second release phase.
How may I pass a variable between two agent phases during the same release?
There is no way to persist variables (no matter powershell variables or VSTS user defined variables) between two agent phases (and environments) for now.
And there is a related issue Variables set via logging commands are not persistent between agents, you can follow up.
The work around for now is define the variable again in next agent phase.
You can share a variable between the agent phases by using the TFS Rest API and creating a new variable in the release.
You can create a helper module to facilitate this task.
Get the release by using the environment variable $Env:Release_ReleaseId.
Add a NoteProperty, using Add-Member, to the variables hashtable of the release returned in step 1, where the name is your desired variable name and the value is a ConfigurationVariableValue.
Save the release with the added variable.
In order to use this approach, you would set the variable in your first agent. Then, in the second agent, you can simply read the TFS variable using the $(VariableName) semantic.
I've used the "Variable dehydration task" to write the value to my artifact folder in a build pipeline. I then read the json with inline-powershell. Currently, I'm reading it on every task in my release pipeline, which seems mental to me, but it sort of works. You ought to be able to set a global or env? variable and use that instead. Supposedly fixed in 2017, but I'm using 2015.
The right way to do it is using Variablegroups to persist between pipelines: https://learn.microsoft.com/en-us/azure/devops/pipelines/library/variable-groups?view=azure-devops&tabs=yaml
A Build definition has a custom variable that can be set when a build is queued.
Is possible to have access to that variable from a Release in the same way that is possible to have access to variables like Build.DefinitionId, Build.DefinitionName, Build.BuildNumber ?
I've managed to do this with an extension from the TFS marketplace, called 'Variable (de|re)Hydration Tasks', from naked Agility Ltd. This extension provides build- and release tasks with which you basically can save your build variables and restore them in your release.
It does this by prefixes, so you can save/restore all default build variables that are prefixed with 'BUILD-', but if you prefix your own variables with i.e. 'ABC_' you can also save them from your build and restore them in your release.
A custom build variable couldn't be used in your release definition. Here is an user voice that similar to your problem: https://visualstudio.uservoice.com/forums/330519-team-services/suggestions/14515326-project-level-build-release-variables. You could vote and add comment below.
As a workaround, you could copy those build variables and their values to a Variable groups. Then add the Variable group to your release definition.
This is a new feature in TFS 2017 Update1.
Have you tried just passing the variable into the task definition like $(MyVariable) (where MyVariable is the custom variable name)?
There's too much routine with building next project version using ant. The routine is in several properties files that must be edited before running ant task. I took a look at Jenkins as a system to make builds (including night ones) but I have a problem with changing properties.
Is it possible (if yes, how can I do it) to type parameters in Jenkins configuration before build in order they will be passed to ant?
What I really mean is the following schema (I used in manual builds):
there're 2 properties files that contain data about build version, src destination, emails to notify about new build and so on.
corresponding properties' keys are used in Ant tasks and these properties are changed manually before build.
some properties are read by Java util and used for their own part during build.
there're also 3 or 4 ant XMLs that a imported in build.xml, and these xmls also read properties from mentioned files.
What I want to do is:
change key properties in Jenkins
press build project
my data will overwrite data in properties files OR will be passed as ant vars values straight to the ant's task(s).
as a result I receive new build with corresponding notifications (they're made through ant)
Are there mechanisms that allow one to make such schema work via Jenkins?
Thank you in advance.
In Jenkins, you can use the parameterised build feature to specify those parameters you need to substitute into your build.
For example, if specify a parameter called server and, when clicking "Build Now", you enter test, the build will be executed with an environment variable you can access called ${server}.
Then, in your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field. Here you can enter my.ant.property=${server}.
That's equivalent to calling ant -Dmy.ant.property=${server}, and will be expanded to ant -Dmy.ant.property=test.
Another option : Set environment variables for the scope of the build using this Env plugin. So if the properties you are using are environment variables or can be set as them then you want to use this one. Though it might involve some effort in changing the build scripts, but it can be a good option :
Q : Why would I use this one as I already have parametrized build plugin
A : Because the parametrized build plugin requires human interaction if there is more than 1 choice. For example building for Release 1 or Release 2 or Test branch.
While in the Env plugin, you can set the property once for each choice and then create a respective job for each. Then just schedule the job(s) thereby eliminating the human factor.
We are using TFS Build 2010 for Builds. We have two branches of source code (Lets say branchA and branchB).
Now as a part of the build definition we set the projects to build:
Now to employ the same build definition from branchB will mean that I create another build definition file with same content, with only the items to build set to "$/branchB"
Is there anyway to make this configurable, without having to edit the build definition?
Also there are other input variables that we set for the build definition, and the values for these variables are included in the build definition XAML file. So to change the value of a variable will mean that we have to edit the build definition XAML file. This is not desirable.
I would like to be able to set the "Items to Build" and the variables of the build definition without having to modify the build definition XAML file.
Are there any solutions to these problems?
You can modify the Build Process Template so it only asks you for the Items to Build. The rest of the arguments are prefilled. To get an idea how this works, see http://www.ewaldhofman.nl/?tag=/build+2010+customization
You can add parameters to your build definition. I did this a while back because we had two web projects in a solution that had to be deployed to different servers (via Windows shares). I added parameters to the build def so that in the build properties I could customize them depending on if it was a dev deployment, staging, etc.
I added a blog post on how to do it. You can use the parameters this way so that they aren't kept in the XAML file.
Deploying Web Apps with a customized Build Process in TFS