Azure Devops delayed Continuous Integration build - azure-devops

Question

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?

Answer 1

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:
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.