#73 added thread-ts as an output

[stevengill]

Summary

Fixes #73 by adding thread_ts as an output when using a botToken. This is useful for threading.

Requirements (place an x in each [ ])

• 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.

[seratch]

I have two things that I would like to discuss here:

1: always passing thread_ts?
What do you think about naming this thread-ts instead and making the slack-send to always return thread-ts? This means that if you run the step twice, you can easily post a message in the same thread. I cannot think of the use cases to prefer knowing message.ts instead of message.thread_ts.

The possible use case would be:

steps:
  - uses: slackapi/[email protected]
    id: slack1
    with:
      channel-id: '#general'
      slack-message: "This is the first message"
  - uses: slackapi/[email protected]
    id: slack2
    with:
      channel-id: '#general'
      payload: |
        {
          "text": "The first reply",
          // Actually this is parent message's message.ts but the following steps use it as thread_ts
          "thread_ts": "${{ steps.slack1.outputs['thread-ts'] }}" 
        }
  - uses: slackapi/[email protected]
    id: slack3
    with:
      channel-id: '#general'
      payload: |
        {
          "text": "The second reply",
          // This should be the same ts with slack1's message ts
          "thread_ts": "${{ steps.slack2.outputs['thread-ts'] }}"
        }

2: thread-ts vs thread_ts?

I know using dash as delimiter is consistent with the existing input value keys. That being said, using underscopre can be a bit similar for users. In the YAML expression, the difference would be steps.slack1.outputs['thread-ts'] vs steps.slack1.outputs.thread_ts.

[seratch]

If you return thread-ts instead, we can check if there is thread_ts first and then fall back to message.ts. Also, it may be fine to return both message-ts and thread-ts.

[stevengill]

@seratch updated this PR. Let me know

[seratch]

The changes look good to me. How about adding a following step to post a reply in thread here:

slack-github-action/.github/workflows/main.yml

Lines 16 to 33 in 2f8da78

	integration_test_botToken:
	runs-on: ubuntu-latest
	steps:
	- uses: actions/checkout@v2
	- run: npm ci && npm run build
	- name: Post message to Slack via botToken
	id: slackToken
	uses: ./
	with:
	channel-id: ${{ secrets.SLACK_CHANNEL_ID }}
	slack-message: 'CI Post from slack-send GitHub Action! Succeeded!!'
	# payload: "{\"key\":\"value\",\"foo\":\"bar\"}"
	env:
	SLACK_BOT_TOKEN: ${{ secrets.SLACK_BOT_TOKEN }}
	# Use the output from the `slackToken` step
	- name: Check Action output is not empty
	run: test -n "${{ steps.slackToken.outputs.time }}"

[lenamikaze]

Will this be merged in anytime soon?

[SnowCait]

Hi @seratch, @stevengill

What blocks this PR from merge?

[stevengill]

Sorry for they delay! I've merged this in and released version V1.19.0

[SnowCait]

@stevengill Thank you!!