Notify slack via shell script/api curl

[vdice]

Due to various issues (mostly mentioned in #192), we cannot use our version of the Slack Plugin if we wish to dispatch to multiple slack channels and keep this repo public. As we place high priority on keeping this repo public, for our simple needs of notifying appropriate channels with information from job results, we propose at this time to build our own logic that we can use for this purpose and avoid the use of the Slack plugin altogether.

At a high level, this logic should be simple-as-possible and consist of, minimally, one script that curls slack’s inbound webhook api to send a given message to a given slack channel. Confidential Slack tokens could be added to each repo in repo.groovy in the form of channel -> credentials id of auth token.

Once this logic exists in bash/scripts, any of our jobs would then be able to run the following (pseudo-code) from a shell step:

if <all good>; then 
  msg=<success msg>
else
  msg=<failure msg>
fi
slack-notify <component channel> <msg>

The work items of this ticket would then be:

1. the creation of the aforementioned logic, covering in minimal test
2. PoC use of aforementioned tool in a Jenkins job
3. If success, creation of appropriate ticket(s) to migrate jobs toward the use of this approach.

[sgoings]

Why do we need a docker container to do this work if we're injecting secrets via Jenkins secrets + just curling slack's API? Just to handle the mapping?

[vdice]

@sgoings great question -- indeed, it isn't crucial to encapsulate the logic as you mentioned in the form of a docker container.

For an MVP of getting us off the slack notification plugin, we could just build this in the form of a bash script, just like the rest here in bash/scripts (plus get it under test) and add the necessary credentials binding value to each repo in the repos map in repo.groovy and we'd be then be able to invoke said functionality when needed, supplying the appropriate channel/msg args.

If the above sounds like a good/better idea, I can re-word this ticket or create a new issue for this and potentially close this. Thoughts?

[sgoings]

I'd definitely start with the simplest possible solution that could possibly work. No need to get all Docker-fancy before you need to.

[vdice]

@sgoings will do! I remember now that the reason for container-izing this logic was for use by multiple parties -- here in the job DSL and in any Jenkinsfiles. That being said, we can certainly create the ticket for container-izing this logic once it is proven and working!

I'll edit this ticket as discussed above.