Variable expansion in k8s v2 manifest file issue


We are trying to deploy a manifest using the k8s v2 provider. When we add the following into a comment section we see the result ${ trigger['registry'] }/${ trigger['repository'] }:${ trigger['tag'] } as

However, when we add this into our manifest file as - image: "${ trigger['registry'] }/${ trigger['repository'] }:${ trigger['tag'] }" we get the following error:

Exception ( Deploy Manifest )
Failure evaluating manifest expressions: {trigger[‘registry’]/trigger[‘repository’]:trigger[‘tag’]=[Result {description=‘Failed to evaluate [image] requested getter registry not found on type class’, exceptionType=class java.lang.IllegalArgumentException, timestamp=1525362786684, level=ERROR}]}

It appears this error happens whenever we try to use the ${trigger['registry']} within the manifest. We’ve tested using ${trigger['artifacts']} which works…

Any idea on what we can do to fix this?


Hi. Can you clarify what you mean by “adding … into a comment section”? Do you mean the large text field in the Deploy (Manifest) stage where you can type in the manifest contents directly (shown below)?

If so, I’m surprised that trigger['registry'], for example, resolves, as I haven’t seen registry or tag or repository in the pipeline context’s trigger object.

For a pipeline execution instance, there’s a link labeled Source in the bottom right (picture below) whereby you can look at the entire pipeline context JSON, to see how SPEL expansion should evaluate for yourself.

I’ll wait for your clarification, meanwhile continue checking for situations where the attributes you’re expecting might show up in the pipeline context.


No not the text manifest. Below is a section where you can add comments. We’ve been using that field to try out variable expansion. We are also using an “Artifact” manifest provided from GCS. I’ll take a look at the Source link and attach what I can.


I’m still not sure why the your comments are resolving correctly, but the answer should be in your execution source JSON. Can you post that or slack DM me a clean version of that?


I DM’d you on hangouts


Okay, talked with @lwander and came to an understanding of what’s happening here.

In short, using artifact injection in the v2 provider is the recommended way to go, versus using docker triggers, which work with the v1 provider and currently doesn’t map the attributes you’re looking to work with, as Lars pointed out to me.

If you have specific reasons why you prefer to this over the standard methods in v2, it’d be helpful for us to understand. We’re not aggressively backporting v2 stuff v1 and vice versa, but a tenable transition plan is important to us. Thanks.