GitLab.org / omnibus-gitlab

mentioned in issue #1211 (closed)

mentioned in merge request !564 (closed)

mentioned in issue gitlab-ce#19793 (closed)

mentioned in issue gitlab-ce#19838

mentioned in issue gitlab-ce#17575

Milestone changed to 8.12

@markpundsack @sytses what do we expect from a first iteration? Just ship it with GitLab? Have we reviewed how?

I'd expect to ship Cog with a Mattermost integration that is preconfigured and significantly functional with GitLab commands.

Clarification: Omnibus won't install Cog, but we can provide scripts/instructions for how to install and integrate easily.

From @sytses comment on https://gitlab.slack.com/archives/koding/p1470850703000179:

the idea is to make it easy to spin up Koding & Cog containers after you did the GitLab Omnibus install and ensure these are automatically configured

Just to capture this somewhere: I really like the slash commands integration (from gitlab-ce#19838) better than bot integration. The slash commands feel more natural with Slack. I don't feel any benefit by having a "bot" that I can talk with, @ mention, etc. Also, Slack allows deeper integration via Apps than a bot can do. For example, an app can respond with a question and have buttons the user can click on to pick an answer. It can also do OAuth to easily connect your Slack account with your GitLab account on first usage. The app backend could exist in the main Rails app of GitLab without requiring additional containers/processes/configuration. We could add the GitLab.com app to the Slack app catalog so everyone can install it easily. Single-tenant GitLab installs would have a Slack app install button somewhere to make it easy to install with a click or two.

I don't want to derail the work on Cog, but a native Slack integration is worth looking at.

To be fair, !deploy isn't hugely different from /deploy, and there are other advantages with Cog, so I'm sure the Cog integration will still be great.

mentioned in issue gitlab-ce#20799 (closed)

Created gitlab-ce#20799 (closed) to discuss Slack app option.

mentioned in issue gitlab-ce#20800 (closed)

To add something to the conversation, slash commands are just another way of starting some simple commands. You can still have a bot and slash commands integrated with it.

For example, you can start a deploy with /deploy <application> <environment>, the bot can start some initial integration tasks and ask you for configuration / optional data or confirmation like:

> Are you sure you want to deploy to *production*? 
Yes
> You must define a new *password* for *admin* user, please type in: 
123safepassword
> Your new instance is http://example.com.

There are a lot of valid scenarios where slash commands cannot handle well.

Yes, slash commands and bot interactions go well together. From what I understood, Cog can't support slash commands, whereas a native Slack app can support both.

mentioned in issue #1498

To ship Cog with GitLab I propose we add the Cog coordinator and default scripts to the Kubernetes configuration for GitLab

Added direction label

FYI, after discussing with @sytses today, we've posted a [Help Wanted] request to the Mattermost community for writing a Cog-Mattermost adapter in Elixir

I looked at leveraging Nomad at first but give that we are going with Kubernetes in our runner we should stick to that one tool.

BTW, I played around with creating Cog omnibus packages few weeks ago. It is doable but for this first iteration we should definitely not go in that direction.

Please be sure to document Cog + Kubernetes. We have no documentation for CI + Kubernetes so support cannot help customers.

mentioned in issue #1528 (closed)

@marin the link to https://gitlab.com/marin/omnibus-cog doesn't work for me

Couple of items I wanted to clarify:

• Hubot's original author, Ryan Tomayko, is not affiliated with Operable nor is he involved with Cog's development. We think Ryan is awesome and would love it if he ever wanted to get involved with Cog but such is not the case now.
• Cog can execute commands via Docker containers or as native OS processes by shelling out to run command executables. Docker is not a hard requirement.
• There's no technical reason why Cog couldn't support Slack's slash commands as the main REST API is a Phoenix web app (roughly analogous to a Rails). Slash commands aren't on our roadmap because we believe shell-like composability is more powerful but we'd definitely entertain PRs to add support for them.

mentioned in issue gitlab-ce#21658

Thanks for the clarification @kevasmith. I'd be interested to see how complicated it would be to handle slash commands with Cog.

Cog already has support for triggers which are similar to webhooks. I suspect it wouldn't be too hard to either use the feature directly or extend it to work with single-shot command APIs like Slack's slash commands.

For posterity, I built a Slack slash command that integrated with Cog via a standard Trigger one afternoon a couple of months ago. It seemed to work fine for the basic test. It's pretty straightforward.

The worst part of the process is the way that Slack handles slash commands via apps, since there doesn't seem to be a way to customize the backing URL at installation time. That means that if you had a single "GitLab" app in the Slack directory, it would always point to the same URL. For hosted GitLab, that's fine, but for folks who are running their own instances it would be less ideal.

Mentioned in issue gitlab-ce#22190 (closed)

Mentioned in issue #1528 (closed)

Milestone changed to 8.13

Status changed to closed

We've started with a very minimum implementation of slash commands in Mattermost so at this moment we are not focused on integrating Cog. I will close this issue for now until we pick up this effort again.