My team leader wants to get notified whenever changes are made to a specific Project.
Is there a possibility within Git to supervise specific Folders or Files and get notifications if the code changes?
If you are just looking for an FYI, you can configure a build job with continuous integration enabled and the 'Path Filters' set to the folders or files you want to supervise. This build definition could be empty as you are not actually trying to build, but rather kick off a notification workflow.
This would create a build each time a file or folder changes that is in the path filter. You then have to decide how you would like to be notified. Here you have a couple options, but 2 fairly easy ones would be as follow:
Use a Send Email task from the VSTS Marketplace, there are a number of options depending on your needs. VSTS Marketplace Email Tasks
Configure a new 'Notification Subscription' under Settings -> Notifications and set this up to send an email to whomever is doing the monitoring any time a build completes for that definition.
Note: if you want to prevent changes to these areas, then you should use branch policies suggested by Daniel Mann.
Note 2: Depending on the volume, if there are tons of changes to these paths, you may overwhelm your build server or consume all your build minutes quickly.
You can configure branch policies for your repository to require a code review; this will trigger a notification.
The branch policy can be limited require review only for certain files or folders.
Related
My scenario is as follows:
Developers check-in SQL changes to directory ClientDB
A dedicated build wakes up, extracts the metadata from the checked-in files, processes it and checks the result in into a sibling directory ClientMetadata
(Developers are not allowed to check-in under ClientMetadata)
The annoying side effect, is that because the dedicated build is a CI build it wakes up twice:
Once for the changes in ClientDB, which makes it update ClientMetadata
Second time, because of its own changes in the ClientMetadata - after all, this directory appears as an Active directory in the Source Settings section of the build:
Ideally, I would like the ClientMetadata directory to be available in the workspace, but I do not want changes there to trigger the build.
Is it possible?
If the 2nd checkin from the build is done with a checkin comment that has the text ***NO_CI*** at the end, the continuous integration trigger will be suppressed.
It's a hack, but it's how gated checkins work OOTB with TFS.
What does ***NO_CI*** stand for?
Not with XAML build. It's absolutely possible in the build system introduced in TFS 2015.
When you select this trigger (CI) whenever someone checks in code, the build will run.
Actually check in files to source control during a build pipeline is not a recommended suggestion.
If you don't want to cloaked the ClientMetadata folder and still want this be pulled down on build agent during get source. Please try below workaround:
You could remove the active status for this folder and add a customize activity to only get files from TFS server path($/../../ClientMetadata) to the agent $(BuildDir).
I maintain our build process on our TFS 2012 system.
Up till now I've been making changes locally to a solution that generates our custom activity DLLs. These DLLs are checked into TFS and are used by the build controllers and agents for the custom activities in our custom build template.
For all of my code and workflow activities I have a unit test library that I can locally run to put in some base test values. While this gives me a good idea at how my custom tasks will run it is not optimal.
What I would like to be able to do is run the entire build definition. Is there a way to test the whole build process locally so that I can be sure that my changes to the workflow are acceptable before checking in and kicking off a build? Right now my builds take between 30 and 40 minutes to complete and I would like to be able to start, monitor, debug, and stop the build locally without occupying one of our agents.
Edit
Another method for me to solve this problem is to come up with some manner to execute the workflow that is the build template locally. Has anyone been able to do this?
Take a look at the Ranger Build Customization Guidance. There is a HOL for doing a lot of this. It doesn't look like it is in v2 so take a look at v1.2.
http://vsarbuildguide.codeplex.com/releases/view/87995
If I am understanding the issue correctly, one way to do this may be:
Install a build agent locally and register it with the TFS Build Controller.
Give the new agent a custom tag so it doesn't get assigned other builds from the queue
Shelve your changeset
In VS, right click the build definition you want, and select queue new build. A "Queue Build" window will open
Under the general tab, "What do you want to build", select your shelveset.
Under Parameters tab ->Advanced -> agent settings, enter your agent's tag.
Click queue.
I accomplish this using a modified version of #malexander recommendation.
Create a code branch in TFS, commit your changes there, especially the changes to your custom activity DLL's (compiled binaries, not just source).
Install a TFS Build Controller and Build Agent locally, registering the controller with your TFS server.
Configure your new local controller to use your modified custom activity DLL's, stored in your new TFS code branch. Team Explorer > Builds > Actions > Manage Build Controllers >
(select your new local controller) > Properties > Version control
path to custom assemblies
4.
Queue a new build, from an existing TFS build definition: change its controller to use your new local controller.
The new build will execute on your local controller/agent, using your modified custom activity DLL's, without interfering/restarting your production agents.
Also: since you're in your own code branch, you can commit debug versions of your custom activity DLL's, without impacting your production agents.
We have been using TFS 2010 to manage work items and sprints for a while now and have recently added on a dedicated QA person. What I need to be able to do is to either create a build definition that I can run on a scheduled basis (Tuesdays at 9pm for instance) that will only build and/or deploy the Work Items that are in a State of "ReadyToDeploy". Or a way to get a list of files to push based on the TFS API.
My end goal is to have a way to automate the release process so that only the items that have passed QA are sent to our staging environment weekly. Then the customer or QA can approve that the items work in staging which is a mirror of production, and another process or build definition will deploy those items which will be in a different state.
I have modified the work items and work flows to accomplish the different states, but I am having an issue getting either a build of just the fixes or a list of all the files to push based on the state of the work item.
I am open to any ideas or solutions for this, the alternative is that I have to manage the list of files and manually push files every week and I am trying to get away from that.
Thanks,
Edit: The way we have it setup now, is that each developer has their own branch and own website, our software is server based and has to be run on a particular server. Our Trunk is linked to the main dev website. This is where QA initially does their testing to move an item to the ready to deploy status. When a dev is ready for QA they check in their changes in their branch and merge into the trunk. The builds are created off of the trunk at the moment. On our deployment nights I open up the trunk website in VS and do a publish then take those files compared against a list the developers have given me and ftp the compiled files to our production server.
I could be wrong, but I am not aware of a way to tell a build to avoid certain changesets based on the state of an attached work item.
I think the only way you could achieve this would be to create a Release branch and perform a daily merge of changesets that are in the "ReadyToDeploy" state. When you merge, you are able to cherry pick changesets, but they must be contiguous. This means that you would have to perform multiple merges to get the Release branch into the appropriate condition.
We have operated something similar for many years and it works well for us. Many people will tell you that it's bad practice, and it probably is, but that is for you to decide.
As for automating this for a build, I don't think it would be a trivial job. The hardest part will be the merge. You might think that there will be no conflicts as it is a one-way merge, but having done this for a number of years, I can tell you that conflicts do arise.
Step By Step Explanation
Create a branch off the trunk called release
When you want to do a deploy, merge from the trunk into release, but only cherry pick the ReadyToDeploy changesets. This may take several merges as the changesets must be contiguous.
Fire off a build / deploy of the release branch.
Repeat steps 2 - 3 as your release schedule allows.
You could do something automatic, it would require an extensive bit of coding. It would also require a branching strategy so that, Dev, Staging, and Production all come from their own branches.
Set up a process that uses the TFS API to scan for items in that state
Use API to Traverse Items to get check ins attached
Use API to Get latest of source and target branch
Use API to Merge by change set (identified in #2) (this is non trivial, have to handle lots of cases, but merging should all be 1 way with no conflicts, so doable)
Use API to Check In
Kick off Compile Build
If Compile Build Successful kick off Publish Build
To the best of my knowledge there is a major issue with this approach. Say you have two changesets: # 1 and 2. Both of them containing modification for the same file. Now changeset #2 contains its own changes plus changes from #1.
If you decide to pull in changeset 2 and skip #1 guess what's gonna happen. You are going to suck in changes from #1. This is obviously a problem.
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 currently working on creating a build template for TFS2010 builds. However, I notice that I'm currently 'spamming' the source control with every change I make to the template (and lots more for all the fixes for those changes).
I wonder what the easiest way is to test the build templates I'm creating?
Is there a way to change the template file and custom activity dlls that doesn't involve checking them in?
I currently have a build controller and agent running on my developer machine, which I'm using to test the template (test = start a build and hope for less errors than last time).
Why is 'spamming' a problem? Anyway, I have a separate Team Project for doing this kind of work, that way I can check in to my hearts content without affecting the developers who need to have a stable build. once I've done my testing I check the template in to the team project(s) used by the developers.
I want to test my builds against the teams latest code-base without having to branch it over to a trial project.
Instead, I do the following:
Create a separate build definition called 'Infrastructure'
clone a production definition
Set the trigger on the Infrastructure build definition to manual.
Set the Infrastructure definitions permissions to allow only [Project]\Build group members to have full control of it.
keeps the notification of broken builds away from the bulk of the team).
Create a separate build process template, called 'Infrastructure.xaml'.
Point the Infrastructure build definition at the Infrastructure process template.
Now when I want to iterate on a new build feature for the team:
Check out the build process template I want to update, and lock it.
Copy the build process template I want to update overtop of the Infrastructure.xaml.
Add my build feature to the Infrastructure.xaml file, and check that in.
Use the Infrastructure build definition to test my changes.
Iterate over 3-4 until I get it right.
Complete the feature and have my changes verified by another Infrastructure team member.
Copy Infrastructure.xaml over the build process template I locked in (1) and check it in.
This still results in 'spam' in the TFS source control, but it keeps the build definition iteration out of the eyes of the team. My build process templates are located out of the main source tree (under the Build Process Templates folder, or in the branches themselves under a 'Core/Build' folder where no-one else on the team is typically paying any attention) so that the team is largely unaffected by it.
#d3r3kk: Why not just branch the template and merge changes back when ready instead of creating copies? That way you can preserve source history in a cleaner way as well.
Ideally, there should be a way to have a build process template that is in progress by having it on your local file system and pointing the build definition to it temporarily. Not sure if something like this exists in later versions of VS/TFS. I haven't seen it available via the UI anyway.