When creating a new build definition in TFS 2010 we specifiy a project or solution to build (Under the 'Required -> Items to Build' section in the 'Process' section of the definition.
Is there any way to get hold of the name of the solution being built in the Workflow scope? I.e. is the there a variable available with this information inside that I can pass into a custom code activity elsewhere within the work flow?
If you open the build workflow and tunnel down into Compile and Test, you'll see a For Each Project loop scope that shows the workflow variable assignment of BuildSettings.ProjectsToBuild as serverBuildProjectItem in an out of the box workflow. There's a task within the sub-sequence that translates that serverItem to a local path containing the proj file.
Related
I am attempting to set up a DevOps build definition to build a VS2017 solution on an on-site agent.
After adding the standard Visual Studio Build step to the build pipeline, the build agent reports the error:
"Error MSB3030: Could not copy the file "d:\agent_work..."
This seems to be happening for any LINKED item.
These items were added to the project from other solutions ("add existing item->Add As Link")
The solution/project builds fine locally on developers PCs, but not on agent.
All that is really required is for the build step to copy these files to an output directory to be included in the build artifacts.
Properties for all linked items are set to "content & copy always".
Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found.
Am I missing something basic here?
This is a workspace mapping issue. You have files that aren't part of your build workspace. You will need to update your build to have a workspace that is mapped in a fashion equivalent to your developers' workspaces.
If your developers are referencing files outside their workspaces, this is a problem that you will have to rectify, then update the build accordingly.
Solved the build error : "Error MSB3030: Could not copy the file "d:\agent_work..." because it was not found." by adjusting the mappings in preceding "get sources" step. After looking at the logs of the build it appeared that the agent was looking in "d:\agent" for some items and "d:\agent\s" for other items (and not finding them). Don't know why it was looking in the "s" sub-directoy. But anyway, the work-around was to include the "s" in the local path mappings for "Local path under $(build.sourcesDirectory)" (ie: s/MyLocalPath)
In a custom vsts build task I want to know the path to the current build pipeline so that I can reuse the path to automatically calculate the path to the build drop folder.
In the vsts build portal where I create build pipelines they can be organized into folders. It's this folder path that I need to use in the build task. I can get hold of the name of the build pipeline from variables here: https://learn.microsoft.com/en-us/vsts/pipelines/build/variables?view=vsts&tabs=batch
But, there's no variable for the folder name. How can I get the folder name?
The folder that the build definition lives under is purely a build definition thing -- it has no bearing on a running build, so it's not populated as a build-time variable.
You can retrieve the build definition by making a REST API call:
GET https://{accountName}.visualstudio.com/{project}/_apis/build/definitions/{definitionId}?api-version=4.1. The account URI and build definition ID are available in a running build, and you can easily allow your script access to an OAuth token (populated in the SYSTEM_ACCESSTOKEN environment variable) for authentication purposes.
This will return a JSON object, which contains a path property. That's the path to your build definition.
You must be using an agent for your build pipeline. The agent may be hosted on VSTS or it may be on your premises.
Now, all the tasks in build definitions are executed on agent. Agent is simply a machine. Normally it uses below folders during build process.
Build.Repository.LocalPath or Build.SourcesDirectory or
System.DefaultWorkingDirectory = c:\agent_work\1\s : The local path
on the agent where your source code files are downloaded
Build.ArtifactStagingDirectory or Build.StagingDirectory =
c:\agent_work\1\a: The local path on the agent where any artifacts
are copied to before being pushed to their destination.
So answer your question:
c:\agent_work\1\s here source code is downloaded.
c:\agent_work\1\a here you can copy anything. Build definition uses this path to generate build artifacts at the end of build.
I am configuring VSTS build and release process.
I have a scenario where I have DEV and QA environments. I have different config files for each of the environments, think of the naming convention Test.Dev.Config
Test.QA.Config
In the "Copy files to" step of the build process, in the "contents" field, are you able to use the BuildConfiguration variable in order to tell the build process to copy the configuration files relevant to the BuildConfiguration:
so that the output of the package contains the Test.DEV.config files for the Dev build step and the Test.QA.config file for the QA build step.
I am basically testing out a options for config transforms in VSTS
Using a VSO variable combined with a string literal often doesn't work as expected within a task like File Copy. Also, you don't want to do that in every task that requires build configuration specific config file. What you can do instead, is to have a separate variable in your build definition that derives from BuildConfiguration variable like so:
Variable Value
BuildConfigFile *.$(BuildConfiguration).config
And then, within the File Copy task, you can directly use this variable as:
_PublishedWebsites\App_Config\$(BuildConfigFile)
For more details on defining one variable in terms of the other, refer this SO post.
I have a Service Fabric project set up with CD in VSTS. The CD process have been set up from the CD wizard in visual studio. So far so good but when the release is made I'm not getting any value from the pre-defined variable called Build.DefinitionName that I use for naming the releases.
This is how my Release name is configured: $(Build.DefinitionName)-$(date:yyyyMM).$(rev:r)
If we look in the release log there is no value for the variables:
[BUILD_DEFINITIONNAME] --> []
[RELEASE_ARTIFACTS_{Primary artifact alias}*_DEFINITIONNAME] --> []
*This value is populated correctly.
And according to the docs of primary artifact variables the two variables above should be the same.
As a result of this my releases are named $(Build.DefinitionName)-201702.7
If I use Build.BuildNumber instead. I get the correct value.
How can I get the variables populated?
Update
When creating the Build and Release definitions manually the $(Build.DefinitionName) gets populated correctly on the Release side. But the problem seems to appear when you use the CD wizard from Visual Studio. I might be missing something but the settings of the Build Definition are identical. Or there is some funky stuff going on with the CD wizard.
The solution is to create the release definition manually on web access and set Continuous Deployment.
On the build number is passed from Build to a release, there is no out of the box way to pass more variables between build and release.
However I write a ser of build tasks to do this: https://marketplace.visualstudio.com/items?itemName=nkdagility.variablehydration
It consists of two tasks, the first saves the specified variables to a json file, which you should put in the build output.
The second restores the variables you want. Especially useful if you have multiple source build for your release.
I am trying understand how to really use PowerShell in TFS. I would like to add a release step to create a work item task, to tell our release management team they require to approve a release.
Our company has many team projects and I want this to be available as a module that can be used by any project. The process I am using to use this is I am adding an artifact for the TFS project that we store our generic item.
It is under $\BuildSupport, for this example, I create a build for my project under $\WEB. I am also creating the release Under $\Web as well. I create my new release definition, I add my Build artifact.
I then add a Team foundation Version Control Artifact to $\BuildSupport Source alias is "BuildSupport".
I then add a environment step called TEST PRODUCTION and add PowerShell task where the script path is: $(System.DefaultWorkingDirectory)/BuildSupport/Main/BuildTools/TFSBuildScripts/CreateWorkItem.ps1
My issue is that when creating a new release it asks every time for me to choose the artifact version based the changeset for BuildSupport.
I don't want to have everyone do this every time is there a better way?
There isn’t the way to queue a new release without specify the version of TFVC artifacts. I submit a user voice here: Default version of artifacts when queue new release.
The workaround is that:
You can create a task group for each team projects, then add this task group to related release definitions. (you need to update the task group if there are updates)
Create or open a release definition
Add PowerShell task and configure it (e.g. Type: Inline Script, Arguments: [necessary arguments], Inline Script: [powershell script] etc…). You also can specify the PowerShell file in the Shared folder (Map BuildSupport to shared folder, then current version is the "default" version when queue release)
Right click this task > Create Task Group
After that you can add this Task Group to other release definitions directly.
Another way is that you can create a build/release task extension, then install it for necessary team project, after that you can add that custom build/release task to build/release definition. For this way, you just need to update the extension if there is the update.