1

I currently have an Azure Devops install that I am configuring for automated build and testing. I would like to enable a Continuous Integration trigger for the build process, however our check-in standards require different parts of our code to be checked in separate from each other.

For example: we are using nettiers auto generated code, so whenever a ticket requires a database change, the nettiers code base gets updated. Because that is auto generated code it gets checked in separately from manual modifications with a comment indicating that it is an auto generated check-in.

A build will fail if it does not have both the nettiers and the manual modifications checked in. However with Continuous Integration turned on, the first check-in will trigger a build to begin that will be missing the second half of the changes which are checked in a couple minutes later.

The ideal way I would like to fix this would be to implement a 5 minute delay between when the CI build first gets triggered, and when it actually begins its work. Even better would be if each successive check-in would cancel the first build and start a new timer with its own build to account for any subsequent check-ins.

An alternative was to solve the issue might be to have a gate on a work item query. However, I have been unsuccessful in figuring out how to implement either of these ideas, or in coming up with other options. Gates based on queries only seem to be available in Release pipelines, not Builds.

Has anyone out there solved a similar problem, or have thoughts on how to solve or work around this issue?

Jereme
  • 630
  • 6
  • 18

1 Answers1

0

Azure Devops delayed Continuous Integration build

I am afraid there is no such out of box setting/method to set this specify continuous integration build for your case.

As workaround, we could generated code and gets checked in to some specify folder by using nettiers, like \NettiersGenerated.

Then we could exclude that folder by the Path filters under the Enable continuous integration:

enter image description here

In this case, the generated code will not trigger the build pipeline.

Update:

It would require that the nettiers code always gets checked in first (which would be hard to enforce)

Yes, agree with you. If the build will fail if it does not have both the nettiers and the manual modifications checked in, my first is indeed not reasonable enough.

As another workaround, we could use the Azure DevOps counter and get the rest of the counter through a powershell script, build the pipeline only if the number is even, otherwise cancel the build, like:

Counter expression like

variables:
  internalBuildNumber: 1
  semanticBuildNumber: $[counter(variables['internalBuildNumber'], 0)]

Powershell scripts:

$value=$(semanticBuildNumber)
switch($value)
  {
    {($_ % 2) -ne 0} {"Go on build pipeline"}
    {($_ % 2) -eq 0}
      {
         Write-Host "##vso[task.setvariable variable=agent.jobstatus;]canceled"
         Write-Host "##vso[task.complete result=Canceled;]DONE"
      }
  }

In this case, the pipeline will be build when it triggered at second time.

Hope this helps.

Leo Liu
  • 71,098
  • 10
  • 114
  • 135
  • 1
    So far I think your suggestion is the best alternative I have found. But I don't think it is quite flexible enough in my situation. It would require that the nettiers code always gets checked in first (which would be hard to enforce). – Jereme Feb 27 '20 at 15:06
  • Hopefully Microsoft gives us some flexibility in this area eventually, but Azure DevOps is one of the slowest moving products in terms of feature improvement that I have used over the years from Microsoft, so we are going our best to migrate away from it where possible. – Jereme Feb 27 '20 at 15:07
  • @JeremeGuenther, I agree with you. I have updated another workaround in my answer to resolve this issue, would you please check if it help you? – Leo Liu Mar 02 '20 at 08:49
  • Using powershell sounds powerful, I see this post on the general concept: https://stackoverflow.com/questions/55461216/powershell-to-trigger-a-build-in-azure-devops It's not as clean as using the built-in options. But could I create a powershell script that queried devops every couple minutes and triggered a build when the last check-in for a given path was at least 5 minutes old, but newer than the last build? – Jereme Mar 02 '20 at 16:35
  • @JeremeGuenther, I am afraid the answer is no. – Leo Liu Mar 03 '20 at 02:26