I want to understand the process how the build definition unshelve selected shelveset and build the code in TFS2013.
It will check whether the shelveset source code is mapped by build in the workspace, if so it will unshelve them. i want to know how internally build will evaluate the complete process.
Each build process template has a parameter called SupportedReasons. This enum is normally set to all, but you can also unselect the option ValidateShelveset to disable a shelveset build option, as shown in the picture below :
During the build pipeline, TFS build service account will running tf command to unshelve in the "Get Version" property in the advanced section of the "Parameters" tab on the "Queue Build" dialog.
It's using tf unshelve Command which will restores shelved file revisions to the workspace on build agent.
Then TFS will build source files the same as others. You could either check the build log to get more detail info, or open your build process template and click each activity to understand how the build pipeline works.
Related
I have three builds.
Build A
Build B (cloned from A)
Build C (cloned from B)
Build A builds our entire environment, Builds B and C were cloned, but then stripped to only build specific parts and from different branches. Since doing this, we've seen the build time on Build A triple. It is running tf vc workspace /delete on every build.
Build C also deletes it's workspace, but build B does NOT. On the repository tab, all three have Clean set to false.
Is there anywhere to view/set options for the Get Sources task? What would cause one build not to do this and the other two to do it?
There are only three TFVC options in get source step of TFS build pipeline.
No any other extra option to control the get source task.
First suggest you check whether you set Clean = true in Visual Studio Build task, you need to uncheck it here.
If you do not check Clean option and the build always refreshed workspace on local build server and build agent always cleans TFVC Repository. Try this solution: completely wipe the agent directory and start again, this may fix the problem. Another way is reconfigure your build agent and trigger the build again.
Besides, you could also disable the default get source steps in the build definition. And use your own script to do the get source/pull files to bypass workspace mapping issue. How to, please follow: Is it able to ignore/disable the first step Get source in vNext Build?
I found my answer. By adding the System.debug = true I was able to get a view of the actual mappings in the workspace. Then I matched that up against a list of all the mappings in the repository of the build. What I found was that when we map a folder and one of its sub-folders as well, only the parent folder mapping is created in the workspace definition.
When Get Sources runs, it looks for a workspace name that matches and then first does a simple count check. When the number of mappings in the repository doesn't match the number of mappings in the workspace it fails out and immediately deletes and rebuilds the workspace.
By removing the sub-folder mappings, my Get Sources task dropped from 11+ minutes to seconds.
how i can check in assembly info in tfs?
i am using tfs CI and i have one work space, when i try to check in pending :
2017-09-10T17:37:40.3410618Z No files checked in.
2017-09-10T17:37:40.8732772Z There are no pending changes matching the
specified items.
changes, tfs log show no pending change, but my dll version is right.
i can see assemblyinfo files in visual studio pending changes.
i am using assemblyinfo plugin in CI and i am check in with powershell command:
Tf.exe checkin $/[path]/assemblyinfo.cs
When you build in VS locally, the file assemblyinfo.cs generated within the workspace (the project in source control mapped) and will be detected automatically in Pending Changes page.
But according to your description, you build with TFS, that means the file assemblyinfo.cs is not in source control yet. Unless you publish/add the output to the active workspace just like build locally with VS, then you can check in directly. Otherwise you have to add the file to source control first, then check in.
So, just try to run "tf status" command first, it will show you list of pending changes.
tf stat /collection:http://server:8080/tfs/Collection
If that file not been listed, just run tf add first, then tf checkin (You need to change directory to your mapped folder first)
I need to check-in some files generated during a TFS 2017 vNext build.
In my old XAML build I could easily do that using the tf checkin command since the files reside in the build workspace.
In the new vNext build, The workspace owner is Project Build Service or Project Collection Build Service, even when I configure the agent to run under a different account.
Any way to perform the check-in on the build workspace? Or somehow configure who owns that workspace?
There are Add and Check in changes tasks in TFVC Build Tasks extension.
Regarding no pending changes, you need to add the files to the list of pending changes for the workspace by calling TF add command.
It's not a recommend way to check-in/ modify source code during a build pipeline. If you really want to do this, you could edit the build worspace files and use tf commands in custom/powershell task eq:
cd $env:BUILD_SOURCESDIRECTORY
$TFFile = Get-Item "C:\Program Files (x86)\Microsoft Visual Studio 1x.0\Common7\IDE\TF.exe"
$tfOutput = [string]( & $TFFile.FullName checkin /noprompt /override:"***NO_CI*** New version is $newVersion." /comment:"***NO_CI*** New version is $newVersion." 2>&1)
Another way is installing TFS Power Tool and use the Windows PowerShell Cmdlets to check in the files. Refer to this link for more details: PowerShell and TFS: The Basics and Beyond
I have created a Jenkins Job which gets code from TFS and builds the EAR at jenkins default workspace (/opt/jenkins/lib/jobs/PROJECTNAME/workspace/dist).
After the EAR is built, I need to checkin this EAR to TFS, but I didn't see any option to checkin artifacts to TFS.
If you are using TFS Plugin in Jenkins to get the code from TFS. It will create a workspace when get the code. Settings as following:
And then, you can add an "Execute Windows batch command" build step to check in files to TFS after EAR build via TF Command.
Now you'll get the files been checked in:
In the command, I check in the folder generated by the build, you can also just add the items generated by the build.
might be helpful.
Visit how to add an existing solution to tfs
Another add solution to TFS server
Using teamcity with TFS, is it possible to run shelveset without unshelving it first to my workspace? I found way to only run it from pending changes (therefore unshelved), but it seems weird this is not possible.
Using Visual Studio 2008 and teamcity adding 8.1.
That feature is not currently built into TeamCity's TFS VCS plug-in.
As a work-around, you can do this using a custom build configuration parameter and a custom build step that automatically unshelves the shelveset before the build.
I created a feature request here: https://youtrack.jetbrains.com/issue/TW-43793
Manual work-around:
Create a new build parameter:
Name: ShelvesetName
Kind: Configuration parameter
Spec: text description='The shelveset to unshelve in the format |[shelvesetname|[;username|]|]' label='Shelveset Name' validationMode='any' display='normal'
Create a new build step:
Runner Type: Command Line
Step name: Unshelve shelveset
Execute step: If all previous steps finished successfully
Run: Custom script
Custom script:
if "%ShelvesetName%"=="" exit /b 0
"%VS2013_Path%\tf.exe" unshelve "%ShelvesetName%" "%vcsroot.vcsroot-name.tfs-root%" /recursive /noprompt /login:domain\username,password
You may have to change VS2013_Path with the appropriate variable/parameter from the agent and the version of Visual Studio you're using.
You'll have to change vcsroot-name with the name of your vcs root, and remove the /login parameter or specify your own credentials.
The VCS root checkout mode must be set to Automatically on agent (if supported by VCS roots) for TeamCity to create a TFS workspace so this can work correctly.
Then finally, when you run a custom build, set the Shelveset Name field on the Parameters tab to the name of the shelveset, including the owner, like shelveset1;domain\username.