Configuration as code #59
Description
Currently the configuration for each project is in a centralized place (.subilorc).
Most modern CI systems (if not all) support the configuration being part of the code.
With the model of "agent" that Subilo has going to that direction proposes some challenges that need to be solved.
Running the latest version
git pull should be the first step always and then we'd need to read the (potentially new) commands that need to run for the particular project.
We could default to git pull being the "before" part of running a job for projects with configuration as code or we could make that step configurable (eg. if for some other reason the project does not fetch code from a git repository)
Config conflicts
There could be conflicts between global config and project. Project config should take precedence but it would be better to find a solution that doesn't allow conflicts to happen.
Adding projects
Registering a project would still require having to ssh into the machine running the agent and make changes to .subilorc.
Enabling editing the file through the UI could be a nice improvement. Specially if Subilo could take care of the initial setup (ie. cloning the project for the first time).
Another option could be the have a directory where any subdirectory there that has a .subilofile would considered a project. I'm not a fan of this approach since there wouldn't be a source of truth of what projects are added to the agent. But is an approach that many CI systems use.