Improvements to ChatOps Pack Development User Story in ST2 1.4dev

February 15, 2016
by Jon Middleton, Optimisation Project Lead @ Pulsant Limited

In the post StackStorm QuickTip: ChatOps your pack dev workflow James Fryman gave a ChatOPS alias recipe to reduce the friction for deploying packs and then in the Random Thoughts section asked:

This action is tied directly to the packs.install. What about a workflow? Seems like that would be a better way to structure this.

This resonated with me as I had already started working on an internal pack that did just that, as I thought attempting to deploy a pack via an alias (and action) contained within the same pack would be madness (or just lead to interesting race conditions). In the last week, our Pull Request has been merged, documentation has been included in st2docs (link) for a workflow that fulfils the above random thought and should be released with 1.4.

So introducing packs.deploy, an action written in Mistral to handle the mapping of names for Git repositories to the information required to carry out the packs.install action.

Great! But can I use this to deploy my own Pack(s)?

Yes you can! All you need to do to set up packs.deploy so that you can deploy from one of your own repositories is to add the following to /opt/stackstorm/packs/packs/config.yaml under repositories: for each of your packs.

MyAwesomePackRepo:
repo: "https://github.com//my-st2.git"
subtree: true

If you don’t have a packs directory, just set subtree to false.

Right, I’ve Done That, How Do I Use it?

The ChatOPS command has been simplifed to the following (as the Git URL is stored in the config file):

! pack deploy {{repo_name}} {{packs}} {{branch=master}} - Download StackStorm packs via ChatOps

And the ChatOPS responses have been simplified too, so that it’s using the ChatOPS formatting from StackStorm 1.2:

The Cool Stuff! A.k.a. automated deployment

The packs.deploy action can also be used for automated deployment, you just need to add the following to the definition above

auto_deployment:
branch: "master"
notify_channel: "my-chatops-channel"

And then set up an StackStorm rule that triggers packs.deploy with the right parameters (see the docs). There should be an example rule for BitBucket Server merged into the BitBucket pack before the release of 1.4). Thus a checkin on master happens the action will run and the following will be posted in your notify_channel.

Future Features?

This is another iteration of the pack deployment user story which further reduces friction. What else would be advantageous and supply another incremental reduction of friction?

• A sensor for GitHub / BitBucket that can detect auto-deployments for repositories that contain more than a single pack and only deploy the ones that have changes.
• Integration with Continuous Integration, so that only packs that pass are deployed.
• Lock out other users from deploying the same pack from a different branch until it’s reverted to master, so features being tested are not reverted.
• A queuing system for requested pack deployments, which informs the user when it’s their turn to deploy and that they may complete the process via a confirmation.

@Bot: Say _alas! ear wax!_ to complete your deployment of *AwesomePack* from *MyAwesomePackRepo* branch _Feature/factor-out-earwax-beans_.

@jjm: alas! ear wax!

@Bot: @jjm: Deploying *AwesomePack* from *MyAwesomePackRepo* for you…

• A rule running from a timer that checks when a non-deployment branch (e.g. dev) was deployed, and automatically rolls it back to master after a
  configured amount of time (e.g. 1 hour).
• Announcements of new features into #general in a more friendly and descriptive format than a change log.
• If you’re using a private repository and using OAuth2 tokens these will be contained in the URL, which will then be placed in chat. This could be worked round
  with a new conf option and masking it from chat. However the token will still be stored in the Git config, so it may be best to use SSH deployment keys.