In TFS 2010/2015, the Xaml builds can be configured to only ever keep the last x builds (e.g. keep the last 5 builds).
However, the new style builds in 2015 change how this works, to keep builds for x number of days, and keep a minimum of y.
This might work well when dealing with small projects, but the output of our build is >5GB a time.
Is there a way to use the old retention policy, or alternatively have TFS manually delete the old builds as new ones are created?
XAML and vNext are totally two different build system. You definitely couldn't use the old retention policy on XAML build for vNext.
And there is also not any option to make TFS delete the old builds as new ones are created. Retention policies is the only way used to configure how long builds and releases are to be retained by the system for now.
As a workaround, you could use TFS API to do this. You could run a utility to clean the build artifact drop location for builds. Here is a sample from skundu's answer in this question: TFS 2015 - Delete Build Artifacts for your reference.
Related
I'm housekeeping the TFS Server and have 40,000 shelvesets of which 6,500 are for the Build Service Accounts.
I assume i can simple remove these as i don't think the builds will refer to old shelvesets.
I exported all current shelvesets.
Can someone confirm if we can just delete all of these? Or will we run into trouble if we want to run an old build
We are running TFS 2017.2
I don’t see any reason to keep them. Since commits should be occurring therefore giving you code history and reproducible builds.
If you delete a shelve set you cannot retrieve it latter for any old builds.
Shelve sets are not the same as code commits
Reference the MSDN documentation which applies to TFS 2017 and shelve sets for use cases.
the purpose is not to be a version history of code changes or
associate code with builds.Thats what commits are used for.
Shelve sets are temporary. However, no rule stopping you from keeping forever. Unlikely any value would be gained from so many
though.
there is not a need to reproduce a build with a shelf set that is older then your code release cycle because commits our occurring making the shelve sets moot.
#NOTE: I do not know why you would have the build agent doing code shelve sets. I would look at your build definition and take out anything automatically creating shelve sets.
Its always advised to find the details of shelveset unless you know its old enough to delete. You must be a shelveset owner, or your Administer shelved changes permission must be set to Allow as explained here. Shelveset commands to delete/find/list/... are listed here
TFS Sidekicks tool provides a dedicated UI for a number of clean-up actions, including old shelvesets till TFS2015. Not sure about its working in 2017
I'm trying to understand the process for vNext Builds and Release Management as far as identifying what work items are included.
If I have a build set up on every check-in (each time a work is completed), then each of those Builds will have one work item linked. I can then trigger a Release deployment of those Builds to a QA environment, but then each Release only identifies that one item as being linked - not any others that have been included since our last production release. Since there could be multiple Release Deploys to QA prior to a Deploy to Production, it's confusing trying to filter through all the Releases.
I'm trying to find a good way to see all work items included in Builds/Releases since the last production deployment. Am I misunderstanding how to use this? Should I be using the same Release and just changing the targeted Build each time? It seems like it bases "included work items" off the checked in work-items in between the last build and the current one.
In Release Management, It compares current release with the last release to show the work items included in current release. You only see one work item is because that you have configured TFS to build every check-in and trigger the release for every build. If you trigger a release after two builds, you will see two work items included in the two builds. The latest version of Visual Studio Team Service has support selecting a release version to compare with current version to list the included changes and work items, but this hasn't been implemented into On-premise TFS yet.
So for now, you can create another release definition and link it to the same build to deploy the build to production manually. Then you can track the included work items from this release definition. Or you can create an app/powershell script to read the build version in the production release and then get the included the work items via Rest API.
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
Currently we have many projects in TFS, one of which is a core project that many other projects reference. If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order). It would be nice to be able to set the core project as the highest priority so that its build always runs first when changes to multiple projects are checked in. Is this possible?
There is no way to set the default build priority for a Build Definition. Since a Build Definition isn't bound to a Team project, but to a collection, there is also no way to configure the Queue to pick up builds from one Team Project before any others.
What you can do is to set a tag on an agent and then assign that tag to the build you want to take precedence. This will exclusively reserve the Build Agent to that specific build definition, causing it to jump in the queue.
Is there a way in TFS 2012 to set Project (not .csproj projects but TFS projects) build priority?
A project in TFS is quite a loose term which does not correspond to a VS project, it's actually used to refer to a product which can contain many branches. The high level project management tools then operate on the TFS "project".
If someone checks in changes to both core and another project at once, the core project build doesn't always kick off first (I think they build in alphabetical order).
Nope, assuming you don't have a custom build then they (the VS projects) don't build in alphabetic order at all, they build in order of dependency. Solutions are built in the order they are returned from the evaluation of the $(SolutionsToBuild) property (this does a wildcard search of the filesystem for .sln files, so maybe that's where your alphabetic observation comes from). Note that dependencies are evaluated on projects within a solution, there is no evaluation of dependencies across solutions.
For the following statements I'm going to assume that you have standard CI style builds gated upon checkin.
If a developer checks in everything at once then the checkin will happen as an atomic unit of work and the build will commence once the checkin is successfully committed. If this is not your experience then I would suggest that you either have funky stuff happening in a custom build, or the developer is checking blocks of work in separately rather than all at once.
Note that this happens per checkin per workspace - if two different developers check stuff in at the same time then whoever checks-in first will trigger the build, and the submission of the second developer will miss the build.
Currently we are using StarTeam to perform the build as well as versioning. we planned to migrate startteam to TFS2010. We have some script for perform the build. i wanted to change this script according to my requirement. i gone through the TFS but i had lot more confusion.
in StarTeam, we will get a files from "Ready to Build" label and perform the build. In TFS, how we are going to get a files from TFS? What concept should i use to get a files and perform the build? i have gone through the lot of commands like get, check-in, checkout etc..
If we use "tf get" command, we can get all the files from TFS but i have a clarification on that. shall i get all the files from TFS for every build? i hope, this is unnecessary headache.. correct me if i am wrong..
how we perform the build in TFS? i have read some types of build such as manual, gatedcheckin, Continuous Integration and schedule.
Is there any relationship between branch and build activities?
In TFS, What is the meaning of Workspace?
As said, many questions in one. Hope this helps along the way:
A workspace is a mapping between the server and a local storage,
similar to checkout in Subversion, view in ClearCase, etc.
"TF get" normally only fetches those files that have changed since
last update. You can force it to fetch everything - and sometimes
have to - but its not normally done.
Team Build is the recommended system to build with when using TFS. It can take some time to get into (Windows Workflow-based), but is quite powerful. There are default process definitions that set up the most common actions for you.
By default, you can't control whether to build by setting a certain label, but you can define that only this label should be used when builds are triggered. Labels in TFS work a little differently compared to other VCS, though, so maybe there's an 'opportunity' to re-think your build process along the way. If you're set on using a label as before, you'll need to build a Custom build activity.