groovy:
def confA = system.configurationManager.get("path/to/confA");
def promotion = confA.findPromotion("promotionToPromoteConfAToConfB");
promotion = system.scriptEngine.installInterpolator(promotion);
promotion.promote(confA.latestBuild, [customVar1:value1, customVar2: value2]);

I want to have a configuration trigger a promotion from a different configuration. I note this answer is somewhat old. Is this still the best approach?

While I have confirmed this still works it's not exactly what I was hoping for. The situation is similar, I am promoting A to B and during the run of B want to trigger a promotion of C to D. Unfortunately, the C to D promotion has the target configuration defined as SomePath/${configuration.getParent().Name}. So ${configuration.getParent().Name} becomes the parent of B and not C as it would be if a user initiated the promotion. I tried setting the target to SomePath/${vars.getValue('SomeVar')} and then triggering with promotion.promote(confA.latestBuild, ['SomeVar':ValFromC]) but ${vars.getValue('SomeVar') is the value from A/B and not ValFromC.

I think I was able to get the behavior I want with
promotion.setConfigurationPath('SomePath/ValFromC')

If this isn't the cleanest way to do all this, let me know.

As a continuation of this, how can I have the configuration run of B wait until C to D is complete and then get the status and fail if the triggered promotion fails?

To make the script "${configuration.getParent().Name}" working for confC, you may also wrap your code with context push and pop like below:

import com.pmease.quickbuild.Context;

Context.push(confC)
try {
...
} finally {
  Context.pop();
}

As to waiting for finish of promotion from C->D, there is no easy way to do that. You may consider to periodically poll latest build of D periodically to see if the promotedFrom property is the same as the original build, and check its build status.

Thanks. But I still feel like this is harder than it should be. Here's the use case. Consider we have two products A and B that get built though CI. Sometimes developers want to promote them to the development environment so we have a promotion defined for each which deploys them. A -> Dev and B -> Dev. But sometimes you want to deploy both so you want C -> Dev to run both of the other promotions. When this happens you still want to see that the target environment configurations for A and B were run which is hard to do using dependencies since then you only see the update of C. If the above solution is currently the best way to do this in QuickBuild I will finish implementing it but I suggest you add easier to use functionality in a future release.

The context isn't working for some reason. I am trying to promote from
ConstructConnect/Builds/SearchAPI/develop
to
ConstructConnect/Environments/DevOps/${configuration.getParent().Name}
which should be
ConstructConnect/Environments/DevOps/SearchAPI

But it errs with:
Promote Component (context)?COMPONENT=SearchAPI' is failed: Can not find promotion destination 'ConstructConnect/Environments/DevOps/develop'

I tested with a simple set up and the context push works at my side. Have you pushed the configuration "ConstructConnect/Builds/SearchAPI/develop"? As to your use case, I think the best approach is to use the dependency mechanism:

1. DevA depends on A via QuickBuild repository to retrieve necessary artifacts of product A and deploy into development environment
2. DevB works for product B the same way as A
3. DevC depends on DevA and DevB

When you want to deploy A or B separately, just run either DevA or DevB. When you want to deploy both A and B, just run DevC

I added some logging and this is what I got:

08:53:36,404 INFO - Pushing configuration: ConstructConnect/Builds/SearchAPI/develop
08:53:36,410 INFO - Target configuration path: ConstructConnect/Environments/DevOps/${configuration.getParent().Name}
08:53:36,476 INFO - Executing post-execute action...
08:53:36,476 ERROR - Step 'master>Promote Components>Promote Component (context)?COMPONENT=SearchAPI' is failed: Can not find promotion destination 'ConstructConnect/Environments/DevOps/develop'.

The parent should be SearchAPI and not develop.

I am trying to implement this using dependencies but am having trouble parameterizing it. I want the user to be able to select which pieces he wants to deploy so I have a prompted multi-select variable (Deploy_components). Then I do the checkout against the repo using a parameter (COMPONENT=${vars.getValue('Deploy_components')}). The repo defines the QuickBuild configuration as top/Environments/${params.get('COMPONENT')} but this always fails before the run starts when QuickBuild tries to resolve just top/Environments for which there are no builds.

tardis4500

I added some logging and this is what I got:

08:53:36,404 INFO - Pushing configuration: ConstructConnect/Builds/SearchAPI/develop
08:53:36,410 INFO - Target configuration path: ConstructConnect/Environments/DevOps/${configuration.getParent().Name}
08:53:36,476 INFO - Executing post-execute action...
08:53:36,476 ERROR - Step 'master>Promote Components>Promote Component (context)?COMPONENT=SearchAPI' is failed: Can not find promotion destination 'ConstructConnect/Environments/DevOps/develop'.

The parent should be SearchAPI and not develop.

Yes it should be SearchAPI and it does work so at my side. Can you please reproduce your issue with a sample database and send to me for diagnostics?

tardis4500

I am trying to implement this using dependencies but am having trouble parameterizing it. I want the user to be able to select which pieces he wants to deploy so I have a prompted multi-select variable (Deploy_components). Then I do the checkout against the repo using a parameter (COMPONENT=${vars.getValue('Deploy_components')}). The repo defines the QuickBuild configuration as top/Environments/${params.get('COMPONENT')} but this always fails before the run starts when QuickBuild tries to resolve just top/Environments for which there are no builds.

Parameter should not be used here as its value is only available when the step runs. However by default repositories need to check changes at start of build. This is the reason why the parameter gets evaluated to empty.
To work around the issue, specify the configuration paths field in QuickBuild repository to evaluate below script:

groovy:
configurationPaths = "";
for (component in com.pmease.quickbuild.util.StringUtils.splitAndTrim(vars.getValue("Deploy_components")) {
  configurationPaths += "top/Environments/" + component + ",";
}
return configurationPaths;