[Jjarro]

I have a handy heuristic about this: if you are interacting (directly or via a third party) with the filesystem of a service in order to use it, said service is probably solving your problem wrong.

Try `fly`. It's worth it.

[raziel2p]

Funny, I use the opposite approach. If I can't configure and manage something via the filesystem, I usually stay clear of it.

Specifically, not relying on the filesystem means I can't easily browse configuration, I can't have version control, and I can't use my configuration manager to have events trigger when things change.

[jacques_chester]

I think there's some confusion. The actual config you send to a Concourse server is on your filesystem and ideally it's checked in.

`fly` is the CLI you use to tell the server "hey, here is a pipeline config", or "hey, I've changed the config, here's the new one".

[twic]

No, i think raziel2p understands. If you're using a configuration management tool like Puppet or Ansible, by far the easiest way to manage a piece of software is through a configuration file on disk that the configuration management tool can manage directly: it's easy to see the current state, and to make changes. Anything that requires a tool or an API requires you to interpose some sort of update mechanism between the configuration management tool and the software, which doesn't have the transparency of a simple file.

[jacques_chester]

Ah, gotcha. So if I'm following this line correctly, it'll need someone to write a wrapper that detects updates to .yml files and invokes fly?

[twic]

Something like that. You could either have a little daemon that watches a file and flies it when it changes, or you could do it straight from the configuration management tool. For example, in Ansible you'd write a handler which is triggered after updating a copy of the pipeline file somewhere:

http://docs.ansible.com/ansible/playbooks_intro.html#handler...

The handler could use the command module to run fly:

http://docs.ansible.com/ansible/command_module.html