Get code review status for a particular shelve set - shelveset

I am working on Build definition, where i have requirement to pull code review status for a particular shelve set. When i trigger a new Build with particular Shelve Set i need to check code review status is completed for that particular shelve set. Please provide me any code sample.

Related

Can I change the data source for my output jobs in Upsolver

Upsolver output is delayed/stuck - We changed the data source for some outputs to a new one. The odd thing is that the "delay" column in the outputs page seems to point to the old data sources and delay is not changing. Why is this happening, shouldn't the output now reflect the new data source and proceed ingesting data from it.
Did you by any chance stop the "old" data source before the old output version has managed to stop? In general when you edit an output and change the source, you need to let the old data source run until you see that the version has completed. This is because we still have tasks that we need to finish running until the time the datasource was stopped.
So, please run the old datasources until you see under the version history tab that the previous version is completed. This should change the delay from the previous version to the current version and you will see the correct delays.
For example if you goto the output, under Version History tab, it should show two versions. Please rerun it until version 1 has completed

How to change Rallys Test Folder status

Is there a way to remove the current test status from a Rally Test Folder?
I create test plans from these folders which carry their own test status, I can manage those, but our team updated the folder status when we moved to rally initially. I would not like to export to csv, wondering if there's a UI tool built in to Rally to reset the status.
Status is a rollup field, so it will always reflect the current status of the test cases contained within. There's no way to "reset" in.

TFS Build XAML Template at “AssociateChanges” step get all the Work Items since begging of the source code branch created

I have asked a similar question
TFS Build Configuration: get all the Work Items Details for a particular build
And based on the answer of above question I have the below query. I decided to start a new thread for new question rather than confusing people in same thread.
I am using a default XAML template for workflow of TFS build configuration. Now my requirement is that I need all the Work Items since beginning whenever I trigger a build event for any build definition regardless of last successful build.
Let say I have triggered first TFS build and it is succeeded then I triggered 2nd build and that is also succeeded.
Then I have opened the log file of 2nd successful build and goes to Diagnostics Tab of last build. Inside Diagnostics tab there is a section as “Associate the changesets that occurred since the last good build”
Inside this it will display a message like
"No change sets are submitted to build 'ABC…..'"
Whereas I require list of all the work items since beginning.
Please suggest me the changes which need to be done in XAML template so that I can get all the work items since the beginning of source code.
As we know, associate the changesets and work items only occurs since the last good build.
There is a simple workaround to achieve what you want, you can specify a previous changeset to queue a build, then build the latest changeset again, then you'll get the associated changesets and work items again. Refer to this blog: http://chamindac.blogspot.sg/2013/09/tfs-2012-get-release-build-with.html
Otherwise, you need to create a MSBuild custom task that makes a call to TFS for the items. Check the links below:
https://volatilecoding.com/2013/06/11/tfs-build-how-to-customize-work-item-association/
(this solution is for TFS2010/TF2012 build process template, you'll
need to work on TFS 2013 build process template).
http://devgorilla.net/?p=104

TeamCity REST API: Who broke the build?

In our office we use a custom Geckoboard to display information about our current build status from our TeamCity 8 build server.
We display recent check-ins/changes, using the following REST query: http://teamcity.internal.com:8080/httpAuth/app/rest/changes?project:ProjectName&locator=count:10
We also calculate the last time the build was broken with this REST query: http://teamcity.internal.com:8080/httpAuth/app/rest/builds?locator=project:ProjectName
However what we've not just been able to do is link the two.
In other words:
For recent changes to determine if the checkin lead to a broken build
For the last time the build was broken determine who made that checkin
Based on the source code here and documentation here
I believe you want something like the following
http://teamcity.internal.com:8080/httpAuth/app/rest/changes?locator=build:(status:FAILED,project:ProjectName,lookupLimit:1)
This should return the changes associated with the last FAILED build, I haven't tested because I don't use TeamCity.
Also see the following StackOverflow question in order to get changes for a specific build.

When a TFS build is triggered by a check-in what how does it do the get?

I have a CI process set up in TFS 2008 so that every time a check-in happens a build is triggered but only if a build is not already running. The exact setting used in the configuration is the radio button labeled:
"Accumulate check-ins until the prior build finishes (fewer builds)"
The checkbox "Build no more than every ___ minutes." is not checked
I have other build processes that might also be going on so I can see that a build is queued with a specific "Date Queued". When the build server gets to the queued build, let's say that it takes 10 minutes to get there, does it use the time-stamp of the queued build to do a get or does the build do a "get latest"?
I believe TFS will use the changeset of the last triggering commit (i.e. the build does a 'get specific version' by changeset ID, rather than a 'get latest').
You can check this by looking at the build report and finding the value for the 'Source control version' field, you should see something similar to this:
So first off, I would check that the value you're seeing for this is consistent with what you see in the build's workspace and that the build is referencing the expected changeset.
Assuming that your build is working as advertised (and this is a problem for you), then you may want to consider altering this default behaviour and force your CI build do a 'get latest' by overriding the 'GetVersion' MSBuild property in the build's TFSBuild.rsp file, by adding the following:
/p:GetVersion=T
Where 'T' stands for 'tip' (or 'head' in SVN parlance).