what if this is not something like "c3i_promote_dev_to_stage"? If I put another string there, I would get a traceback...

@gnaponie Ehhh, we need to have a general way to know the promotion destination from the Greenwave message. Do you have any suggestion?

Also CC @mikeb

Mmm I guess it is fine. Just... if an error happens, I guess that will mean that the decision_context was changed...
Anyhow the change looks fine to me. But please, wait for another review. Maybe from Mike.

+0.5 :)

@rayson Would it make sense to pass decision_context, source_tag, and target_tag from the yaml template to the Jenkinsfile as parameters, and then use those to setup the trigger and call the promotion job?

Would it make sense to pass decision_context, source_tag, and target_tag from the yaml template to the Jenkinsfile as parameters, and then use those to setup the trigger and call the promotion job?

@mikeb Passing decision_context seems a good idea to me. Regarding to source_tag and target_tag, currently we run different Jenkins jobs for dev->stage and stage->prod promotions for visibility. Do you think it is a good idea to use just one job?

@rayson No, I think it makes sense to use two different jobs, but they could be using the same Jenkinsfile and template, and decision_context, source_tag, and target_tag could be passed in as parameters via the .env file, similar to what you do with the other job definitions. So we'd have a:

waiverdb-greenwave-promote-to-stage.env
waiverdb-greenwave-promote-to-prod.env

with different NAME, DECISION_CONTEXT, SOURCE_TAG, and TARGET_TAG parameters.

@mikeb Done. Please do another review. Thanks.

+1 Looks good to me! Merging.