I'm using new tfs 2015 build agent (not XAML one). In XAML it was possible to change working path from $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath) to any.
Is it possible to change path in new agent to disable or lock $(BuldAgentID) ?
To disable generation of random digits like:
c:\Agent\work\1
c:\Agent\work\2
c:\Agent\work\3
etc.
Use the build variables to change the same,
The working directory for this agent. By default $(Agent.RootDirectory)_work.
now you can assign the variable to any location.
Check the Link
Related
My project recently migrated from VSS to TFS, and we are using TFVC for our main CM and documentation repo. In order to simplify things and reduce the system shock, we would like to automatically force a lock of files on check out. Is there a way to do this in a VS 2017 (On-Premises TFS setup)?
I have already tried this, and it doesn't work:
Team->Team Project Collection Settings->Source
Control...->Workspace Settings Tab: Changed default workspace
type from "Local (recommended)" to "Server".
Within Team->Team Project Settings->Source Control...->Check-out Settings Tab: Changed enable multiple check-out to UNchecked.
Lastly, I would like to apply the changes globally...I was hoping this would be a server configuration setting. Is this true, or does every single person on the team have to make local workspace changes?
You can set the default type for new workspaces (Manage project collection workspace settings for your team) but any team member can update the type for own workspace. The option enable multiple check-out is applied to whole repository but using of a local workspace ignores this option (When might I need to use a server workspace?). There is no option to lock the workspace type.
Im using the tf.exe and I need to know the actual Revision ID on my Team foundation server.
I tried tf history, but I simply need the latest revision.
I am using TFS 2010 and Visual Studio 2008.
An Environment Variable would do it for me.
You don't need to use the tf.exe, if you are using vNext build (TFS 2015 and later version), you can directly use the predefined variable Build.SourceVersion to get the latest version value (changeset ID) in current build. See Predefined variables for details.
Then you can set the build number format with the variable Build.SourceVersion:
e.g : $(TeamProject)_$(BuildDefinitionName)_$(Build.SourceVersion)_$(Date:yyyyMMdd)$(Rev:.r)
But note that the variable $(Build.SourceVersion) in build number format is only available when builds were triggered automatically on commit/checkin (on Continuous integration). It can not be resolved when you queue build manually and keep the Source Version field as empty (by default it will get the latest version). So, if you queue build manually, then you need to specify the specific Source Version (e.g C458) in the queue build dialog. See my reply in another thread : Using SourceVersion and rev:r in TFS2015 build names
Another workaround is getting the latest changeset with the variable Build.SourceVersion first and then upgrade the build number automatically within the build process.
TFS 2010 means XAML builds, so you need to use the IBuildDetail.SourceGetVersion property.
The simplest way is to assign a variable just before the UpdateBuildNumber activity; the variable value is computed mixing the build number computed by TFS and the above property.
Does anyone know if the feature to tag agents has dissapeared?
I could not find anything related to over the internet.
My idea is to have certain builds use a specific agent. On TFS 2013 I would use tagging, but i no longer see that option.
On the other hand, I see that it is possible to connect a build definition to a certain agent queue.
There is no more agent tags for TFS 2015 or later version. If you want to use a particular build definition and a specific build Agent which used to run the build.
You could add a user Capability to that specific build agent then in the build definition you put that capability as a demand (General tab).
Another way is directly using Agent.Name or Agent.ComputerName demands in build def or when queuing a build. Take a look at this blog: How to send TFS build to a specific agent or server, which also support on TFS2015.
Oren: Is this feature works in TFS15 SP3?
Reply Eric Parvin: Yes, this should work on TFS 2015 to the newest version.
Use demands and capabilities for this. Add a custom capability to the build agent, and then add a matching demand to the build definition.
Demands and capabilities would work, and you could also create a specific queue, with a single available agent in it, and set the queue to your desired build, so you would achieve the same behavior as desired one.
I'm trying to set up a parameterized build.
One of the build parameters is the branchname, where I want the TFS plugin to get the project from.
Is it possible to pass an build parameter to the "project path" variable of the TFS SCM plugin. (If yes, how? I have tried several ways, but it doesn't seem to work)
This variable:
TFS Project Path
I don't think it's possible to use variable for Project path in Jenkins. The Project Path requires the name of the project as it is registered on the server. There is nowhere to define the variable.
The description of Project path is:
The Team Project and path to retrieve from the server. The project
path must start with $/, and contain any sub path that exists in the
project repository.
Check: https://github.com/jenkinsci/tfs-plugin/blob/master/README.md
You can use a "build-parameter":
and user this parameter in the TFS-settings:
But in my case I want the TFS-plugin check the TFS for code changes every 15 minutes and trigger a build if code changes were detected. Using this configuration the plugin triggers the build every 15 minutes also if there are no code changes.
The default build template for TFS has a format of $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
This translates to something like BuildName_20141111.1 for the first build of the day, BuildName_20141111.2 for the second and so on that.
That's all well and good but what I'd like to do is pull out that .r and insert it into the assembly before it's compiled by the build server.
I've already edited the build template to update the various AssemblyInfo.cs files and such and that's working fine. Right now we are toying with the idea of Major.Minor.yyDDD (Day of year).r but the catch is that very last part - how do we get $(Rev:.r) from within a build template?
I've tried looking through the various environmental variables and I can pull out the entire Build definition string (i.e. BuildName_20141111.1) but really all I want is that .1 (or more specifically "1"). Is there a way to do this programmatically? Is there an environment variable I've missed? Or is there a way that I can actually access things like $(Rev:.r) directly?
I am relatively new to TFS but this is the last hurdle before I can move a lot of projects to it.
You effectively need to parse this off yourself from the BuildName parameter. If you are using TFS 2013 you can do it in PowerShell. Prior versions need a customized build template.
There are prebuilt solutions to this. Best is the TfsVersion activity or the VersionAssemblies.ps1 that is provided as part of the TFS Community Build Tools.