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.
Related
I have two BuildAgents in my Default queue. Both checkboxes for active are set, both are online and running and also shown as online and running. When I start a build on that queue, it is only sent to one Agent, never to the other. If I stop this one Agent, I get the error message, that there is no agent available. But there is!
Has anyone an idea, whats going on here?
Specs: I have an On-premise-TFS-2017 (it was upgraded from 2012). Build Agents where installed the way, that TFS-2017 describes it on the interface.
You get the message means that the build agent Capabilities don't meet the conditions which set in build definition (Demands settings) or build requirements.
Please try below things to narrow down the issue:
Check the Demands in your build definition, make sure the demands
you added are existing on build agent Capabilities. If not existing
there, just try to Add Capability for the agent manually.
Somethings the agent cannot automatically identify some components as
the system Capabilities. In this case you can try comparing the
Capabilities between the two build agents to identify the
differents. Add the missed Capability for the failed agent manually.
Then try it again.
Deploy a new agent to check that.
Reference this article : TFS/VSTS Build – System Capabilities and Demands
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).
We are using TFS and the TFS Build Service. We are considering to migrate the Build service to Jenkins but we came across some issues. According to this site, there are some things that do not work very well with the TFS and Jenkins plugins. All of them we use a lot:
Associated Change sets – Team Build automatically associates a list of change sets that are included in the build
Associated Work Items – Team Build analysis the relationships and also associates Work Items with a build. Indeed it walks the work item tree (parent) and maintains that association in the chain.
Is this still true? We have this scenario:
A developer checks in a code that fix a bug or resolve a User Story. It does that by associating his check in with the work item ID.
His check in triggers a build that will associate the work item with his changeset. For bugs, the build will update the "Integrated in Build" field with the build number. We use this field to know in witch version the bug was fixed.
Is there any way to make Jenkins behave and do what TFS build service does?
Another option is to mix the two using dummy builds on the TFS side that set the records straight and kick-off the Jenkins' builds. Some hints
How to trigger Jenkins builds remotely and to pass parameters and “Fake” a TFS Build.
This approach requires a bit of effort but has many advantages:
No big-bang, use Jenkins opportunistically
Can continue using existing builds
Having a build identifier in TFS allows you an overall monitoring and to use the Test features
I have a VSTS build definition for one of our projects that requires jenkins to build, but we still have all our other products using VSTS natively. To maintain consistency, this build definition triggers a jenkins build. We configured the build definition to not sync code as jenkins will download it (save time) and not to publish the artifacts back to the agent (i have another script for that found here). This allows developers to continue to use git as normal, and the build/release process is consistent with our other products. Along with task tracking and such.
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.
I'm trying to set up our TFS 2008 instance to require that projects build before they can be checked in.
I have created a check-in policy using the out of the box "Builds" policy, but I'm still able to check broken projects in after mangling the code and attempting to build the project.
We're a small shop, and TFS was originally set up with our team's Active Directory group listed as TFS admins. Is this the problem? Do check-in policies apply to TFS admins?
Any other suggestions?
Check-in policies are a client-side check only. If the client does not have the check-in policy available, the check will not run. Instead, they will get a generic policy failure saying that not all policies were run. Additionally, any user (there's no special permission for it) can override a check-in policy failure with a comment.
The "Builds" check-in policy does the following:
Request from the server a list of build definitions affected by this check in
For each build definition returned where the last build was not "good," create a checkin policy error message containing the build definition's name and the user that triggered the build.
If the policy detects a broken CI build, show an error when you attempt to check in. "The last build failed.."
It sounds like you're trying to make sure that people don't break the build with their check-ins. TFS2010 includes a new feature called Gated Check-In that validates changes before they are committed to source control.
If you are using TFS2008 and can't upgrade, you'll need to look at something like OpenGauntlet - however the user experience is much improved with TFS2010.
TFS was originally set up with our
team's Active Directory group listed
as TFS admins. Is this the problem?
This is probably not the best idea. Team Foundation Server Administrators can do destructive things like destroy files+history and delete projects. If there's any chance that somebody might become disgruntled, you might want to reduce the number of admins or ensure that you have good backups.
As a middle-ground, you could have 1 or 2 people as TFS Admins, and everybody else as a Team Project Administrator. Most people only need Contributor access though.
In TFS2010, there is a new concept called "Project Collections". Typically, organizations have 1 or 2 people as "Project Collection Administrators" so they can add new projects and build controllers.
Check-in policies apply to everyone. Did you verify that your deployment of the policy is active on all machines?