Add st2chatops role #125

humblearner · 2017-03-04T07:21:54Z

Sample for st2chatops role

       - name: Install st2chatops with "slack" hubot adapter
         role: st2chatops
         vars:
            st2chatops_version: latest
            st2chatops_st2_api_key: CHANGE-ME-PLEASE 
            st2chatops_hubot_adapter: slack
            st2chatops_config:
              HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE

For st2_api_key generation task: https://github.com/StackStorm/ansible-st2/pull/125/files#diff-c6fa708e733eecbe8e8a283eb5690c19R53

arm4b · 2017-03-06T14:41:24Z

Installation looks pretty clean.

From the configuration point of view we'll need the following syntax to work:

st2chatops_version: latest
# hash to configure any value in st2chatops.env
# https://github.com/StackStorm/st2chatops/blob/master/st2chatops.env
st2chatops_config:
  ST2_API_KEY: 123asd456
  HUBOT_ADAPTER: slack
  HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE
  ...

humblearner · 2017-03-06T15:19:18Z

Awesome!! That was my next question, whether we need configuration or not. Thanks!!

lakshmi-kannan · 2017-03-06T18:52:47Z

roles/st2chatops/tasks/main.yml

+    state: present
+  when: st2chatops_version != "latest"
+  notify:
+    - restart mistral


Haha, right in the bull's-eye! 🎯 🥇

haha, WIP folks 😉

…atops_role

arm4b · 2017-03-07T12:48:46Z

README.md

 | `st2mistral_db`          | `mistral`     | PostgreSQL DB name for Mistral.
 | `st2mistral_db_username` | `mistral`     | PostgreSQL DB user for Mistral.
 | `st2mistral_db_password` | `StackStorm`  | PostgreSQL DB password for Mistral.
+| **st2chatops**               | Default hubot adapter: 'slack'
+| `st2chatops_version`     | `latest`      | st2mistral version to install. Use `latest` to get automatic updates or pin it to numeric version like `2.2.0`.
+| `st2chatops_ST2_API_KEY` | `CHANGE-ME-PLEASE`      | st2 API key, that can be generated using `st2 apikey create -k` in a task.


