TFS 2017 u2. The task gallery for build/release definitions is crowded by tasks that are utterly irrelevant to our software shop. They're built-in, so removing the extension is not an option.
Any way to hide them?
CAVEAT I discourage you: if you need to reinstall a Task, the process is non-trivial.
This has already been answered at Remove custom installed build task on tfs
The idea is to use tfx build tasks delete. You need the GUID of the task: a quick way to get it is to look at the task.json file in the https://github.com/Microsoft/vsts-tasks repository.
Unfortunately, there is no way to hide the tasks. You could search the tasks you want to use, and I've submitted a UserVoice at website below, you can vote it:
https://visualstudio.uservoice.com/forums/330519-visual-studio-team-services/suggestions/33373423-hide-build-tasks
Related
In tfs when automatic release occurs (each night) my team have to change their backlogitems asociated with this build to an state called 'ready for qa' next day, sometimes we forget it, if the build mark those backlogitems as 'ready for qa' when it's success it would be great. Is there a way to configure the automatic release to do that?
I don't believe there is any native way to do this, but the following extension Update Work Item in the VSTS marketplace should work for you.
After installing the extension, you will need to add a task to your Release Definition and configure it to suit your needs. Be sure to enable the "Allow Scripts to Access OAuth Token" setting in your release.
Note: there are some nuances in configuring this task to be sure to read all of the 'help' icons during initial configuration
Personally, I found using TFS Rest API as a good way of updating Work items. The Work items update TFS API is quite simple and easy to use
https://www.visualstudio.com/en-us/docs/integrate/api/wit/updates
The advantage of using it over build task is that you can run and test it locally and is easier to update and maintain
I'm converting our XAML build process to vNEXT build for our on-premise TFS 2017. One step I like to automate is the create a work item task for a specific user to execute after the release has been done. Is there a built in way to do this? I have a PowerShell script but I'd prefer not to use it if there is already a better way
No, there is still no out-of-the-box feature for this. Either using the REST api or the Client Object model in a powershell script just like you have done will do the trick.
You could also take a look at this similar question: How to have TFS automatically add certain tasks to new work items?, jessehouwing has provided a great answer.
Another way is using TFS Aggregator- a serverside pugin for TFS 2013
(update 2 and later) which has the ability to create new work items
based on rules. An example task can be found here:
https://github.com/tfsaggregator/tfsaggregator/wiki/Auto-Create-Children
Update
After go through the extension in VSTS marketplace (https://marketplace.visualstudio.com/) , there is also no existing task could do this. You may still use your powershell script or write your own extension.
I am used to working with Perforce and I really like the ability to be able to group checked out files under different pending changelists. For example, if I am working on two bugs at the same time and the changes made for them can be grouped separately.
I am unable to find this functionality in TFS. Is this supported? If no, what is the best practice around it?
I am using VS 2015 Professional with TFS Server 2015.
No, it's not supported with pending changelists in TFS for now.
To be a workaround, this is possible using the Suspend/Resume feature in Visual Studio 2012 and above. It will allow you to keep multiple shelvesets, associated to multiple workitems. Only problem is that you can't have all two bugs open at the same time, so you'll have to check them in one by one.
More detail info please refer this link: Suspend your work and manage your shelvesets
is there a way to automaticaly close a User-Story in TFS2010 when I checkin my code
with the last open task ?
I do not want to add the User-Story to the checkin with the code.
TFS can't do this automatically, however tools like http://tfsaggregator.codeplex.com/ can.
As previously suggested, TFS Aggregator can indeed easily do this. Just be sure that you actually want to do this, because you might want a human eye to verify that the story is indeed done.
What I suggest is to use the aggregator not for closing the story, but for moving it to a code complete state (or "ready for UAT", or "deployable", or what-have-you), if your tasks do not, in fact, cover everything needed for "DONE" done.
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.