search

huserben / TfsExtensions

Extensions for TFS 2015+ such as custom Widgets (require TFS 2017) and Build Tasks
MIT License
45 stars 22 forks source link

Creating a main Gated check-in enabled build definition and using a single source for all triggered builds. #19

Closed LesCodeables closed 7 years ago

LesCodeables commented 7 years ago

We have multiple CI build definitions which I want to trigger from one main Build definition to enable gated check-in. I want to know, will it get the changeset in the child builds and build the solution or it will get the latest source in the child builds?

huserben commented 7 years ago

Hi

by default it will use the newest version. However under advanced properties you will find the option "Use Same Source Version" which, when activated, will trigger the builds for the same source version as the original build

LesCodeables commented 7 years ago

Hi, In case of gated check-ins the changeset is shelved and built. If the build fails then the checkin is denied. I know that by default it gets the latest version, I want to know whether it will pick the shelveset for child builds.

huserben commented 7 years ago

Hi

yes, as said, if you tick these 2 options under Advanced Configuration: shelveset

it will run the triggered builds for the shelveset: triggeredbuild

And the triggered build will then use the same sources: build

This should support your gated check-in use case.

However as far as I understand the gated-checkin process it will check whether the triggered build will be successful. This means you need to wait for the triggered builds to finish and in case they fail as well fail your gated check-in build. In order to wait for builds to finish you need at least 2 build agents, as otherwise you will end up in a deadlock situation as the triggered build will wait for the other builds to finish but those cannot be started as long as one build is running...

LesCodeables commented 7 years ago

Hi, Thanks for the reply. I understand what you are saying. as yous said, I have been using two different build agents, one for main build and other for triggered builds. The problem here is, my triggered builds have a Get Sources build task. Now, if the builds are going to be on different agents, how are they going to share the same source as they will have different workspaces? I'm in bit of a confusion there.

huserben commented 7 years ago

Hi the GetSources task will use the same shelveset when you specify those two options I mentioned above. So when we trigger the the build we will pass parameters that define which source version to use, so it doesn't matter on which agent you run it.

huserben commented 7 years ago

Hi @LesCodeables

were you able to solve your problem or do you need further assistance?

huserben commented 7 years ago

Due to inactivity I will close the issue

LesCodeables commented 7 years ago

I'm apologise for not responding. I was out for a while. I would like to know whether is it possible to use the same workspace for both parent and child build?

huserben commented 7 years ago

Hi @LesCodeables

what exactly do you mean by same workspace? The same source version or something else?

LesCodeables commented 7 years ago

Hi, By workspace I mean the same location of files on the agent. Now, I'm triggering a build definition from another build definition and I want the two definitions to use the exact same workspace on the agent. Is that possible. I'm not talking about the source version here.

huserben commented 7 years ago

Hi

ok I don't think this is possible, at least i never saw some setting for this. As well the workspace is depending on the build agent, so if the build would be triggered on another agent this cannot work.

I'm not entierly sure but I think TFS will create another mapped folder for every build definition, so I think technically it cannot use the same workspace for builds of different definitions.