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
Related
long time listener, first time caller!
I've spent two days searching for an answer to this so hopefully someone here may be able to help.
I've set up a personal/free VSTS instance and created a project.
One of the first tasks I want to do is setup the build pipeline, so create a new pipeline, define the agent pool as VS2017, connect to my Github repo etc, all of which is fine.
Next I try to add an Agent Job, again choosing VS2017 as the agent. With no other options chosen, if I try to save the build definition I get the following error message (and cannot save it);
The AllowScriptsAuthAccess build option is not supported in API versions greater than 4.0.
Allow scripts to access the OAuth token is unchecked on the Agent job configuration under phases and on the Build/Options tab (slider set to disabled)
I've googled and searched for all sorts of stuff to try and find someone with the same problem but it's almost like I'm the first to discover this - which is highly unlikely!! It has almost driven me to using Bing to search for a solution, but let's not get carried away.
Any ideas or suggestions would be greatly appreciated!
So it turns out that turning off the "New YAML pipeline creation experience" and "New Navigation" under preview features fixes the problem, insofar as I can now create and save a build pipeline without the error.
Also, if you have "Build YAML Pipelines" enabled under preview features for the Organisation, you get the "View YAML" link that I was missing also.
Thanks all for your help. I'd be interested to know the root cause of this still. I'll update the Microsoft support ticket with the same and post back here if they have any insights.
There's an similar issue here:https://developercommunity.visualstudio.com/content/problem/123012/getting-multiconfiguration-build-option-not-suppor.html
Seems the build template was broken. So, you can try with other build templates or starting over with an empty template, then add the needed tasks manually to check if that works.
Besides, you can try below things:
Clean the caches on your client machine, also clean the browser
caches, then check it again. See How to clear the TFS cache on
client machines.
Create a new team project and create a new build pipeline within the
new team project to check if that works
I am assuming this is a bug in the VSTS system and it will likely be fixed soon. But for the time being, I found a workaround:
I was also getting the AllowScriptsAuthAccess error and struggled with it for hours. I don't think any of the configuration settings you mentioned have anything to do with it (free account, GitHub, OAuth token unchecked).
To solve it, I converted the Agent Job to YAML (which is as easy as clicking "View YAML" in the upper right). Save the code to a file named .vsts-ci.yml, and save this in the root folder of your solution. Commit/push the new file, then queue the build. (Note that the conversion to YAML is one-way, so you may want to Clone your build.)
That should get rid of the AllowScriptsAuthAccess error. After that I had to add a few variables, but then it's just a matter of following the error messages.
I hope this helps. Sorry I can't answer this more authoritatively. Please post a comment if I am missing any steps.
I had this issue and it turned out that I didn't have Build Admin permissions in VSTS for the project. Not a very helpful error message for this.
My development team is using TFS for source control. My current plan is to have a new shared branch created each sprint for the developers to use for all their tasks.
What is the best way to ensure that the developers are performing forward and reverse integration every day for that branch? In other words, how do I make sure they are constantly getting the latest code set from the sprint branch and checking their code in as well?
There is no such VS extension can force developers to get code from TFS and check in frequently and continuously.
If which you want is to "get the latest " and avoid TFS force you/colleagues to resolve conflicts before checking in.
However, TFS redefined what "Get Latest" does. In TFS terms, Get Latest means get the latest version of the files, but ignore the ones that the server thinks is already in your workspace. Moreover, doing a get latest is good practice, but not mandatory. There is no such settings.
There has been some similar questions in SO and got an amazing answer, below links for your reference:
Is performing a Get Latest mandatory before checking in in TFS so you do not overwrite/lose code?
Why doesn't TFS get latest get the latest?
As a workaround, if you really need this feature in your team, you could set up a reminder such as meeting reminder in outlook 4:00PM to remind your colleagues, they should merge their work in the branch at the end of day. Just couldn't force them to do this.
This is a people problem, not a tooling problem. There's no way the tool can force their behavior when it comes to committing their code or merging branches. It's just part of workflow discipline, which will come with time.
is there a way to backup a JIRA project configuration and then restore?
The issue I have is that sometimes doing workflows changes I can break the whole configuration.
So, I'm looking for a way to easily rollback to the previous working version of the project configuration.
Please note that I cannot rollback the whole JIRA server as it will affect other projects.
We are using the latest version of the Jira Service Desk on premises.
Thanks,
Please, see full answer here.
You can't.
JIRA does a full export of everything, and you can import
the issues from one project from that. But that's it. If you need
single project backups with configuration, you'll need extra
functionality. This is exactly the case where I would reach for
Botron's tool -
https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager
Whenever you publish a change to a workflow, JIRA asks you if it has to save a copy of the original. If you do that, it should be easy to revert to a previous version. Still it gets cumbersome to manage lots of copies of a workflow and to understand what changed when.
If you want a bit more control, you can also export your workflow to xml and keep that somewhere. If you need to rollback, you can import from that xml again. For more details see the documentation here.
If you want even more control, then add-ons like Botron's configuration manager can indeed be useful.
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.
If I create a bug in TFS, is it possible to associate it with a unit test and be notified if this bug is fixed/broken?
Not exactly, but the workflow can go the other way: instead of creating a bug up-front, you can let Team Foundation Server handle the work item creation for you. If you create a continuous integration build that runs your unit tests, you can create a bug assigned to the user who submitted the changeset if that build fails (including because the unit tests fail.)
A good article on configuring continuous integration to do this is in MSDN Magazine.
A new feature in TFS 2010 is Gated Check-in, which will prevent this failing code from getting checked-in by requiring the build and test steps to complete successfully before they get committed.
There is, currently, no mechanism to do what you desire. You can force users to check in changes tagged with a work item, which you can then manually examine. Provided the user either alters a test class or creates a new one, and checks in with the fix, you can see whether it is done or not. But, there is no automagic "if this test is changed, alert me".
If you need some type of "change and alert" functionality, I would examine CodePlex and see if there are any tools of this type. It could be facilitated at the database layer, as well, but I am not sure what kind of monkeying that would take. I have not looked at the service endpoints for the latest TFS, so there may be a way to poll to see if there are changes.
Wish I had a better answer, but this is an interesting ASK, so I would consider going to Microsoft Connect for TFS and requesting the feature. It could be included in a future rev if enough people are interested in this feature.