TFS - Triggering two builds with CI - tfs

Currently, I have three solutions that have corresponding builds and they produce three artifacts:
CommonSolution -> BuildA -> Common.dll (output drops into a nuget feed)
ProgramSolution -> BuildB -> Program.exe
ServiceSolution -> BuildC -> Service.svc
Program.exe and Service.svc both consume the Common.dll via a nuget feed and it should be the exact same version.
Currently all the builds are isolated and so the CommonSolution is built. Then the Common nuget is updated manually in the Program/Service, and then they are built.
In TFS, is there any way such that if BuildB is trigged, it automatically triggers BuildA first, then the Common nuget is updated and consumed in BuildB and BuildC, and the two builds are triggered?
Or are there any other setups that would be more suitable?

When you edit your build configuration, go to the Triggers tab and enable Continuous Integration. There you can define path filters and specify the path to your solution folder, so the build will only be triggered when changes are checked in to that distinct path.
In your case, only the CommonSolution changed, the dll will be updated. Then just need to chain build B and build C.
For the latest version of TFS- Azure DevOps Server 2019, we do have a build-in feature: Build completion triggers
Large products have several components that are dependent on each
other. These components are often independently built. When an
upstream component (a library, for example) changes, the downstream
dependencies have to be rebuilt and revalidated.
In situations like
these, add a build completion trigger to run your build upon the
successful completion of the triggering build. You can select any
other build in the same project.
For TFS version 2018 and previous, there are two ways to run another build in your current build.
Option 1: add PowerShell task in your current build definition to queue another build by REST API
Assume another build id is 5, so you can add PowerShell task with the script:
$body = #{
definition = #{
id = 5
}
}
$Uri = "http://account.visualstudio.com/DefaultCollection/project/_apis/build/builds?api-version=2.0"
$buildresponse = Invoke-RestMethod -Method Post -UseDefaultCredentials -ContentType application/json -Uri $Uri -Body (ConvertTo-Json $body)
Option 2: install related extension in Market place
There are some extensions you can install for your on-premise TFS server, then you can add the task to queue another build. such as Queue Build(s) Task, Trigger New Build, Queue New Build etc.
is there any way such that if BuildB is trigged, it automatically triggers BuildA first So,you could add a step to trigger Build A during the process when running Build B.

Related

Moving TFS CI Build def to VSTS - VSTS CI build def gets everything and builds everything

