Is it possible to use dropdown menus for variables in vNext build definitions? And how can this be done?(TFS 2017)
Theses variables shall also be available at queue time. By default, all variables are of type string and cannot be changed (screenshot).
The usage is for example to select the build environment (win7/win10...)
This was possible with the old build system (XAML)(screenshot)
Unfortunately, there is no such setting in TFS to have a dropdown in variables of vNext build definitions, you can only change the value manually (For example, type true instead of false for system.debug variable).
I've submitted a user voice for your requirement at website below, you can vote it there:
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/32979130-use-dropdowns-in-variables-of-vnext-build-definiti
Related
According to the Microsoft docs, I should see an option to link to a variable group under the Variables tab in my build definition, but I don't see it.
I have a variable group defined, but Link Variable Group option does not show up. I'm using Microsoft Visual Studio Team Foundation Server Version 15.112.26301.0.
Your screenshot is referencing "Build" variables, however the documentation you reference is "Release" variables. These are two completely different setups in VSTS.
However, the ability to link variable groups in is worked into both Builds and Releases now from within VSTS. The screenshot below is from one of my build definitions while I am editing it.
You will have to use the new build definition editor to link variable groups.
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.
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)?
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