Conditional parameters in metarunners

I can reproduce your situation, but I think I'm not following your use case. To me, it makes more sense to alter the conditional behavior based on build configuration parameters. If the parameter is provided by the metarunner, why would you need to run a conditional build step if the parameter equals the metarunner parameter value that you've provided? It seems like it is more useful to use a conditional build step if the build configuration parameter does not equal some value. This way, the build step runs unless you've provided the expected parameter to the build configuration; allowing you to tailor each build to your needs with the same metarunner. The metarunner parameters are used within the build step, just not for the conditional build step determination.

Take this example I based off of your metarunner:

<?xml version="1.0" encoding="UTF-8"?>
<meta-runner name="Conditional Metarunner">
  <description>Demo</description>
  <settings>
    <parameters>
      <param name="one" value="one" />
      <param name="two" value="two" />
    </parameters>
    <build-runners>
      <runner name="One" type="simpleRunner">
        <conditions>
          <equals name="one" value="one" />
        </conditions>
        <parameters>
          <param name="script.content" value="IF %one% == one ( echo True ) ELSE ( echo False )" />
          <param name="teamcity.step.mode" value="default" />
          <param name="use.custom.script" value="true" />
        </parameters>
      </runner>
      <runner name="Two" type="simpleRunner">
        <conditions>
          <does-not-equal name="two" value="two" />
        </conditions>
        <parameters>
          <param name="script.content" value="IF %two% == two ( echo True ) ELSE ( echo False )" />
          <param name="teamcity.step.mode" value="default" />
          <param name="use.custom.script" value="true" />
        </parameters>
      </runner>
    </build-runners>
    <requirements>
      <equals id="RQ_6" name="env.OS" value="Windows_NT" />
    </requirements>
  </settings>
</meta-runner>

The first runner will run if the build configuration parameter of %one% is equal to one. If I do not set the build configuration parameter %one% = one, the step is skipped. This is what you're reporting and I think this works as intended. This results in the following entry in the build log:

[Step 1/2] Build step Command Line is skipped because of unfulfilled condition: "one equals one"

However, the second runner will run because the build configuration parameter %two% has not been set and %two% does not equal two. This results in the following build log entry:

[Step 2/2] True

If I then run a custom build and provide a build configuration parameter of %one% = one and %two% = two, I end up with the opposite results because I am testing the parameters of the build configuration instead of the metarunner. 

[Step 1/2] True

[Step 2/2] Build step Command Line is skipped because of unfulfilled condition: "two does not equal two"

Thanks for the detailed response.

My example was highly simplified to demonstrate the lack of scope on the conditions, but perhaps it might help if I at least describe what I am trying to achieve. I might be going about it wrong, so please correct me if I have missed something.

Essentially, what I have is a metarunner that does a few steps at once using Net Core steps. As such I have set that metarunner up to take framework and runtime as parameters. Let's call this metarunner "A".

We build packages of multiple projects onto 2 runtimes, win-x64 and linux-x64. As such, I would ordinarily need to run my "A" metarunner twice for every project. One with `win-x64` runtime set and the other with `linux-64` set. Most packages build both runtimes, one builds only `win-x64` and eventually they may slowly switch to `linux-x64` only.

I had the idea of building a parent metarunner that might allow me to select none, one, or both runtimes for each build step / project. Let's call this metarunner "B"

So instead of having 2 metarunner "A" build steps, "Project.Api (win-x64)" and "Project.Api (linux-x64)" I would have a single metarunner "B" build step for "Project.Api".

In this metarunner "B" I was trying to use a multi-select parameter called "runtime" and then using the "contains" conditions in the steps to choose when to call metarunner "A" and with what value.

<?xml version="1.0" encoding="UTF-8"?>
<meta-runner name="Conditional Metarunner">
  <description>Demo</description>
  <settings>
    <parameters>
      <param name="runtime" value="win-x64,linux-x64" spec="select multiple='true' data_1='win-x64' data_2='linux-x64'" />
    </parameters>
    <build-runners>
      <runner name="Build win-x64" type="MetarunnerA">
        <conditions>
          <contains name="runtime" value="win-x64" />
        </conditions>
        <parameters>
          <param name="teamcity.step.mode" value="default" />
          <param name="runtime" value="win-x64" />
        </parameters>
      </runner>
      <runner name="Build linux-x64" type="MetarunnerA">
        <conditions>
          <contains name="runtime" value="linux-x64" />
        </conditions>
        <parameters>
          <param name="teamcity.step.mode" value="default" />
          <param name="runtime" value="linux-x64" />
        </parameters>
      </runner>
    </build-runners>
  </settings>
</meta-runner>

This would allow me to have build steps in which I could individually choose on a per-step/project basis which runtimes were going to be built. I would have a single config that builds my suite of apps (as we generally have multiple projects making the suite and it all builds together in a single CI build project)

If these conditions parameters were in the build config it would apply across all steps all the time.

I may be massively overthinking this, or there may be something simple I have missed. Hopefully this gives you a little more insight into what I want to do.

Thanks,

Mike

I'm still not sure how this improves your workflow. As written, if TeamCity used the metarunner parameter for the conditional test, this would run both runners every time. If you're setting the metarunner parameter %runtime% are you then also using a build configuration parameter %runtime%, or how are you planning to customize the parameter for each step/project?

Have you looked into Build Configuration Templates? https://www.jetbrains.com/help/teamcity/build-configuration-template.html#Overview

Build configuration templates allow you to eliminate duplication of build configuration settings. If you want to have several similar (not necessarily identical) build configurations and be able to modify their common settings in one place without having to edit each configuration, create a build configuration template with those settings. Modifying template settings affects all build configurations associated with this template.

Couple years late to the party, but echo same confusion and expectations ... if parameter is defined in the meta-runner, it's a reasonable expectation that the condition would be taken from there, not the wrapping build configuration.

Since there's an ability to nest meta-runners, also in the same boat of assuming conditions would work the same. It's not conducive to stack templates into configuration when meta-runner can do it more elegantly .. well, except for the condition part :-(

To re-iterate - if MetaRunners are indeed intended to mimic other runners, it'd be like setting all Python runner info on build config.

One way we've circumvented this is adding an additional step to the wrapper meta-runner to take certain values and set with "##teamcity[setParameter" to set back to build-config