Is there a way to configure TFS as follows:
When Build Fails:
Send an email to the breaker(s) only.
If build still broken after minutes, send an email to the team that says "Build is still broken"
Repeat ad-nauseum
I know how to do the first part. (Alerts Settings)
Is there a way to make it repeat sending (nag) until the build is fixed?
Not out of the box, but...
You can configure your alerts to send as text/html/soap. So if you spin up your own web service that does the nagging you can have TFS easily turn the nag of and on...
Set up a continuous integration build. That way, every time someone checks in code, the build will run and fail. Or hopefully, not fail.
Related
We are currently checking the test plan module on our Azure Devops server and I'm facing an issue that the community may help.
According to this once a test run has been marked as failed or blocked there is no way to resume the test once the raised defects have been resolved. You either have to mark the test run as paused (so as to be granted the "resume" option) or reset the whole test to active in which case you loose all your progress and need to start over. Two questions:
This "workaround" works as long as you are careful and save the test run as paused. Otherwise if a failed step exists the run is saved as failed. Once this is done I have found no way of changing it to "paused" so as to get the resume option. Is there a way I'm missing?
In the test list under a specific suite you get the current test run outcome and state of test case. In case of "Paused" you don't have a way to know if the test execution is paused or you are utilizing the aforementioned workaround (e.g. a bug is registered). I cannot see a way that I could enhance the test run with some information that would signal this (there is no wit template I have found) on the grid. So is the standard query module (bringing testcases and associated bugs with state) the only way?
thanks
For the first question, if the test case is on status Failed and you retest the test case, all test steps need to be redone. Also there is no resume-button. This is by design. For now, set the status to Paused can resume the test, but it cannot truly reflect the result. As far as I know, there is no other way.
You could add your request for this feature(For example: when status = Failed/Block, the restore button is enable) on our UserVoice site , which is our main forum for product suggestions.After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.
For the second question, as workaround , you can also add tags to paused test cases for labeling.
I'm currently using AppCenter to Test my Xamarin app. The complete suite is being run at night. But I'm currently looking for a way to make this part of my CI builds to introduce an extra quality gate before features get merged.
However, we would need to slim down the amount of tests that need to be run otherwise this would become unmanageable. For this we can specify categories on our App Center test build step. When queued manually I'm able to specify the categories, however when we make this CI Build part of a branch policy and use a manual trigger for our build validation we are unable to specify the categories as we don't get the popup when queuing.
Any suggestions on how to adres this issue differently?
Seems you want to set build variables in pull requests when you queue the build under policies.
Unfortunately, this could not be achieved by now. It will not pop up the dialog when you queue the build. There has been a related uservoice, you could vote up and follow it, TFS PM will kindly review your suggestion.
Allow Setting Build Variables in Pull Requests
https://developercommunity.visualstudio.com/idea/365725/allow-setting-build-variables-in-pull-requests.html
The only workaround for now is editing the build definitions and add the variable under variables directly, then queue again. You could clone the original build definition first.
I'm trying to execute a bit different build steps in VSTS based on type how build was started: automatically or manually.
I'm especially interested in accessing that information from powershell script. But so far was not able to find suitable solution or workaround.
Did someone faced similar requirement before? How did you solved it? I would appreciate your help!
Seems you want to know whether the project build is happening through TFS triggered build or manually triggered build.
There is no such feature for vnext build for now. About this , you could submit your uservoice to this link, TFS Product Team is listening to your voice there.
As a workaround either to use two build definitions through different version patterns or manually add a specifical tag after a manually build finished. Through using tags to set some labels on the build to distinguish manual and automatic builds. But this is a manual action, it would be better if we can do this automatically.
It seems to be I've managed to find an option that allows to determine wherever build was triggered automatically or manually.
All builds started manually have actual user in $Env:BUILD_QUEUEDBY variable, while automatic builds have system account there. My value was [********]\Project Collection Service Accounts.
I don't know how reliable it is, but for me so far following code did the job:
# Identifying who triggered the build
$OwnerId = $Env:BUILD_QUEUEDBY;
$OwnerId = $OwnerId.ToUpper();
if ($OwnerId.EndsWith("PROJECT COLLECTION SERVICE ACCOUNTS"))
{
Write-Host "Build was triggered automatically. Resulting files considered 'BETA'"
}
else
{
Write-Host "Build was triggered manually. Resulting files considered 'STABLE'"
}
I have set up Jenkins to use the GitHub pull request builder. It's working great! Except one little thing. My test suite creates HTML Reports (which I have beautifully posted using the HTML result poster plugin) but I can't seem to change the status message that gets posted to GitHub. My commits all get marked like:
The status of the commit gets updated properly, but the message part always says "Build finished. No test results found."
I can't seem to figure out how to change this message based on the status of the test suite. So, basically the only feedback I'm getting is the exit status of my shell script. This script does all of the building, testing, and handling of results, etc. This is reasonably acceptable in the event of a pass, but in the event of a failure, this message could be much more helpful! Even just knowing whether it was a build failure vs. a test suite failure would be nice, so then I can adequately verbally abuse the person who made the pull request :).
Everything else is working so good, that I can't figure out what seems like a trivial change is driving me crazy! Any ideas?
FWIW, the logic was added here: https://github.com/janinko/ghprb/commit/ffbc581d2712d6b99b9c6d0b081d7895a5ee8039
I believe you just need to generate JUnit formatted test output, and you may or may not need to ad a post-build step to publish the JUnit XML output.
This trips up a lot of newcomers to TFS, and I'm keen to hear your solutions.
So you've fixed a bug, tested it, looks good, everyone is on top of you to get it out as soon as possible, so you queue a new remote build, wait patiently, then put it into test/production only to find out it's actually an old version - you forgot to check in before doing the build!!
OK, so this is a common oversight, and it costs valuable time. Is it possible to pop up a warning first, or is there some neat trick other have found to avoid this?
Instead of manually kicking off a build after you check-in, what if you set up a "Continuous Integration" build so that the build would be automatically kicked off once you checked in? This way it would be impossible to forget to check in your changes. Here is an article on how you can set that up: http://msdn.microsoft.com/en-us/library/bb668971.aspx.
Continous Integration as mentioned above is the best solution! :)
But you could write a custom activity within your build definition to check if there were any new changesets since the last build and if there is no new changeset show a warning message in the build log or something, but then again the developer has to read to log otherwise it's not useful.
I wouldnt spend any time at all for something like this, I would rather knock on the developers head everytime he misses the check-in! :}