The problem with this approach is that we need a new var for every setting in st2chatops.env. And if we introduce new setting in st2chatops (like recent Mattermost support https://github.com/StackStorm/st2chatops/pull/65/files) it will force us to edit ansible-st2 as well.

The better approach is to have st2chatops_config hash/dict which will allow us to configure ANY env variable in st2chatops.env.
Take a look at my comment, we need the following syntax to work: #125 (comment)

# hash to configure any value in st2chatops.env # https://github.com/StackStorm/st2chatops/blob/master/st2chatops.env st2chatops_config: ST2_API_KEY: 123asd456 HUBOT_ADAPTER: slack HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE # add here any other env var to configure

At a high level we just have {{ st2chatops_config }} var to rule all config settings.
Similar approach is implemented in https://github.com/StackStorm/ansible-st2/pull/121/files

arm4b · 2017-03-08T17:16:33Z

roles/st2chatops/tasks/main.yml

+  become: yes
+  replace:
+    dest: /opt/stackstorm/chatops/st2chatops.env
+    regexp: '^# (export HUBOT_SLACK_TOKEN.).*'


This is still not scalable and handling every single env var is error-prone.

We need better approach.
When {{ st2chatops_config }} "dict" is provided, - just iterate over key/value pairs and set those in st2chatops.env.

So with {{ st2chatops_config }} user could midify any existing env variable from the https://github.com/StackStorm/st2chatops/blob/master/st2chatops.env.

This should work (#commented vars):

st2chatops_config: HUBOT_ADAPTER: irc HUBOT_IRC_SERVER: example-server.com HUBOT_IRC_PORT: 100500

With that, keep in mind to cover corner cases like handling both "#commented" and "uncommented" records in st2chatops.env. Eg. if user provided HUBOT_ADAPTER: IRC in {{ st2chatops_config }}, - we should uncomment that var and set value. If record is already uncommented, - just set new val.

@humblearner Another corner case.
If user provided completely new env var like FOO: bar via {{ st2chatops_config }}, - should we write that key:value in st2chatops.env too or maybe throw an error that such env var is not available. WDYT?

(new vars):

st2chatops_config: FOO: bar

I'd rather not go through all of this and have a .j2 file for each adapter in files/ with jinja templates for the settings. So based on the adapter variable you can generate a config from ansible with variables substituted and placed in the st2chatops.env file on the box.

The problem with that approach is described here: #125 (comment)

Ex: @emedvedev merges Mattermost support (https://github.com/StackStorm/st2chatops/pull/65/files) and we obviously won't include env vars in ansible-st2.

Another example is that the list of vars we list in st2chatops.env is not full and can't be. There are a bunch of custom env vars for this or that adapter and even Hubot itself.
Just a quick example from search:

https://github.com/github/hubot/blob/498d65611388d2881e6ae24f74bd68a832a24211/src/robot.coffee#L413-L417

https://github.com/github/hubot/blob/498d65611388d2881e6ae24f74bd68a832a24211/bin/hubot#L24-L30

Who knows about more vars hidden in the code?
I don't even want to care about it, it's user's problem. They know what they need, - let's give an instrument.

BTW this approach is similar to #121 to avoid relying on st2.conf templating which can become outdated quickly.

I don't even want to care about it, it's user's problem.

No. We explicitly decided that we'll supply this in commented form in our config file so they don't have to go guess. If someone is adding support for an adapter here, they should include a .j2 file. A .j2 file is a schema for the adapter configuration. You won't have the following problem if you went with this approach.

should we write that key:value in st2chatops.env too or maybe throw an error that such env var is not available. WDYT?

Who knows about more vars hidden in the code?

Exactly the problem we should solve and not leave it to user

we obviously won't include env vars in ansible-st2.

I'd validate the "adapter" variable against a set of supported adapters. A supported adapter means presence of .j2 file.

Exactly the problem we should solve and not leave it to user

I just demonstrated with links how we'd fail to do that.
We can recommend to set some frequently used vars in st2chatops.env but we literally can't inspect every new hubot adapter for some hidden vars. And even by adding new vars you can't monitor all those adapters when new env var is added or new feature is implemented.

Additionally, in st2chatops.env user can add any new env var he wants. Think about custom hubot plugins enabled which is usually the case for real installations. So env vars in reality are used not just to configure predefined list of adaptors, but much more.
By hardcoding I think we bring more work for us and less flexibility for users.

If someone is adding support for an adapter here

None will be adding support for adapter here after adding it in st2chatops or hubot-stackstorm. I had enough cases to be realistic about this when different repos become unsync quickly.
That's the reason I'm implementing config setting in a "free form" #121 rather then hardcoded key-vals for every setting. And I would like us to be consistent in this approach across entire Ansible repository to keep the configuration repo management pragmatic & balanced.

Oh you two. What a silly little tussle. It's adorable to be honest.

I'm inclined to agree w/ @armab but would like to see how it would get implemented. I know how I would do it, but would like to really see what you're thinking. Seems like the "harder" of the two to implement but one that will cause least amount of work in the future.

On the flip side I wonder if @armab is worried about stuff that we just flat out aren't going to run into often and the type of person that runs into it will probably have the ability to fix it anyway.

@armab can you or @humblearner contribute the fix for this quickly? If not I'd say just let @humblearner implement it with J2.

Just googled a bit more about other implementations and "what could be expected".

See these config examples, looks pretty reasonable:
Ansible example for Hubot: https://github.com/brianshumate/ansible-hubot
Chef example for Hubot: https://github.com/chef-cookbooks/hubot#attributes

I think we can do it the same way:
Make {{ st2chatops_adapter }} var required (since hubot won't work without adapter) and additional env vars via {{ st2chatops_config }} dict optional.

The problem with hardcoded vars is that apart of "adapter vars" there are also hubot plugin vars:
https://github.com/brianshumate/ansible-hubot/blob/5a1d679472ebfd12119cc9db0209a219560cc6ab/defaults/main.yml#L61

arm4b · 2017-03-08T17:37:04Z

roles/st2chatops/defaults/main.yml

+# https://github.com/StackStorm/st2chatops/blob/master/st2chatops.env
+st2chatops_config:
+  ST2_API_KEY: CHANGE-ME-PLEASE
+  HUBOT_ADAPTER: slack


I think we shouldn't set HUBOT_ADAPTER: slack by default if user didn't provide any custom key: value for that.
WDYT?

These are supposed to contain sane and safe defaults. I am fine with this TBH.

arm4b · 2017-03-08T19:05:30Z

And yeah, we want to include st2chatops role in existing TravisCI machinery, otherwise there is no way to know if things really worked.
(you can set "private" ENV variables in Travis UI for Slack).

With that, we somehow need to find the way to disable debug messages for specific tasks to avoid showing token in Travis build logs: https://travis-ci.org/StackStorm/ansible-st2/jobs/209102385

arm4b · 2017-03-09T21:05:08Z

Just a note:

As a good configuration management citizens we'll need ansible vars to install & enable hubot external scripts/plugins from http://hubot-script-catalog.herokuapp.com/
As said before, that's how real ChatOps deployment usually looks like (ex: !shipit from the Hubot community and more stuff like that). That's where custom ENV vars will be needed too.

Same as it's implemented in https://github.com/brianshumate/ansible-hubot and https://github.com/chef-cookbooks/hubot#attributes

Not a requirement for this PR, - can wait for future.

humblearner · 2017-03-10T03:40:11Z

Alright!! After long discussion and tie-breaker (Thanks @bigmstone!!). We are going with dict and loop_control.

For now, I have kept the Configure adapter setting task in main.yml. In case it gets complex we can move it to its own file config.yml.

FYI.. going with .j2 would have been more painful and complex as individual template modules for adapters would've overwritten the env file. Using assemble module meant more tasks to get all the parameters besides adapter settings in st2chatops.env.

ToDo:

Add check for every key in the hash: Currently all the keys should have adapter name export HUBOT_<Adapter_Name>_<Variable>=<Value> in st2chatops.env.
Add token in Travis. For this I was thinking of using ansible-vault instead of adding token in Travis. Travis log

TASK [st2chatops : Add st2_api_key in st2chatops.env] **************************
task path: /vagrant/roles/st2chatops/tasks/main.yml:18
changed: [centos6] => {"changed": true, "msg": "1 replacements made"}

and clean: https://github.com/StackStorm/ansible-st2/pull/125/files#diff-ec9a9d2344ff9779bfa7756c4ada61feR5.

Update README

arm4b · 2017-03-10T12:57:13Z

changed: [localhost] => {"changed": true, "msg": "1 replacements made"}

@humblearner Yeah, that sounds good enough. I thought it will show real API_KEY in the log.

Vault is not necessarry, since we don't want our keys (even encrypted) to be distributed with the repo. But as additional precautionary measure adding no_log: yes for specific task that saves potentionally sensitive data in st2chatops.env would be nice.

arm4b · 2017-03-10T13:08:31Z

Add check for every key in the hash: Currently all the keys should have adapter name export HUBOT_<Adapter_Name>_= in st2chatops.env.

I'm not sure if we need such validation, since with {{ st2chatops_config }} user potentionally can save any ENV variable he wants in st2chatops.env. As said before, custom ENV variables are used not only to configure specific hubot adapters, but also any specific hubot plugins installed by the user, see: http://hubot-script-catalog.herokuapp.com/

There are a bunch of variables you can set, depending on Hubot plugins installed:

export FILE_BRAIN_PATH
export HUBOT_SHIP_EXTRA_SQUIRRELS
export HUBOT_ANNOUNCE_ROOMS

and so we can't and don't want to control that via any kind of rules.

arm4b · 2017-03-10T13:13:48Z

roles/st2chatops/meta/main.yml

+    - st2
+    - devops
+    - chatops
+    - autmation


Also i think we can include additional hubot tag.

arm4b · 2017-03-10T13:17:00Z

roles/st2chatops/meta/main.yml

+    - chatops
+    - autmation
+dependencies:
+    - role: st2


st2 role is not a requirement for st2chatops since st2chatops can be installed on a separated machine, it's possible to configure remote API endpoints and it will work.

Saying that, st2repo is a dependency for sure to install st2chatops package.

cc @lakshmi-kannan you asked before why we need st2repo and st2 roles separated.

Apparently, it should. However, it fails here:

RUNNING HANDLER [st2chatops : restart st2chatops] ****************************** fatal: [centos6]: FAILED! => {"changed": false, "failed": true, "msg": "touch: cannot touch `/var/log/st2/st2chatops.log': No such file or directory\nrunuser: group st2 does not exist\n"}

Nice! This sounds like a bug discovered.

st2chatops can be configured on separated machine (https://github.com/StackStorm/st2chatops/blob/master/st2chatops.env#L23) and should not rely on resources created by st2 package.

Can you document the bug in st2chatops repo? It's a packaging issue, we can fix it later.

arm4b · 2017-03-10T13:21:21Z

roles/st2chatops/defaults/main.yml

+st2chatops_ST2_API_KEY: "CHANGE-ME-PLEASEdd"
+
+# Hubot Adapter to be used for st2chatops
+st2chatops_HUBOT_ADAPTER: CHANGE-ME-PLEASE


Just an empty string or None (which won't set the val in st2chatops.env) as a default would be nice.

Also I'm more in favor of lowercase vars like: st2chatops_adapter or if you want st2chatops_hubot_adapter.

https://github.com/StackStorm/ansible-st2/pull/125/files#r105474907

arm4b · 2017-03-10T13:24:14Z

roles/st2chatops/defaults/main.yml

+st2chatops_version: latest
+
+# Please provide ST2_API_KEY using "st2 apikey create -k"
+st2chatops_ST2_API_KEY: "CHANGE-ME-PLEASEdd"


Same as previous comment, just an empty string or maybe None (which won't set the val in st2chatops.env) instead of CHANGE-ME-PLEASEdd will look nicer.

CHANGE-ME-PLEASE is similar to https://github.com/brianshumate/ansible-hubot/blob/master/defaults/main.yml#L58. Better explicit than implicit. 🙂

arm4b · 2017-03-10T13:25:30Z

roles/st2chatops/meta/main.yml

+  description: Install st2chatops
+  author: humblearner
+  company: StackStorm
+  license: Apache


arm4b · 2017-03-10T13:31:24Z

roles/st2chatops/tasks/main.yml

+    - '^(export ST2_AUTH_USERNAME.*)'
+    - '^(export ST2_AUTH_PASSWORD.*)'
+  when: st2chatops_api_key.changed
+  tags: [st2chatops, skip_ansible_lint]


Same as before, any touch of st2chatops.env should trigger st2chatops restart handler.

Make sure we follow that in all other Ansible tasks.

arm4b · 2017-03-10T13:33:59Z

roles/st2chatops/vars/main.yml

@@ -0,0 +1,9 @@
+---
+supported_hubot_adapter:


supported_hubot_adapters

arm4b · 2017-03-10T13:36:23Z

roles/st2chatops/tasks/main.yml

+    dest: /opt/stackstorm/chatops/st2chatops.env
+    regexp: '^# (export HUBOT_ADAPTER={{ st2chatops_HUBOT_ADAPTER }})$'
+    replace: '\1'
+  when: st2chatops_api_key.changed and st2chatops_HUBOT_ADAPTER in supported_hubot_adapter


st2chatops_HUBOT_ADAPTER in supported_hubot_adapter

In this case it will skip this important task if adapater is wrong.
I think it makes sense to move this validation logic in separated task and FAIL playbook execution early and loud if user provided invalid adapter.

Ex how @lakshmi-kannan did it:

ansible-st2/roles/bwc_repos/tasks/bwc_repos_apt.yml

Lines 3 to 5 in 1aa9d35

- name: Assert that master_token is specified

fail: msg="License key must be supplied for BWC enterprise installation."

when: license is not defined

arm4b · 2017-03-10T13:43:14Z

roles/st2chatops/tasks/main.yml

+  with_dict: "{{ st2chatops_config }}"
+  loop_control:
+    loop_var: _conf_option
+  when: uncomment_adapter.changed  # TODO: Add check for Individual keys in hash


This will fail to work in cases when user needs to re-configure adapter settings.
Ex: change API key, but didn't change adapter.

Consider this Ansible role not as a way to install st2chatops role only once, but in a wide conext of management where different values could be changed/reconfigured with time.

arm4b · 2017-03-10T13:48:15Z

README.md

 | `st2mistral_db`          | `mistral`     | PostgreSQL DB name for Mistral.
 | `st2mistral_db_username` | `mistral`     | PostgreSQL DB user for Mistral.
 | `st2mistral_db_password` | `StackStorm`  | PostgreSQL DB password for Mistral.
+| **st2chatops**
+| `st2chatops_config`      | `{ }`         | Hash of st2chatops settings to edit in [`st2chatops.env`](https://github.com/StackStorm/st2chatops/blob/master/st2chatops.env) file. For example, `Slack` hubot adapter requires: `ST2_API_KEY: CHANGE-ME-PLEASE` `HUBOT_ADAPTER: slack` `HUBOT_SLACK_TOKEN: xoxb-CHANGE-ME-PLEASE`


With 2 new jinja vars, seems ST2_API_KEY and HUBOT_ADAPTER are irrelevant in this description now.
We just need them in README.

arm4b · 2017-03-10T13:58:13Z

Curious how st2chatops is up and running without providing required configuration like ST2_API_KEY and other real settings. Probably the process exits in a couple of seconds later.

We need to add some simple check in st2smoketests to keep it real.

arm4b · 2017-03-10T14:01:08Z

roles/st2chatops/vars/main.yml

+ - flowdock
+ - yammer
+ - spark
+ - irc


Please also include shell adapter: https://github.com/github/hubot/blob/master/docs/adapters/shell.md

BTW do you think it will be better if we use shell adapter instead of Slack for testing/smoketests purposes in TravisCI?

Also we need mattermost adapter.
Just to be one step ahead because of this addition: StackStorm/st2chatops#65 I'm sure we'll forget to add it later.

arm4b · 2017-03-10T15:04:38Z

When all finished/merged, we'll need Ansible st2docs update to highlight st2chatops installation and configuration.

humblearner · 2017-03-10T21:53:29Z

@humblearner Another corner case.
If user provided completely new env var like FOO: bar via {{ st2chatops_config }}, - should we write that key:value in st2chatops.env too or maybe throw an error that such env var is not available. WDYT?
(new vars):
st2chatops_config:
 FOO: bar```

is why i had ToDo task:

Add check for every key in the hash: Currently all the keys should have adapter name export HUBOT_<Adapter_Name>_= in st2chatops.env.

However, I am perfectly fine, leaving it open for the user to decide, what they want to add to their hubot adapter settings.

arm4b · 2017-03-10T22:10:06Z

Yeah, I think that corner case is irrelevant now, considering research and fact that env variable could be anything from the http://hubot-script-catalog.herokuapp.com/, not just adapter-specific.

arm4b · 2017-03-13T14:09:28Z

roles/st2chatops/tasks/main.yml

+  tags: st2chatops
+
+
+- name: Uncomment Hubot "{{ st2chatops_hubot_adapter|upper }}" adapter in "/opt/stackstorm/chatops/st2chatops.env"


What if i specify st2chatops_hubot_adapter=slack in Ansible and then change it to st2chatops_hubot_adapter=hipchat or any other adapter later?

Will it work?

arm4b · 2017-03-13T14:14:17Z

roles/st2chatops/tasks/main.yml

+- name: Assert st2chatops_hubot_adapter is specified
+  fail:
+    msg: >
+      '"st2chatops_hubot_adapter" must be supplied in roles/st2chatops/defaults/main.yml for st2chatops installation.


We can omit mentioning roles/st2chatops/defaults/main.yml since it's not single point of truth.
Just asking user to provide {{ st2chatops_hubot_adapter }} var is enough.

I guess, you mean https://github.com/StackStorm/ansible-st2/blob/master/roles/st2chatops/vars/main.yml

arm4b · 2017-03-13T14:29:53Z

Sync-up with master to include the recent build failure fix.

Additionally, as said before, we'll need some smoke test case to make sure st2chatops really works.

…atops_role

arm4b · 2017-03-14T13:44:49Z

roles/st2chatops/vars/main.yml

+ - yammer
+ - spark
+ - irc
+ - mattermost


Just discovered in st2chatops PR that the right naming for mattermost adapter is matteruser, see: https://github.com/StackStorm/st2chatops/blob/1164c0823885931e3a3ad48e0cbb52a336f2d01b/st2chatops.env#L107

FWIW, mattermost adapter should work as well, and we have support for it in hubot-stackstorm, but @armab is right, matteruser is the one we pack in st2chatops.

humblearner · 2017-03-19T21:09:19Z

roles/st2smoketests/tasks/main.yml

+    replace: '{{ st2chatops_api_key }}'
+  no_log: true
+  changed_when: no
+  notify: restart st2chatops


This is a catch-22 situation. Either restart or idempotency. Removing this and https://github.com/StackStorm/ansible-st2/pull/125/files#diff-c6fa708e733eecbe8e8a283eb5690c19R124 in favor of: https://github.com/StackStorm/ansible-st2/pull/125/files#diff-c6fa708e733eecbe8e8a283eb5690c19R140

arm4b · 2017-03-20T11:11:39Z

roles/st2smoketests/tasks/main.yml

+    - smoke-tests
+
+- name: Verify st2chatops using bin/hubot
+  shell: "cd /opt/stackstorm/chatops/ && { echo -n; sleep 5; echo '! st2 list actions'; echo; sleep 10; } | bin/hubot --test "


With bin/hubot --test we actually test shell adapter.
See: https://github.com/StackStorm/st2chatops/blob/master/bin/hubot#L20-L22

From the lines above I see you're setting HUBOT_SLACK_TOKEN

So decide whether you test slack or shell hubot adapter.

arm4b · 2017-03-20T11:16:36Z

roles/st2chatops/tasks/main.yml

+- name: Assert st2chatops_hubot_adapter is specified
+  fail:
+    msg: >
+      '"st2chatops_hubot_adapter" must be supplied in roles/st2chatops/defaults/main.yml for st2chatops installation.'


This error message looks not exactly what we check, according to this conditional:

when: st2chatops_hubot_adapter not in supported_hubot_adapters

As I understand we really check if {{ st2chatops_hubot_adapter }} is supported, but instead of that throwing an error saying that {{ st2chatops_hubot_adapter }} is not provided in roles/st2chatops/defaults/main.yml.

arm4b

Looks nice/works well 👍

Just a final request, - can you please also extract chatops smoketests into separated file st2chatops.yml under the st2sometests role?
It will be easier to add when conditional in future, ex: run st2chatops checks only when respective package is installed.
Just FYI, once merged I'll see what I can do to polish corner cases similar to that a bit later.

arm4b · 2017-03-21T18:30:22Z

Once merged what we'll need also:

st2chatops issue
st2docs PR (Add st2chatops role #125 (comment))

Add st2chatops role

8f083d8

lakshmi-kannan reviewed Mar 6, 2017

View reviewed changes

Anirudh Rekhi added 3 commits March 6, 2017 11:08

Merge branch 'master' of github.com:StackStorm/ansible-st2 into st2ch…

1e2bcb9

…atops_role

Fix as per comment and merge master

d6ea7b1

Add st2chatops configuration

217bf6f

humblearner mentioned this pull request Mar 7, 2017

ChatOps Support #13

Closed

Anirudh Rekhi added 2 commits March 6, 2017 23:07

Make ansible-lint happy, minor changes and README update

3fc04be

ST2_API_KEY update

eecbd9b

arm4b suggested changes Mar 7, 2017

View reviewed changes

Anirudh Rekhi added 2 commits March 7, 2017 14:56

Include hash to configure value in st2chatops.env

2c1f98f

Update README for st2chatops_config

cbe2228

humblearner changed the title ~~[WIP] Add st2chatops role~~ Add st2chatops role Mar 8, 2017

arm4b reviewed Mar 8, 2017

View reviewed changes

Anirudh Rekhi added 2 commits March 9, 2017 18:50

Update to include hash of adapter settings

a6b9ac3

Making Travis happy

d8457ce

arm4b suggested changes Mar 10, 2017

View reviewed changes

arm4b reviewed Mar 10, 2017

View reviewed changes

Add shell and mattermost in supported_adapters

60498fa

Anirudh Rekhi added 2 commits March 12, 2017 17:53

Fix lint error

08787f6

notify restart for shell

f32b023

arm4b reviewed Mar 13, 2017

View reviewed changes

Anirudh Rekhi added 3 commits March 13, 2017 13:21

Merge branch 'master' of github.com:StackStorm/ansible-st2 into st2ch…

d2e428a

…atops_role

Support for adapter update

19ae2d0

Make adapter update idempotent

38931c5

arm4b reviewed Mar 14, 2017

View reviewed changes

arm4b mentioned this pull request Mar 14, 2017

Pack Install #74

Open

Anirudh Rekhi added 6 commits March 14, 2017 09:38

Add matteruser as one of the supported adapters.

612b213

smoketests for st2chatops

7a4e49d

update kitchen.yml for adapter

ed4d3b7

fix for ansible-lint

1159ef7

Errors only Travis can catch

6889da9

Fix for idempotency

ed2c96d

humblearner commented Mar 19, 2017

View reviewed changes

Remove notify handler in favor of changed_when:no

b56921d

arm4b reviewed Mar 20, 2017

View reviewed changes

Anirudh Rekhi added 2 commits March 20, 2017 15:28

Update test for slack adapter

a8b71d0

Add tags and update failure message

cde6ac0

arm4b approved these changes Mar 21, 2017

View reviewed changes

humblearner mentioned this pull request Mar 21, 2017

st2chatops cannot be installed without st2 repo on a separate instance StackStorm/st2chatops#67

Closed

Anirudh Rekhi added 3 commits March 21, 2017 14:26

Move st2chatops smoke tests to seperate yml file

f718a16

Changed to right variable

a109d68

Add check for hubot_token

bb4e4b6

humblearner merged commit 1f7a1b6 into master Mar 21, 2017

humblearner deleted the st2chatops_role branch March 21, 2017 22:20

	- name: Assert that master_token is specified
	fail: msg="License key must be supplied for BWC enterprise installation."
	when: license is not defined

		tags: st2chatops


		- name: Uncomment Hubot "{{ st2chatops_hubot_adapter\|upper }}" adapter in "/opt/stackstorm/chatops/st2chatops.env"

		@@ -0,0 +1,9 @@
		---
		supported_hubot_adapter:

Add st2chatops role #125

Add st2chatops role #125

Conversation

humblearner commented Mar 4, 2017 • edited by arm4b Loading

arm4b commented Mar 6, 2017 • edited Loading

humblearner commented Mar 6, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 7, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b Mar 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 9, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b commented Mar 8, 2017 • edited Loading

arm4b commented Mar 9, 2017 • edited Loading

humblearner commented Mar 10, 2017 • edited Loading

arm4b commented Mar 10, 2017 • edited Loading

arm4b commented Mar 10, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

humblearner Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b commented Mar 10, 2017 • edited Loading

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b Mar 10, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b commented Mar 10, 2017

humblearner commented Mar 10, 2017

arm4b commented Mar 10, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b commented Mar 13, 2017

arm4b Mar 14, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

arm4b Mar 20, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b Mar 20, 2017 • edited Loading

Choose a reason for hiding this comment

arm4b left a comment

Choose a reason for hiding this comment

arm4b commented Mar 21, 2017

humblearner commented Mar 4, 2017 •

edited by arm4b

Loading

arm4b commented Mar 6, 2017 •

edited

Loading

arm4b Mar 7, 2017 •

edited

Loading

arm4b Mar 8, 2017 •

edited

Loading

arm4b Mar 8, 2017 •

edited

Loading

arm4b Mar 8, 2017 •

edited

Loading

arm4b Mar 9, 2017 •

edited

Loading

arm4b Mar 9, 2017 •

edited

Loading

arm4b commented Mar 8, 2017 •

edited

Loading

arm4b commented Mar 9, 2017 •

edited

Loading

humblearner commented Mar 10, 2017 •

edited

Loading

arm4b commented Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

humblearner Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

arm4b commented Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

arm4b Mar 10, 2017 •

edited

Loading

arm4b Mar 14, 2017 •

edited

Loading

arm4b Mar 20, 2017 •

edited

Loading

arm4b Mar 20, 2017 •

edited

Loading