I have been removing unused releases in TFS 2017, due some of them were created automatically and never used. but this task is monkey job. I would like to perform a bulk deletion, or create an script to delete them.
So far, I was checking the REST API but there is no option to abandon or to delete the releases.
Any other suggestion?
Based on my test, you can use the REST API to abandon or delete the release.
Abandoning an active release: (Mentioned in the official document)
PATCH http://server:8080/tfs/DefaultCollection/LCTFVCScrum/_apis/Release/releases/10?api-version=3.1-preview
{
"status": "abandoned",
"manualEnvironments": null,
"comment": "Abandon the release"
}
Delete the release: (Not mentioned in the official document, tracked with the Fiddler tool )
DELETE http://win-server:8080/tfs/DefaultCollection/LCTFVCScrum/_apis/Release/releases/9?api-version=3.1-preview
Both of them work well.
So, you can get the release list first using REST API (to get the release IDs), then create a script to delete the releases with the Release IDs which you want to be deleted.
Get release list:
GET http://server:8080/tfs/DefaultCollection/LCTFVCScrum/_apis/Release/releases
Related
I'm using Microsoft Visual Studio Team Foundation Server Version 15.112.26307.0.
Using the Releases page/view for a group of approvers to review and manually trigger the release from environment QA to environment PROD (first environment triggers automatically).
From that screen, the approver clicks the icon and then in "override" to approve and launch second environment... on that action (popup) it asks for a comment and the the user clicks the approve button which triggers the next release environment... until here, its the standard way from TFS....
I wanted to know if there is a way to list all releases that completed all environments, and on that list show who approved it and also the comment entered... is it possible to customize a view or create a whole new list querying that information? Its a information/audit list only... no need to take action from there... just summarize the information for review.
Thanks!
You can use Releases - Get Release API to get the information you want. Since you are using TFS 2017 Update 1 RTM, you could capture the rest api by pressing F12 in browser then select Network. Check the screenshot below:
I've tested the following api in Version 15.117.27414.0, and get the comments successfully:
Get
http://tfs2017:8081/tfs/{collection}/{project}/_apis/Release/releases/{releaseId}
Assume the following build
Powershell Task Write-Host 'Original1';
We create the following draft
Powershell Task Write-Host 'Original1';Write-Host 'Draft2';
At the same time we had to change the original build - set Continue on Error, for example, and a new Timeout value.
Then we publish the draft. The original build would become
Powershell Task Write-Host 'Original1';Write-Host 'Draft2';
But both Continue on Error and Timeout would be overwritten with the values from the draft (original values at the time the draft had been created).
Perhaps I am missing something in my understanding how drafts should work (there is basically nothing about them on https://learn.microsoft.com/en-us/), or perhaps it is even a genuine defect in the TFS version we use (2018.2), but I'd have expected either a proper merge or at least some message preventing one from overwriting the changes in the original build.
Otherwise drafts just seem to be of very limited and error-prone use.
Am I missing something?
P.S.: Tried different combinations of changes on multiple tasks and etc. In some cases(when modifying inline powershell in the same task) drafts got "published" (as deleted), but no changes at all made their way to the original build (not even a new history entry), so I am much more inclined to think that the entire drafts feature is a bit defective as of now
We have contacted Microsoft and as of now (end of 2018) the current behaviour is considered to be by design
As it turns out, as of now this is the intended way for it work. The
Draft option just exists so that you can first test a definition
before committing it.
So, until something changes, the Drafts feature should be used carefully in any environments where concurrent changes to(drafts of) builds/task groups/releases can be made.
We use Jenkins to verify patch sets. Sometimes Jenkins needs do some changes on the patch set. So it commit --amend the changes and then uploads the new patch set.
It work nicely besides the fact, that all manual reviews made to the original patch set get erased.
How can I push a new patch set (from Jenkins) without loosing all existing reviews/votes?
Be aware that, in the situation you have described, you have a new patchset and, excluding in special situations, you don't want votes of the old patchset copied forward to the new patchset. For example: if someone have approved the patchset1 and Jenkins pushes the patchset2, probably he/she doesn't want to have his/her vote automatically copied to patchset2.
Said that: you can control how votes will/won't be copied forward to new patchset setting the label.LABEL-NAME.copyXXXXX options of the project. See more info in Gerrit documentation here.
Now that TFS 2015 comes with the same new Rest API of VS Team Services, I've taken a look at the API doc:
https://www.visualstudio.com/en-us/integrate/api/git/overview
One question naturally raised is that most queries do not expose an parameter for git branch or tag (e.g. download /path/to/my/file with tag 'release_v1.0'), which looks like a show stopper. As in my case, I need programatically pull out some source file under a certain branch/tag.
Is it not supported yet?
Yes you can. As or the link that you have above you can use the provided so to retrieve both branches and yes. In git they are really all the same thing, pointers. This use the "refs" api.
https://www.visualstudio.com/integrate/api/git/refs
If I have multiple patch set versions for one change in Gerrit, it seems like I can only submit the latest patch set version (because only that one has the necessary button). Is there an easy way to instead submit one of the old patch set versions of the same change, using only my web browser on that Gerrit instance?
I know that I can fetch the wanted version of the patch set from my git client and push it as yet another new patch set version on top, but I would like to avoid having identical patch set versions multiple times in the review and discussion around it.
No, sorry, this is not currently possible. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted. They also can not be reviewed/verified. If you want to use an older version of a patch set, you must re-submit it to make it the most recent patch set. To avoid no new changes error do git commit --amend and git will create a new sha1, which will be happily accepted by Gerrit as a new patch set.
There is no proper way to do this using only Gerrit UI. Cherry-pick the specific "patch set" of the "change list" (e.g. if there are 15 patch sets in a Change List and want to revert back to patch set #8). Get the cherry-pick command from Gerrit UI for the required patch set.
Run that cherry-pick command, and use git commit --amend, then push your change. It will generate new patch set (for above example #16).
The only way I could do this was as follows (from the change refspec assuming you are in Gerrit revision "<change-no>/3" and want to go back to "<change-no>/1").
git review -d <change no>,1
git commit --amend # modify something in the commit message
git review # resubmit the changes, will submit to rev 1