We have a team alert in TFS 2015 that sends an email out to all developers whenever one of our builds fails.
I'd like to modify it to not issue emails when someone fails a private build, or a private gated check-in fails (we don't use gated check-ins by default). In these cases, a separate alert will issue to just the individual developer.
Below is the current criteria
However, when I tried to run a manual gated check-in just now, the build failure issued an email to the entire team.
What additional conditions are required to ensure that these emails are not generated when I create a build using a shelveset - whether or not I choose to automatically commit the changes on success.
There is no private gated check-in build, "gated check-in build" is not Private build.
You queue a private build if you want to build the changes that you
have put into a shelveset.
More detail info with private build in TFS, please refer this MSDN link:
Queue a build
When you are going to use the private build and not issue emails when someone fails, you can add a build reason not contain check in shelvest as a workaroud.
The part above your screen shot is the part that identifies if the alert is being configured for a Team (sends to everyone) or a personal alert (just to you).
Related
I don't understand why can I check this two options together because this options are not similar in their behavior.
I only want to check in the changes when the build (CI) succeeds.
What I need to do?
Have a nice day.
There is no impact between CI and Gated check-in. When you select CI, it will build whenever someone checks in code, it happens after the changes have been checked in to TFS. If you select Gated check-in, it will accept check-ins only if the submitted changes merge and build successfully, which means only the build succeeded the changes can be checked in.
By default, CI builds are not run after the gated check-in process is complete and the changes are checked in. However, if you do want CI builds to run after a gated check-in, select the Run CI triggers for committed changes check box.
Detailed information you can refer to the link below:
https://learn.microsoft.com/en-us/vsts/pipelines/build/triggers?view=vsts
Since you only want to check in the changes that builds succeed, you
should only select Gated check-in.
I created a ci build in tfs 2015.3. On the trigger tab I set gated check in.
Is there a way to let the developer now in vs that the build failed. Currently there is no way, I do not want to use alerts, I would like for a message in vs.
In addition, when the build fails, the files are checked out on the build server, how can I cancel this behavior, this requires a tfs admin to release the files.
In TFS 2013 there used to be a tool called Team Foundation Build Notification that shipped with Visual Studio 2013. However this is no longer the case.
If you don't want to use e-mail notifications there are third party applications that you can run in your tray to receive build notifications. I have used catlight myself recently for the exact same problem. If you are using a chat application like Slack you can also integrate build notifications into your team's slack channel to be notified on build failure.
To answer the second part of your question it is important to understand what a gated check-in does exactly.
When you check-in and a gated check-in is triggerd your files are not checked in but TFS creates a shelveset instead. TFS will then perform a private build using the latest version of the sources in combination with the shelveset it just created. Only when the this private build passes the pending changes in your shelveset will be checked in by the build on behalf of the user who triggerd the gated check-in. This will create a new changeset.
Upon check-in all locks will be released so all files that have a check-in or check-out lock will be released when the build server checks in your changes on behalf of you.
When the build fails no the changes in the shelveset (created when the gated check-in build was triggerd) will not be checked-in by the build server thus the locks will not be released. In the source control explorer the files will still have pending changes (and be checked-out) because the changes in your workspace have not yet been checked-in. This is the intended beheaviour and should not cause any issues for you unless you have disabled multiple check-out and you are, by having these files checked-out, blocking other developers from making changes.
I would not advise you to use a gated check-in when also not allowing multiple check-outs. Furthermore I would not advise disallowing multiple check-outs if it can be avoided in any way.
A gated check-in is meant to safeguard the repository from receiving check-ins that would break the application (it no longer compiles or unit tests fail) or diminish the quality below your standards. However this also means you cannot check-in until all the rules and validations you have in your build process pass and thus means other developers will be locked out until you are able to get past the "gate".
We'd like to have a process like the following:
User submits code review with shelveset of changes they want to be in master branch.
If code passes review, select group of users can pull down the shelveset, and merge the changes into master using the original authors name for historical tracking.
I can use the tf checkin /author:{OriginalAuthor} command, but this doesn't work with our gated build. If I bypass the gated build, it will check in on the original authors behalf, but using the gated build it seems to pull the Author from the shelveset which is still marked as coming from my account/workspace and not the /author.
So I'm wondering, is there a way to have the gated build honor the /author argument for the final check-in that it performs?
I just tested in TFS 2015.3, and enable a Gated Check-in in new build system.
If I use tf checkin /author:A, I'll get a shelveset with message below:
Your check-in has been placed into shelveset
Gated_2016-10-27_01.53.28.8457;B and submitted for validation by build
definition \ScrumProject\Visual Studio.
Once user B request a review, user A re-run command tf checkin /author:A, you'll see the message below, and the change has been checked in by user A.
We are taking on new developers and encouraging them to use TFS2010's private builds feature - a build is done using a shelveset, so you can see what impact changes will have.
We have TFS set to email the dev team, and that's what's causing the problem: TFS emails the whole team with the result of the private build, which causes confusion over the current state of the 'public' build when a private build fails.
The only difference in the email is that private builds don't label the sources, so the subject line is Scrum Build 8518 failed rather than Scrum Build CI Build_20111007.5 succeeded. While this is enough to be able to distinguish the two once you're used to it, it's confusing at first.
Is it possible to disable the email alert for private builds? Alternatively, is it possible to change the subject line if the build is private to something more explicit?
I've looked at the JobStatusAgent config and the email templates, but I can't see anything there that will help. We are using the default template, if that's relevant.
Definitely recommend the Alerts Explorer as suggested by #Edward. You don't need the whole team to install the Power Tools, just a couple of team members to manage Project level Alerts should suffice.
With the Alerts Explorer, you can then set up the alert to filter for the Requested By or Requested For fields. In case of Continuous Integration builds, the Requested For field contains the user whose check-in triggered the build. The Requested By field contains the user who requested the build. In case of CI or scheduled builds, this will be the Build Agent service account. Unfortunately, this doesn't really help if you have public builds that are manually requested.
Are you configuring your alerts with the Alerts Explorer power tool? It's much more powerful than the out-of-the-box alerts functionality.
You can configure more fine-grained configuration on the alerts - for example, Title contains " CI ", build number string matching, or based on the person requesting the builds.
Please have a look here, where I 've discribe a method to insert a new build argument named "BuildType" into your Build Process Template.
Using this additional parameter we control the sending (or not) of an email to the QA-team.
I'm trying to set up automatic notifications for our test team so that they're told when they're ready to test a user story.
The notifications are currently firing when the "Fixed In" build for the work item changes.
Our nightly build deploys to a staging server. I want this build to update the "Fixed In" build.
In addition, we have a gated checkin build. I do not want this to update the "Fixed In" build.
I tried changing the "Associate Changesets and Work Items" property in the build definition to "false", but the gated checkin is still being associated with (and updating the "Fixed in" build of) work items.
How can I prevent my gated checkin from being associated with work items?
Is there another smarter way to automatically notify the test team when a work item is ready for testing (as opposed to just having been checked in)?
We have a similar set up, with 'private' builds being fired when developers check in in the DEV branch, and 'integration' builds that are actually the ones that are relevant to the test team.
Both 'private' and 'integration' builds derive from the same build process template, but are different build definitions.
We have constructed in the build solution a custom activity "Types.cs" (basically a simple enum):
namespace BuildTasks.Activities
{
public enum QATypes
{
Private,
Integration,
Release
}
}
This is passed as possible values of an build argument we have added named 'BuildType':
.
This appears now as a configurable build definition parameter:
We obviously enter 'Private' or 'Integration' in each definition accordingly.
In the final steps of our process, we check on the value of this param & depending on it we send (or not) an email to a QA alias.
It might be possible to organize a similar implementation to meet your needs.