I am reading the instructions from https://learn.microsoft.com/en-us/azure/devops/repos/git/pull-request-status?view=azure-devops#status-policy.
I have a TFS Build Definition which executes tests for every branch and reports success/failure.
I'd like to link the corresponding build to the Pull Request as well (and make require a green status to merge, if possible), similar to the screenshot below.
How can I do that, do I edit the repo Policies or in some other way? The link doesn't give much detail on how to do the actual linking.
Go to your repo -> branches -> select the branch that will be the target for your PullRequests -> Open the context menu left to the commit-id -> "Branch policies".
There you define your criteria for pull requests and can add a build under "Build validation".
Related
Our TFS 2013 admins have given us one build definition to build our solution and run all unit tests and they are not willing to create any more build definitions. We are following feature branch strategy and would like to use this build definition for our gated builds. I am trying to find how to use this one build definition with multiple branches.
I know, I can add all branches to Source settings and build them whenever a check-in is made. But I want to find out, if there is any way to add branches to Source settings, but only compile the solution that has been checked in. For example if we add 5 solutions to the Source settings, we want to compile only the solution that has changed rather than all 5 solutions.
You will need to setup an incremental build that only builds the solutions that have changed.
Ideally you will want to setup a build for every branch. You would still use the one build template given to you, but you would define the work-spaces and behavior differently for each branch depending on your needs. However if you do not have that option you can still implement what you are trying to do.
For example if you only want to build the solution that has changed you will set up your build to be an incremental build like the following:
In the "Process" tab update the "Items to build" section to any *.sln or *.*proj
In the "Workspace" section, select only the source control paths of each branch if setting up a build for every branch or select the entire source if that is how you have to do it ($/).
Change the build to an incremental build by changing the Build Process Parameters on the "Process" tab - CleanWorkspace=None
Tag one of the build agents, so that it is the only one used for these incremental builds. Set the build to only use this tagged agent. It is important that the same build agent or set of agents is used for the builds if incremental builds are to work.
We have 3 TFS branches – dev, test, and prod.
TFS works well for us as source control as long as we check in and get latest often. Then the merging is small and we can resolve any issues right away. We know that if we don’t do this every day, then merging our code will be painful.
But by the time we are ready to promote to one of the other branches, there are huge changes in the code. We don’t want to keep any of the code in the target branch, and we really do want an exact copy of the source version, not a merge.
We do like having the 3 branches so that change sets are kept for the complete set of changes in each deployment/promotion.
I don’t see a way in TFS to do this very common function. I have been using two workarounds:
If only one user does the merging from one branch to the next, TFS really does copy all changes. But it does not work if the user is different than the last user attempting the promotion, then TFS will merge the code.
I have checked out the whole solution of my local copy of the target branch. Then done a file system copy of the source branch folder into the target branch folder. Then checked in the solution.
Is there a right way?
The correct way to merge is:-
Set up a shared workspace that contains both branches (if you don't already have one)
Get the latest Target branch code
Get the latest Source branch code
Merge from your Source to your Target using Latest Version and All Changes to a Specific Version
Submit your Changes to Source
To overwrite the target if you get conflicts, to ensure that the target is definately overwritten, Select Choose Source version at the conflict window
I know this post is way late, but
My solution in this scenario
Prod -> Dev -> Test
(parent) -> (child) -> (grandchild)
When test is ready to be promoted, I do the following.
Delete Prod (This can be undone with rollback, but check-in)
Branch Test -> Prod (Use the same name a location as the old deleted version), so your new branch structure will be Dev -> Test -> Prod
Reparent Prod (new branch) to "none"
Reparent Dev to Prod
Delete Test
Branch Dev -> Test
When you look at the new branch hierarchy it will look the same as when you started but the code in prod will be the same as Test.
We use TFS source control and have two build controllers (one VS2010 the other VS2012). We use the default build workflow template bar a few custom changes.
As we have many branches, how would we go about changing the workspace based on the desired branch?
I was thinking of adding a parameter for the branch ($\oursourcecontrol\branches\main) and then just passing it as a variable in to the get workspace part of the workflow.
Or is there a better way of doing it?
You currently can't and it is really a shame. It would completely break the Trigger support for CI and Gates checkins. You can use the TFS Community Build Manager to quickly clone and adjust build definitions to support multiple branches though.
What you could do, is to fetch more than you need (say $/Sourcecontrol/Branches/*) and then use a string-replace on any path parameter (like solutions to build, test settings file etc) to point them all to the correct solution. You'll probably need to do some templating like {BRANCH} so that you can easily replace these tokens.
The Git build template does support this on a Git repository, but you'd need TFS 2013 to make use of server side Git support.
I mapped the server path in the Repository tab at higher level that TFS branches are contained. Cloak rest of the branches not required for Get sources step except the branch to be built. And create variable to pass the branch name, check allow at queue time. Use this branch variable in build steps to make the build definition work for all the branches. You may need more than one variable based on your branches structure in TFS.
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 a "Main" branch and a "Dev" branch in source control; pretty common approach where developers work off of the Dev branch and merge changes to Main at set periods when the code has been unit tested and is ready for customer testing.
We link Work Items like PBI's (Scrum) and require comments on checkins. Normally the TFS build report will show the attached work items and changesets. Our dev build (Dev branch) does indeed do this.
But, our Main build which uses merged changesets from the Dev branch doesn't "inherit" those links. If you read our Main build (Main branch) report it shows none of the original changesets; just the "Merged from Dev" one.
Does anyone know if it is possible to make TFS look though the branches for all of the changes from the merges and put those in the build report?
What you are looking for is only available in 2010 I believe.