search

silverstripe-archive / deploynaut

A web based tool for performing deployments
BSD 3-Clause "New" or "Revised" License
71 stars 26 forks source link

Allow modification of pipeline config by non-privileged users #86

Open chillu opened 10 years ago

chillu commented 10 years ago

Scenario: Default smoke tests in CWP check for a 200 HTTP code on prod, but I want to secure the prod env with basic auth since the site isn't live yet (and we plan to use the env for demos, security testing, etc). Currently this requires me to ask CWP staff to modify the YAML config.

It would be good if that's a self-service capability. Allowing full access to the YAML config is probably a bit much, but we could provide a simple placeholder edit interface which is then inserted into the YAML alongside the deploynaut frontend (outside of CMS).

chillu commented 10 years ago

In terms of CWP capabilities, Stephen suggested we could also solve this by giving Dev Managers with pipeline approval rights the ability to do direct deployments as well (which makes sense to me)

ss23 commented 10 years ago

Pinging @tractorcow

tractorcow commented 10 years ago

The configuration of smoke tests has always been a bit of a sticky point... it's the one part of the configuration which is the most variable. It could be argued that it shouldn't be in the pipeline at all, and perhaps could be moved to a dataobject instead, making it completely independent of the yml config.

However, even in this case, it probably should be managed via the CMS. If a user doesn't have CMS access then they probably shouldn't be granted permission to alter configuration in any case. I don't like the idea of introducing front-end CMS capabilities. That would just circumvent the point in having a CMS at all. It would be better to allow CMS access, and ensure that specific fields were made editable or not via permissions.

I don't really want to discuss CWP here since this isn't the appropriate location, so I won't. :) Want to catch up on skype?

sminnee commented 10 years ago

I would suggest that the pipeline is configured to say "get my smoke test steps from this file in the repo". For example, it might look for ./tools/smoke-test and execute that via whatever mechanism makes sense.

That way, we can meet @chillu's requirement without needing to change Deploynaut's permission model. It also means that: