bug: core pack: `core.inject_trigger`: `trigger` parameter masks `trigger` payload in rule setting

[djha-skin]

SUMMARY

The action parameter for the core.inject_trigger action is masking the trigger variable available from within the jinja in a rule.

I am trying to fire off a trigger from a rule using core.inject_trigger, and I want to pass along some of the information from the webhook trigger payload (which matches the rule) into the new trigger which I am creating. This doesn't work, because when I use, e.g. {{ trigger.<thing> }} within a rule, the trigger jinja variable seems to be masked by the trigger parameter in the core.inject_trigger rule.

ISSUE TYPE

Bug Report

STACKSTORM VERSION

Paste the output of st2 --version:

st2 2.10.4, on Python 2.7.5

OS / ENVIRONMENT / INSTALL METHOD

Reproduced on basic one-server install

STEPS TO REPRODUCE

1. Create a rules file named whatever you want, and have it look like this:

---
name: "pass-along-trigger"
pack: "mypack"
description: "Process webhook POST that comes in."
enabled: true

trigger:
  type: "core.st2.webhook"
  parameters:
    url: "process-webhook"

criteria: {}

action:
  ref: "core.inject_trigger"
  parameters:
    trigger: "mypack.clean_trigger"
    payload:
      thing1: {{ trigger.thing1 | regex_replace("cleanthings", "up") }}
      thing2: {{ trigger.thing2 | regex_replace("cleanthings", "more") }}
  trace_tag: "cool-i-can-set-a-trace-tag-based-on-{{ trigger.webhook-content-stuff }}"

Now just register the rule and run it with st2-rule-tester.

EXPECTED RESULTS

I expect the stuff from the payload of the webhook trigger instance for process-webhook webhook to be available in the jinja of the rule.

ACTUAL RESULTS

Instead, when I use trigger in the jinja above stackstorm insists that the value of the jinja trigger variable is "mypack.clean_trigger", which is the value of the trigger action parameter.

The action parameter for the core.inject_trigger action is masking the trigger variable available from within the jinja in a rule.

Suggested Fix

It would work, I think, to add an additional parameter to core.inject_trigger named trigger_name, which does the same thing as specifying something for the trigger parameter. Also, the trigger parameter for that action would not be removed, only deprecated, and only one of the two parameters would be required to be specified. That way, no old rules in the community are broken, but new rules can be created which allow this functionality.

[Kami]

Thanks for reporting this and including possible solutions.

I will look into it this week.

[mjtice]

Any thoughts on this? We're getting ready to upgrade to 3.5 and I was hoping I wouldn't have to keep pulling down our custom inject_trigger action.

[arm4b]

@mjtice We're accepting Pull Requests, if you'd like to take a deeper look and fix this issue. That would be very welcome!