At Spacelift, we're using Slack for internal communication. And we know that other tech companies do the same, so we've created a first-class integration that we ourselves enjoy using.
Here are examples of messages the Spacelift application sends to Slack;
Linking your Spacelift account to the Slack workspace»
As a Spacelift and Slack admin, you can link your Spacelift account to the Slack workspace by going to the Slack section of the Settings screen.
The integration is an OAuth2 exchange which installs Slack Spacelift app in your workspace.
Once you install the Spacelift app, the account-level integration is finished and the Slack section of the Settings screen informs you that the two are talking to one another:
Installing the Slack app doesn't automatically cause Spacelift to flood your Slack channels with torrents of notifications. These are set up on a per-stack basis using Slack commands and the management uses the Slack interface.
Though before that happens, you need to allow requests coming from Slack to access Spacelift stacks.
Managing access to Stacks with policies»
Similar to regular requests to our HTTP APIs, requests and actions coming from Slack are subject to the policy-based access validation. In this case, we're using stack access policies. If you haven't had a chance to review the relevant documentation yet, please do it now before proceeding any further - you're risking a chance of getting lost.
The default stack access policy for Slack requests is to deny all access.
Unlike HTTP requests, policy inputs representing Slack interactions replace
"session" sections with a single
"slack" section, containing the following payload:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
For the most up-to-date explanation of Slack user intricacies, please always refer to Slack's own documentation.
As you can see, that's quite a bit of data you can base your decisions on. For example, you can map some Slack channels as having certain level of access to certain Stacks - just make sure to keep these Slack channels private / invite-only. Here's an example stack access policy allowing Write level of access to requests coming from Slack's #dev-notifications channel:
Any Stack with this policy attached will be accessible for writing from this Slack channel - but no other!
Note that different commands may have different required levels of access, so you can create a more granular policies - for example giving a
#devops channel Write access, while giving only Read access to various "notifications" channels.
Available slash commands»
Three slash commands are currently available:
/spacelift subscribe $stackId- subscribes a particular Slack channel to run state changes for a given Stack - requires ;
/spacelift unsubscribe $stackId- unsubscribes a particular Slack channel from run state changes for a given Stack;
/spacelift trigger $stackId- triggers a tracked run for the specified Stack;
Currently confirming and discarding tracked runs is available through the Slack interface. The ability to trigger those actions is subject to a stack access policy check with a Write level on the user Slack info.