Produce output file containing response from Slack API

[fenech]

Hi, I'm using this resource to print messages to a Slack channel, but the messages can be very long, and I'd like to be able to post a summary as a main message, followed by the longer details in a reply thread.

To do that, I would need the ts in the response from Slack, and include it as the thread_ts parameter in the follow-up message.

I can think of a few ways to do this:

1. roll everything into one put step, with extra parameters to specify the thread contents
2. use a put step to post the first message, then a custom task to post the remainder
3. use two consecutive puts, and add a parameter to specify the thread_ts

I think that #1 could introduce quite a lot of extra complexity in the resource, so I think #2 or #3 would be the preferred approach. However, in order to do that, the put step would need to produce some output that could be used in subsequent steps.

At the moment the resource outputs a timestamp which is the output of date, but perhaps this timestamp could instead be the ts from the result (if available)? Then the implicit get step after the put could be used to write some output files for use in later steps.

Happy to try and make a PR with some changes if we agree on an approach 😄

[fenech]

I was confusing the chat.postMessage API with the webhooks API used by this resource. The latter only returns an HTTP 200 with body "ok" so none of the information I was hoping to use is available. So I guess that this would be a much bigger rewrite than I thought.

[bgandon]

Given you need (have a concept of summary and detailed message), your solution number 1 matches the philosophy with Concourse: you have something to send, you use a “dummy” resource (with no concept of “version”) to put it there. In your case, we could imagine new parameters like summary, summary_file, full_text, and full_text_file.

But the non easy thing is to make it clear about the rules for treating the parameters. In the current state, the code already tends to get clumsy about this, and is already not so easy to maintain. (I remember reverting a big cleanup refactoring that was actually breaking when running the tests.)

So in the end, this resources is meant to keep things simple, really. We'd better not go into such fancy things like threads. I don't say it's impossible. And I'll test , try and advise on any code you would submit.