Feature Request: Allow sending multiple messages at once

[oilers]

Description

We generate workflow summaries from GHA and format each job as a Block, then post them to a notification channel for job status notifications. Recently, we encountered an issue where some workflows had more than 50 jobs. This exceeds the maximum number of blocks we can post at once. That is reasonable, and our solution is to generate multiple messages and post them in a thread. We do not always know how many messages we must submit since the summary is performed in a shared workflow. In order to do this I am left with 3 bad options:

1. Send each message as part of a matrix job; this means each message consumes a self-hosted ARC runner, which seems excessive
2. Fork the action ourselves and add support
3. Do not use the action and fall back to making API calls ourselves

It would be great if there were some way of passing in multiple messages.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• example code related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• I've read and understood the Contributing guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.
• I've searched for any related issues and avoided creating a duplicate issue.

[vegeris]

Hi there,

Could you clarify what you mean by send multiple messages at once? If I understand correctly, you're running a workflow that creates a dynamic number of jobs and want to send data about each job to Slack via Slack API calls; sometimes the # of jobs means too many blocks to send in a single Slack message and you want to make additional calls to chat.PostMessage without adding additional job steps?

One thing that comes to mind is that your workflow could create the first Slack message and every subsequent job could send its block as a separate message in thread

[oilers]

In general: A workflow is run, this is defined according to the repo, but will include a "notification" job with an if: always() section that depends on every other job in the workflow. This job is a reference to a shared slack notification workflow. That workflow then reads the job info and posts the status to appropriate channels with what passed, failed, skipped, canceled, etc.

Your suggestion is to add a notification job after each job in the workflow? What if that job ends up with more than 50 statuses, like in the case of a shared workflow that contains a matrix over a large monorepo.

[zimeg]

👋 This is a super interesting use case! Could you share more about how you're formatting the blocks that are being sent?

I agree that none of those alternatives seem ideal, but I'm thinking that making direct API calls might be easiest with an unpredictable amount of messages needing to be sent. I'm hoping that this wouldn't be much additional logic if some coded logic to format the blocks exists somewhere else.

Sending multiple messages (or API calls) with different payloads from a single step is interesting in general and I'm curious if you have a suggestion for how this might be supported as input to this GitHub Action?

These are sizable workflows you're running that we might not have considered in recent iterations, which makes all of these details super interesting! Thanks for sharing these and the suggestion 🙏

[oilers]

Sure thing, so we retrieve the GHA job statuses, parse them to determine overall success, failure, or other, turn that into a block, then use a separator block, map all the jobs into blocks, add another separator block, then add a summary block to the end. We also support one or more user-defined blocks to append to the end of the message, although I don't believe that particular functionality is used often.

As for how I was seeing it work, I hadn't fully thought it through, but updating the payload and/or the payload file param to support parsing an array of values was my initial thought.

FWIW, we were suprised ourselves when we got a bug report about incorrect slack messages, it was unexpected that a single workflow would have so many jobs. I tend to agree that the slack API is the most likely solution we will be pursuing for now.