We are starting to migrate our old xaml build def's to VSTS web-based build def's. For each branch, we have a debug build def and a release build def. The debug build def is set up as a Continuous Integration build. As a test, I modified one source file and checked it in. The old xaml build def checked out the 1 file and seemed to have built only the project that changed (what we want and expect in a CI build). In the xaml build log I see the following:
<InformationField Name="Message" Value="1 file(s) were downloaded with a total size of 0.29 MB." />
and it ran the build in 3.3 minutes.
In the new VSTS build - I see that it does a "tf get /version:170936" and gets all the files in changeset id "170936":
2018-06-12T15:08:39.8409262Z Checking if artifacts directory exists: C:\BuildAgent\agent2\_work\1\a
2018-06-12T15:08:39.8409262Z Deleting artifacts directory.
2018-06-12T15:08:39.8409262Z Creating artifacts directory.
2018-06-12T15:08:39.8564882Z Checking if test results directory exists: C:\BuildAgent\agent2\_work\1\TestResults
2018-06-12T15:08:39.8564882Z Deleting test results directory.
2018-06-12T15:08:39.8564882Z Creating test results directory.
2018-06-12T15:08:39.8877401Z Starting: Get sources
2018-06-12T15:08:39.9033640Z Entering TfvcSourceProvider.PrepareRepositoryAsync
2018-06-12T15:08:39.9033640Z localPath=C:\BuildAgent\agent2\_work\1\s
2018-06-12T15:08:39.9033640Z clean=False
2018-06-12T15:08:39.9033640Z sourceVersion=170936
2018-06-12T15:08:39.9033640Z mappingJson={"mappings":[{"serverPath":"$/Path/To/Branch","mappingType":"map","localPath":"\\"}]}
2018-06-12T15:08:39.9033640Z Syncing repository: Project Name (TFVC)
2018-06-12T15:08:39.9033640Z workspaceName=ws_1_45
2018-06-12T15:09:06.7318304Z Workspace Name: ws_1_45;a6060273-b85e-4d4b-ac63-3fbbcafc308b
2018-06-12T15:09:06.7630780Z tf get /version:170936
2018-06-12T15:09:21.6070136Z Getting C:\BuildAgent\agent2\_work\1\s;C124440
2018-06-12T15:09:21.6070136Z Getting C:\BuildAgent\agent2\_work\1\s;C124440
2018-06-12T15:09:21.6226405Z Getting C:\BuildAgent\agent2\_work\1\s\.nuget;C158533
2018-06-12T15:09:21.6226405Z Getting C:\BuildAgent\agent2\_work\1\s\Build Scripts;C141602
2018-06-12T15:09:21.6226405Z Getting C:\BuildAgent\agent2\_work\1\s\Databases;C124440
~
~ The rest of branch...
~
and then seems to rebuild all projects taking 13.2 min to run, almost 10 minutes longer than old xaml build.
Am I missing something with the new build def? I do not have the "Clean" button checked in the VS Build task. I do have a build.clean variable but it is Blank by default - sometimes we want to clean so we just can set it to "all" at queue time.
Clicking about on the web shows the following MS VSTFS version: 15.105.25910.0
Any help is much appreciated.
For multiple build agents, even though you have not checked Clean checkbox of the VS Build task, and the clean option in the Repository is set to "false".
Since the agent is randomly picked, it may not contain your source code before. That's why you see that TFS does a tf get /version:170936 and gets all the files in changeset id "170936" and also build all projects.
For Multi-configuration in Options tab of build definition. Please refer the official Article: How do I build multiple configurations for multiple platforms?
After that, it will split configurations to multiple builds during the build.
And ow that your build definition successfully builds multiple configurations, you can go ahead and enable parallel builds to reduce the duration/feedback time of your build. You specify this as additional option on the Options page:
Take a look at this post Building multiple configurations and/or platforms in Build 2015
To narrow down if the issue is related to multiple build agents, you could also send TFS build to a specific agent by demand, and queue the build multiple times with clean=false in the same build agent, it should have built only the project that changed(CI).

How to make a build definition which runs another build definition as one step in VSTS

So I have 1 default publish build definition and I would like to have another one which is in sync with it and does all the same steps but with an additional step at the end.
Can I have another build definition as one of the steps within another build definition?
This question is for Visual Studio Team Services latest.
There are two ways to run another build in your current build.
Option 1: add PowerShell task in your current build definition to queue another build by REST API
Assume another build id is 5, so you can add PowerShell task with the script:
$body = #{
definition = #{
id = 5
}
}
$Uri = "http://account.visualstudio.com/DefaultCollection/project/_apis/build/builds?api-version=2.0"
$buildresponse = Invoke-RestMethod -Method Post -UseDefaultCredentials -ContentType application/json -Uri $Uri -Body (ConvertTo-Json $body)
Option 2: install related extension in Market place
There are some extensions you can install for your VSTS account, then you can add the task to queue another build. such as Queue Build(s) Task, Trigger New Build, Queue New Build etc.
It appears this is now enabled without an extension through the UI: https://github.com/MicrosoftDocs/vsts-docs/issues/561

How to delete a build from Jenkins job workspace

