Empty parameter passing to a build

[alexkrytsky]

Is there a way to pass an empty parameter to a Trigger Build Task? the required format is key:val, key2:val2. Any possible way to make it something like key: , key2:val2 and in the triggered build, it would be just an empty parameter?

Right now just doing this and overriding some default values this way:

variables:
  - name: MULTILINE_PARAM
    value: |
      PARAM1:somevar,
      PARAM2:secondparam,
      PATH:'',
      EMPTYPARAM:''
  - name: CUSTOM_PARAMS
    value: |
      PARAM1:overridevalue,
      PATH:\some\custom\path\here

steps:
  - template: templates/trigger_pipeline.yaml
    parameters:
      PIPELINE_PARAMS: "$(MULTILINE_PARAM),$(CUSTOM_PARAMS)"

In the trigger_pipeline.yaml I'm using the task and passing PIPELINE_PARAMS in buildParameters. But I need EMPTYPARAM to remain empty when triggering a build.

[huserben]

Hi @alexkrytsky

so is the default value of the variable different than empty? Otherwise you could just not specify it and it would take the default (empty) variable.

Otherwise you can try it in the proposed form key: , key2:val2 - I couldn't try it myself yet but it could work. Another option could be to put key: "", key2:val2 and see what happens then.

The last option could always be to have some small script in the target build that "transforms" a given value (like EMPTY) into an actual empty value (it's a workaround but I think it should work quite well if the above ways don't work)

Please let me know if you could figure it out or whether you need additional help.

[alexkrytsky]

Hi @huserben , The default value might be empty or some value so I need to support both values.

I was thinking about the last option as a workaround in the target build has a parser at the very beginning of the build.

I tried key: , key2:val2 and it actually just worked! I just needed a space there and your parser took it as a value. Thank you!

---

One more question that I have related to the "Cancel Triggered Build" task. Not sure if I should I open a new issue or how to reach out to you. My workflow goes as follows:

1. Trigger N builds
2. Wait for: completion or a new automatic trigger of this build
3. If we trigger another instance of this build prior to all of the triggered builds finish, I need to cancel all previous ones.

Do you have something similar implemented or any idea how to implement it in the easiest way?

[huserben]

Hi again

ok very good to know and I'm glad it worked out for you (can't say that this was intentional :-))

For your second question: In general don't worry and feel free to open new issues for different questions/requests.

Just to rephrase your question so I can be assured I got it right: You have Build A that triggers a number of Builds (let's call them X, Y and Z). Then as part of "A" you want to wait for completion of X, Y and Z. Now for some reason you queue up another Build of A and you want to cancel ongoing builds of X, Y and Z because this instance of the build will queue them anyways again?

If so, the cancel build task currently works against a variable called TriggeredBuildIds, it will attempt to cancel all the builds with the id specified in this variable. If you want to execute it at the very beginning of a build you could somehow fetch the id's of currently running builds and store it in this variable and then "normally" run the cancel build task.

Additionally I think the Cancel Build Task could be enhanced to have an option to specify build definition names that shall be cancelled, but currently I'm not working actively on the Tasks so it might take a while till this feature is available.

Please let me know if this helped and/or you need more information. I could also assist in case you would need help to write some script.

[alexkrytsky]

Hi @huserben,

I hope that unintentional feature will remain there in place! It helps quite a bit! Also, don't know if that's intentional or not, you allow duplicated variables to be passed in the build and the latest variable that was added will take precedence. I hope it's a feature and it will remain there! Also really helpful!

You did understand my question correctly. Unfortunately, I wasn't able to use those extensions due to a simple missing feature. If you can fix it that would be great! Your trigger build task creates environment variable TriggeredBuildIds and it supposes to persist ID of kicked off builds with comma separated format. That works well BUT, I'm using multiple jobs to trigger multiple builds (X, Y, and Z). In that case, that variable(TriggeredBuildIds) doesn't persist its value hence CancelBuild task won't be able to monitor those builds. The reason why I'm using multiple jobs to trigger builds is that I'm using a parallel strategy to trigger a few builds of X with identical configurations.

Possible fixes for it? :) I might have to write a script to use their API to cancel all builds. Don't have a clear idea on how to structure that though. Thoughts?

[huserben]

Hi

Instead of having a script to cancel you could still use the task, but just having a script that would somehow fetch the ID's of the currently running builds. The script could get those id's and just store it in the variable so the Cancel Task would pick it up.

In order to fetch currently running builds you can use the REST API as described here: https://docs.microsoft.com/en-us/rest/api/azure/devops/build/builds/list?view=azure-devops-rest-5.1

You will need to know the id's of the build definitions (X, Y and Z). For this example I just took [1, 2, 3] - this of course has to be replaced by the actual id's.

This request should give you the currently running builds of those build definitions: _GET https://dev.azure.com/{organization}/{project}/_apis/build/builds?definitions=1,2,3&statusFilter=inProgress&api-version=5.1_

From the response you should be able to find out the respective build id's. Then just store them in the variable TriggeredBuildIds as comma separated values.

[alexkrytsky]

Hi That's a really good idea! I'll do that! Thank you for your assistance with this! Thanks for these nice extensions! Great job!! I think we can close the issue now 😊

[huserben]

Hi

I'm glad I could help. Thanks for reporting the problem and please don't hesitate to open up new issues in case you have questions or find a bug or are in need of an addition feature.