This fixes the limitation I mentioned this morning in the standup, that @sambarluc and myself discovered in a test pipeline with the previous release candidate.
Before this change, if on a specific put the user wanted to send a notification
message, for example:
He would be forced to actually make the pipeline spammy by adding state
success to source.chat_notify_on_states.
To solve this, we had two options:
Add put.params.chat_notify_on_states, but this would look ugly:
- put: cogito
inputs: [repo.git, app]
params:
state: success
chat_notify_on_states: [success] <== well it is obvious, no?
chat_message: "Perftracker registration of X"
Understand what the user wants: it is obvious that at least one of
chat_message or chat_message_file is set, then the user wants to send the chat
message in this specific put. Note the specific == NON in a job on_xxx handler.
This fixes the limitation I mentioned this morning in the standup, that @sambarluc and myself discovered in a test pipeline with the previous release candidate.
Before this change, if on a specific put the user wanted to send a notification message, for example:
He would be forced to actually make the pipeline spammy by adding state
success
tosource.chat_notify_on_states
.To solve this, we had two options:
put.params.chat_notify_on_states
, but this would look ugly:In this PR we implement with option 2.