I wonder if it is possible to remove only one build (including artifacts) from job workspace.
I tried to "Delete Build" in Build History but all it does is remove build reference from Build History table. I know I can ssh to a server and delete files from the command line but I am looking for a way to do it from Jenkins web interface.
After installing Workspace Cleanup Plugin I am able to wipe out current workspace but I want to keep my other builds in the workspace.
In your Jenkins instance, to be able to have folder/per build - set flag "Use custom workspace" in your job's settings. Here is a brief help info from the setting description:
For each job on Jenkins, Jenkins allocates a unique "workspace directory."
This is the directory where the code is checked out and builds happen.
Normally you should let Jenkins allocate and clean up workspace directories,
but in several situations this is problematic, and in such case, this option
lets you specify the workspace location manually.
One such situation is where paths are hard-coded and the code needs to be
built on a specific location. While there's no doubt that such a build is
not ideal, this option allows you to get going in such a situation.
...
And your custom directory path would look like this:
workspace\$JOB_NAME\$BUILD_NUMBER ~> workspace\my-job-name\123
where $JOB_NAME will be "my-job-name" and $BUILD_NUMBER is the build number, eq. "123".
There is one nasty problem with this approach and this is why I wouldn't recommend to use it - Jenkins will not be able to reclaim disk space for outdated builds. You would have to handle cleanup of outdated builds manually and it is a lot of hassle.
Alternative approach, that gives you more control, tools and is able to keep disk space usage under control (without your supervision) is to use default workspace settings and archive your build output (files, original source code, libraries and etc.) as a post-build action. Very-very handy and gives you access to a whole bunch of great tools like, Copy Artifact Plugin or ArtifactDeployer Plugin in other jobs.
Hope that info helps you make a decision that fits your needs best.
I also use "General/Advanced/Use custom workspace" (as in #pabloduo's answer) on a Windows machine with something like:
C:\${JOB_NAME}\${BUILD_NUMBER}
Just wanted to add a solution for getting rid of the build job's workspaces.
I use Groovy Events Listener Plugin for this.
Using the plug-in's standard configuration I just use the following Groovy script:
if (event == Event.JOB_DELETED){
new File(env.WORKSPACE).deleteDir()
}
And now the custom workspace is deleted when the build job is deleted.
Just be aware that this would also delete non-custom workspaces (because the event is triggered for all jobs on your Jenkins server).

autodeployment of tfs build

I have a software that up to now was run with UI or command scripts. My job was removing all UI and make it run automatically using tfs builds.
Using TFS 2012 VS 2012
My questions:
1. How to run software that it is being build. I tried with MSBuild Arguments using
/p:DeployOnBuild=True /p:DeployTarget=Package /p:CreatePackageOnPublish=True
/p:OutputPath=bin /p:VisualStudioVersion=11.0 /p:MSDeployPublishMethod=InProc
/p:MsDeployServiceUrl=localhost
/p:DeployIisAppPath=#"\\filer01\FDrive\public\documents\new\\"
No errors, but my testing solution doesn't produce anything. For testing it should create a file. Same code works fine from within custom code activity so it means the software doesn't run. I want to run software from source control.
Question 2. What is the best way to pass arguments from TFS Build Definition to software I am Building and Running? Can I call them from withing software?
Edit:
Solution:
custom activity:
var process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = String.Format("{0}\\TestingForm.exe", binaries)
}
};
process.Start();
process.WaitForExit();
I've never tried the DeployIisAppPath argument but we routinely used TFS build definitions in the past to deploy our code to a remote IIS server. Works great. Maybe you can try dropping the DeployIisAppPath and deploying to local IIS instead?
The MSBuild arguments can be accessed during the build step. You can instruct MSBuild in your wpp.targets file to take those values and use them to alter the application files but it all depends how you want to use them.

Jenkins: How To Build multiple projects from a TFS repository?

I have set my workspace directory to C:\jenkins_builds\workspace and I want to build ProjA and ProjB, each having a local workfolder (same as project name).
When fetching the source code from my repository, the first two things the TFS plugin does are:
tf workspace -new %workspace-name-A%;%user-name% -server:%my-server%
tf workfold -map $%branch% ProjA -workspace:%workspace-name-A% -server:%my-server%
Which goes fine when building ProjA. The problem is, the first command maps the root directory from the repository directly to my C:\jenkins_builds\workspace directory. The second command does what I actually want, i.e. mapping %branch% to the ProjA subfolder. Later on, when building ProjB, the first command fails (and consequently the build) with the following error message:
The path C:\jenkins_builds\workspace is already mapped in workspace %workspace-name-A%;%user-name%.
OK, it seems like a bad idea to map the root directory to the work directory. But why does this automatically happen when the TFS plugin runs the workspace new line? Currently I have to clean things up between building ProjA and ProjB by running the -unmap command.
My team is using Team Foundation 3.0.
We have the same situation and there are 2 ways to solve this:
use different workspace-root-directories for the two builds
This results in the need for two checkouts => double the space and slower, but better isolation between the two builds
"hardcode" the workspace name to the same for both builds
By default jenkins creates a workspace containing the build name, which can be changed in the "advanced" section of the TFS config, and then you can use the same workspace-/workfolder-mapping for several builds - in our case we called them ProjectName_${NODE_NAME} so it even works on several nodes

Resources