First off, congrats! Waypoint seems like a really interesting project, I’m really excited by the potential of separating the deploy/release phases!
I haven’t had much of a chance to dive into the code beyond skim reading some RPCs, but it seems that at the moment the waypoint configuration for a project is stored locally on the developer’s machine, and the waypoint CLI instructs the server to enqueue specific jobs based on the contents of the local config file?
I think I remember some mention during hashiconf digital that waypoint will eventually allow folks to perform deploys/releases through an API or slack. Would each of these clients need to have a local copy of the project’s waypoint configuration, or would waypoint get the config by some other means? e.g. would the build step upload the waypoint configuration that was in use at that moment, and that should be used by all subsequent operations for that build?
On a related note, do you folks have plans to allow the server to have some control over project configuration?
I agree that moving an application’s deployment configuration closer to the code is a good thing, but I’m worried that having to maintain each of these config files individually could make it more difficult to standardise deployment pipelines. If there are parts of your deployment workflow that you want every project to implement, how would you ensure that’s happening without manually auditing every config file?
As an example, the documentation for hooks demonstrates how hooks can be used to record an audit log of actions, but if this audit log relies on an entry in every application’s waypoint config file it’ll be quite difficult to verify that the audit log is covering all projects correctly without inspecting the config file for each and every project. Another situation where you might need to enforce consistency is ensuring all projects are using a specific version of a plugin.