Things we could generate:

• initializer
• possibly the route
• a cogy folder inside the app with a README

Or require them to be defined explicitly. If we go the "not-required by default" way, then maybe we should also support a default description in commands, so that :desc isn't required.

Also update examples in README and docs.

Since we pass the args to #on, we can automatically define helpers to access the arguments.

on "foo", args: [:a, :b] do
  a # => returns args[0]
  b # => returns args[1]
end

We should somehow only accept requests from the cogy executable. This could be done by generating a token from the host application and send it in the config section of the bundle config YAML.

For this, we need operable/cog#1143 to be fixed first.

We should provide a way for users to define their own helpers, like user or something, that will be available inside commands and will return the Rails User object. It should be configurable like this:

Cogy.configure do |c|
  c.user_lambda = ->(id) { User.find(id) }
end

Then the helper could just call this lambda with the Cogy ENV as the argument.

Blocked on #35.

Right now, since all the user-defined commands are eventually turn into Proc objects, we can't use return. So we are forced to use next instead, but it's not intuitive.

This will list all the available commands and provide the ability to execute them from the browser.

Ruby version, cogy bundle, Rails.

This bundle will:

• ship the cogy executable that should be placed in the Relays (#5)
  • the URL that it hits should be configurable using a dynamic configuration
• provide the install command that accepts the inventory endpoint as a URL and install the bundle to Cog

Supersedes #5.

The Cogy executable should pass all env. variables that start with COGY_ to the backend app.

This could be done by injecting a cog_url option in all the generated commands. Then the executable will read this option and act accordingly.

If we do this, then we can also get rid of the hardcoded URLs inside the executable and make it totally Rails-app-agnostic.

Blocked by #5.

It should be easy for users to test their commands inside their apps.

Ship an executable from the gem, that can be used to test cogy commands from the terminal.

It should probably share the same code with the Relay executable that we'll ship eventually, so this depends on #5.

Also add version badge from badgefury.

Handler does not make much sense now, plus we need a class to hold the execution context for a command invocation. That way we could also have an env method, similar to how ActionPack has.

..using curl or something

When an error occurs inside a command, the backtrace is not useful due to eval. We should fix this.

We should add support for easily returning JSON to Cog and also define templates for commands.

Proposal

JSON responses

We could detect if the result of a command invocation is a Hash, and if it is, then inject the "JSON" line in the response and possibly call render :json instead of render :text.

Templates

Templates are defined in separate files (without an extension), named after their corresponding command. For example, for a command named "foo", Cogy would search in app/cogy/templates/**/* for a file named foo and, if found, it would use it when generating the bundle config.

Defining templates

(TBD)

Also hook it into the tests.

https://gemnasium.com

• Cogy
• Command
• Handler
• controller & views
• Integrate yardoc tasks and gem
• link from README

http://keepachangelog.com/en/0.3.0/

This is a matter of testing with a Rails 5 dummy and update the dependency constraints. It should mostly be fine for Rails 5.

This will make Cogy endpoints hittable by web browsers too.

We should pass the whole Cog envinronment, and wrap it in a hash.

Then we could move the logic that extracts args and opts from CogyController to instance methods in Context.

Depends on #25.

Document the recommended deployment flow and provide:

• capistrano tasks for invoking the trigger
• possibly configuration options for controlling those
• a sample Cog trigger (using our 'cogutils' bundle)
  • we have to release cogutils first

• capistrano 2
• capistrano 3

Right now users have to set the COGY_BACKEND environment variable in order to use Cogy (see here). Ideally, this shouldn't be necessary.

When operable/cog#1143 is fixed, we can inject COGY_BACKEND from the Cogy configuration into the inventory so that it passes through to the cogy executable. Even better, we could generate it automatically, or have a sane default.

• use the new setting also in Capistrano task

Right now we return 200, which is not ideal.

It should illustrate the typical workflow of writing a new command:

1. writing a bundle
2. deploying the app
3. capistrano task
4. cog trigger
5. cogy:install

Also how calling a command works:

1. user typing in Slack
2. Cog invoking cogy executable
3. executable hitting the application etc.

It should:

1. add the route
2. create a cogy folder and place a README
3. create the initializer (reuse the existing generator)

This should be closed once we add tests that test the expected results of commands.

The generators added in cd3ac72 are effectively unusable because Cogy will throw an error on boot if bundle_version and executable_path configuration options aren't set (which aren't, if the user haven't done so manually).

We should just warn or do nothing at all if those configs aren't set. We should instead default them to something, like all the other configuration values.

The executable should do a POST instead of a GET.

It's more intuitive that it's a POST that triggers a command that may change the state of the application and we won't clutter the URL with all the environment info we want to share in the future.

application/x-yaml seems good.

Right now, we provide a way to bump the version automatically when a file changes (using the grit gem). We should instead provide a portable way to do this without having to copy/paste code from our documentation.

Right now, what we get is:

---
cog_bundle_version: 4
name: foo
description: Cogy commands
version: '0.0.1'
commands: {} # <-- this

We need to figure a way to ship the executable from within this gem.

Right now, if for example we hit http://app:3000/cogy/cmd/idontexist/foo, the following is rendered:

@say_foo: Command 'agifdsas' returned an error.

```
NoMethodError:undefined method `run!' for nil:NilClass
```

We should instead inform the user that the command doesn't exist.

We should probably support everything in the 4.2 series. Also update README accordingly.

Right now all commands are under a single bundle. This probably won't scale well when different teams start adding team-specific commands.

We need a way to namespace individual commands.