Error: Could not queue the build #138
Comments
krispenner
changed the title
|
Hi @krispenner This error seems to come from Azure DevOps itself -what you can try to do is to set the system.debug variable of the build to true and see whether we would get more information. If that still doesn't work, you could try to comment out the build parameters to check whether it works then. If so there is probably something off with the format (I don't see anything right away, but it's usually the culprit :-)) Edit: I think the build parameters should be enclosed in ': |
|
Hi @huserben, thank you for your reply. If you see my earlier comment please disregard, it was incorrect and so I have deleted it to avoid confusion. The issue appears to be that only Variables can be passed and not Runtime Parameters. Can you confirm that statement? The documentation is a bit misleading in that case since you use the words variables and parameters interchangeably and they are two different things in pipelines - granted runtime parameters were only added in late 2019. I had defined runtime parameters on my builds and these are not being set. But if I remove the parameters and use variables instead it works. Maybe this triggerBuild task does support passing runtime parameters and you can point me to how to do that? Using runtime parameters provides a much better experience for manual UI driven build triggers which my target pipeline also needs to support. In the meantime I'm going to look into how I can use both runtime parameters and variables; potentially a script task could check if a variable value was provided and if so use it's value otherwise use the runtime parameter value. |
|
FYI, I was able to get the trigger passed variables to work and if not specified due to manual start then fallback to the runtime parameters. Still curious if runtime parameters should be supported and I'm missing something? Triggering build: buildParameters: triggerApi:$(api),triggerEnv:$(env)Triggered build parameters:
- name: api
displayName: API
type: string
default: api1
values:
- api1
- api2
- name: env
displayName: Environment
type: string
default: DEV
values:
- DEV
- QA
- PROD
variables:
paramApi: ${{ parameters.api }}
paramEnv: ${{ parameters.env }}
api: $[ coalesce(variables.triggerApi, variables.paramApi) ]
env: $[ coalesce(variables.triggerEnv, variables.paramEnv) ] |
|
Hi @krispenner sorry for the late reply. Nice that you figured it out, thanks for putting the effort into investigating the problem. As you mentioned they are rather new and before there were "only" the variables. I checked very quickly about the runtime parameters and saw that there seems to be in general a way of doing it: However I would need to check if the api is even supporting it at the moment. So for now the plan would be to mention the lack of support for runtime parameters, I hope that's ok, as you got a workaround for your problem at the moment. |
|
@huserben that all sounds great! Yes I have it working perfectly now. If I ever see you update this to support runtime parameters then I will look to update my side as well and remove the extra bit I added to work around this. Thank you so much for all your help and amazing task! I'll close this issue as the error I had was resolved. Also a bit of background on parameters, I believe they were added as Template Parameters initially and only used when passing parameters from one pipeline to a YAML template. So the name Template Parameters came from that. Then more recently they added support to provide these same parameters at queue time of a pipeline but called these ones Runtime Parameters although they are the same thing really the name determines where you are specifying them. For this reason I think the REST API you use just re-uses the original templateParameters property as you found out. {
"stagesToSkip": [],
"resources": {
"repositories": {
"self": {
"refName": "refs/heads/master"
}
}
},
"templateParameters": {
"testParam": "hello world"
},
"variables": {}
}from the link you shared |
|
I came across this answer in a search for fixing a problem I thought was coming from how I was sending parameters from one pipeline job to another from the Azure CLI (using the Azure DevOps CLI extension). At first, the documentation I found on Then, continuing my search, I came across this GitHub feature request where they mention adding the Hopefully this helps anyone who is confused about conditionally launching pipelines from other pipelines. I meant to blog about this last night too but got sidetracked; I'll hopefully publish it next week, and meanwhile have Microsoft reconcile their documentation. |
|
@mrcity Looking forward to reading your post. Feel free to leave a link here. It might help others that stumble over this problem. |
|
@huserben Here's the link! https://goshtastic.blogspot.com/2023/02/start-azure-pipeline-from-another.html There could be enough here for a conference talk 😛 |
|
Hey guys! I'm getting the same error on a build that was working this morning and stopped working for some reason: jobs:
- job: "TriggerKbPipeline"
condition:
variables:
AgentString: $[stageDependencies.CreatePrimeVersion.CreatePrimeVersionJob.outputs['AVersion1.AgentVersion']]
AgentString2: $[stageDependencies.CreatePrimeVersion.CreatePrimeVersionJob.outputs['AVersion2.AgentVersion']]
pool:
vmImage: ubuntu-latest
steps:
- task: TriggerBuild@4
condition: or(eq('${{ parameters['AgentVersion'] }}', ''), eq('${{ parameters['AgentVersion'] }}', 'latest'))
inputs:
definitionIsInCurrentTeamProject: true
buildDefinition: 'KB'
queueBuildForUserThatTriggeredBuild: true
ignoreSslCertificateErrors: false
useSameSourceVersion: false
useCustomSourceVersion: false
useSameBranch: false
branchToUse: $(branchName)
waitForQueuedBuildsToFinish: true
waitForQueuedBuildsToFinishRefreshTime: '10'
failTaskIfBuildsNotSuccessful: true
cancelBuildsIfAnyFails: false
treatPartiallySucceededBuildAsSuccessful: false
downloadBuildArtifacts: false
storeInEnvironmentVariable: false
authenticationMethod: 'OAuth Token'
password: $(System.AccessToken)
enableBuildInQueueCondition: false
dependentOnSuccessfulBuildCondition: false
dependentOnFailedBuildCondition: false
checkbuildsoncurrentbranch: false
failTaskIfConditionsAreNotFulfilled: false
buildParameters: "GitSemVer: $(StagesSemVer), AgentVersion: $(AgentString)"
- task: TriggerBuild@4
condition: and(ne('${{ parameters['AgentVersion'] }}', ''), ne('${{ parameters['AgentVersion'] }}', 'latest'))
inputs:
definitionIsInCurrentTeamProject: true
buildDefinition: 'KB'
queueBuildForUserThatTriggeredBuild: true
ignoreSslCertificateErrors: false
useSameSourceVersion: false
useCustomSourceVersion: false
useSameBranch: false
branchToUse: $(branchName)
waitForQueuedBuildsToFinish: true
waitForQueuedBuildsToFinishRefreshTime: '10'
failTaskIfBuildsNotSuccessful: true
cancelBuildsIfAnyFails: false
treatPartiallySucceededBuildAsSuccessful: false
downloadBuildArtifacts: false
storeInEnvironmentVariable: false
authenticationMethod: 'OAuth Token'
password: $(System.AccessToken)
enableBuildInQueueCondition: false
dependentOnSuccessfulBuildCondition: false
dependentOnFailedBuildCondition: false
checkbuildsoncurrentbranch: false
failTaskIfConditionsAreNotFulfilled: false
buildParameters: "GitSemVer: $(StagesSemVer), AgentVersion: $(AgentString2)" |
|
Hello Guy's this extension is not working when we are running it from a particuler branch below is the configuration(except when we are merging) and error is given below: Call to the template which contain TriggerBuild@4 task: Debug log: NB: Some of the values like called-project and Trigger-build has been replaced with dummey name! |
|
Hi @dasbiswajit can you try to trigger it for your main/master branch and see if this is working? Is the pipeline that is triggered working against the same git repository, so the specific branch ("refs/heads/release/1.xx.xx") is available for this pipeline? What happens if you try to manually trigger this pipeline for that specific branch? |
|
Hello @huserben with merging to master it is working. while running on release/1.x.x it is not working. |
|
@dasbiswajit In case this is true and you are using a different repo for the triggered pipeline, my next assumption would be that in this repo you lack the branch name ("release/1.xx.xx") and this is why it can't trigger the pipeline. Would you be so kind and let me know if the above is correct? |
|
@huserben OK. yes- These are two different pipelines. Unfortunately the called pipeline does not have the same branch ("release/1.xx.xx") as the caller pipeline. Rathert it has master branch. Is there any way we can pass the branch name? |
|
@huserben can you please update us? this is blocking our Deployment. |
|
Hi @dasbiswajit Ok if you don't have the same branch, you can't have "useSameBranch" set
You can also leave it empty and then it will trigger the pipeline on the default branch. See also https://github.com/huserben/TfsExtensions/blob/master/BuildTasks/overview.md#use-same-source-branch |
I'm getting the following error:
"Could not queue the build because there were validation errors or warnings."
But no more detail than that. Is there any verbose logging I can turn on that might help show what the validation errors and warnings are?
Here is my YAML task:
Here is the task output:
Thank you!
The text was updated successfully, but these errors were encountered: