Add endpoints for `calls.*` apis and `Type: call` in blockkit

winston-stripe commented 1 year ago

Implement the API methods for the Calls API in Slack https://api.slack.com/apis/calls

Implemented methods

calls.add - Indicate a new call has been started
calls.end - Indicate to slack that the call has ended
calls.info - Get information about an ongoing slack call object
calls.update - update call information
calls.participants.add
calls.participants.remove

Additionally, I've added the minimal version of Block{Type: "call", CallID: string} which slack recommends/requires be posted back to the channel https://api.slack.com/apis/calls#post_to_channel.

All implemented functionality is publicly documented. There appear to be additional attributes on the type: call block, however those appear to be internal values for slack's rendering, so I have left them out. See this gist for specific responses https://gist.github.com/winston-stripe/0cac608bd63b42d73a352be53577f7fd

Pull Request Guidelines

These are recommendations for pull requests. They are strictly guidelines to help manage expectations.

PR preparation

Run make pr-prep from the root of the repository to run formatting, linting and tests.

Should this be an issue instead

[ ] is it a convenience method? (no new functionality, streamlines some use case)
[ ] exposes a previously private type, const, method, etc.
[ ] is it application specific (caching, retry logic, rate limiting, etc)
[ ] is it performance related.

API changes

Since API changes have to be maintained they undergo a more detailed review and are more likely to require changes.

no tests, if you're adding to the API include at least a single test of the happy case.
If you can accomplish your goal without changing the API, then do so.
dependency changes. updates are okay. adding/removing need justification.

Examples of API changes that do not meet guidelines:

in library cache for users. caches are use case specific.
Convenience methods for Sending Messages, update, post, ephemeral, etc. consider opening an issue instead.

winston-stripe commented 1 year ago

Oddly, I have no idea why the lint step is failing. Downloaded and ran golangci-lint run locally and everything ran without a hitch. Maybe some weird bad caching or some unexpected actions interaction? Fwiw, when looking through their docs, I did notice that

v3.0.0+ requires explicit setup-go installation step prior to using this action: uses: actions/setup-go@v3

Still no idea otherwise esp since master is passing, i'm fully based off of master, and all failing files are other ones I didn't touch here 😕.

winston-stripe commented 1 year ago

Thanks @kanata2 for fixing the repo's linting check in #1194! rebased off master and everything is passing now

winston-stripe commented 10 months ago

bump: @kanata2 is it possible to get a 👀 on this?

slack-go / slack