Generic Environment Sync action in Web UI
tnelson-doghouse opened this issue · 8 comments
We would like a task that replaces drush sync in the web UI (but preferably isn't drush specific).
- It will copy databases and assets/files between environments
- For preference, it will be flexible about source and destination environments, but will only allow people to run it if they have permissions to the destination environment
- For bonus points, if this can let you choose a sanitised database, that would be great, but I don't expect this.
HTH,
We're overhauling advanced tasks/custom tasks in Lagoon, and the goal will be to improve the documentation around this that will allow users to create these tasks themselves.
Lagoon probably won't ship with any built-in tasks in the future, because we plan to deprecate those standard drush based tasks eventually.
While I agree with deprecating the drush-based ones, I still think there should be a few that can be added just by adding something to .lagoon.yml or something. I shall look forward to the revamped documentation :) . Is there a ticket we can follow for the advanced tasks overhaul?
While I agree with deprecating the drush-based ones, I still think there should be a few that can be added just by adding something to .lagoon.yml or something. I shall look forward to the revamped documentation :) . Is there a ticket we can follow for the advanced tasks overhaul?
I will say now that tasks defined in the .lagoon.yml will probably not be a thing. The management of these becomes too difficult to know which environment, where it lives etc..
We will provide some example tasks that will perform some things like replacements for the more common tasks (file sync, db sync), but won't be ones that would include sanitising databases, etc. But from the examples, you would be able to copy and extend it to do whatever additional functionality you would want.
As for which ticket to follow, I guess this would be one of them, additionally:
We haven't road mapped anything related to this work specifically, so there is no ETA or planned/designed work for this. There is current documentation for creating custom tasks now, but this will eventually be deprecated once we decide on the new task API.
- Agreed that general defining of tasks in .lagoon.yml shouldn't be a thing
- I was thinking that in some specific cases (eg. this one, and probably 3-5 others) that it might be worthwhile having a special enabling thing that works just for those specific tasks
- Agree that DB san doesn't belong as one of those special tasks, just the really common ones.
Good info on the tickets and status -- thanks!
- Agreed that general defining of tasks in .lagoon.yml shouldn't be a thing
- I was thinking that in some specific cases (eg. this one, and probably 3-5 others) that it might be worthwhile having a special enabling thing that works just for those specific tasks
The problem of managing things in the API via .lagoon.yml is a real bad one though. Builds are almost completely decoupled from the API by design (outside of any pre/post rollout tasks that users define), so introducing this mechanism into the build phase that would call back to the API to check or modify something in the API that could then effectively be overridden by a .lagoon.yml from another environment is why this is a bad idea.
The logic to work out if a task can or can't be run on a specific environment because the .lagoon.yml says so becomes super complex and difficult to maintain, so the simplest solution is to not do it it all via .lagoon.yml.
As we get closer to designing what custom tasks v2 looks like, tickets will get updated. But generally, it will be managed via the API/CLI only, not via builds. But that doesn't stop you from doing crazy things in your pre/post rollout tasks (you just own those things)
OK. Was just trying to make it more straightforward. But if it's a CLI tool thingy, I can live with that. Just means more scripting :) .
Edit: Straightforward from a Dev-using-lagoon POV, not your POV.
OK. Was just trying to make it more straightforward. But if it's a CLI tool thingy, I can live with that. Just means more scripting :) . Edit: Straightforward from a Dev-using-lagoon POV, not your POV.
Well since we haven't decided on the API, or designed anything yet, and we've only had discussions. There isn't really anything certain to compare it to yet. The solution we have discussed internally so far under would be far more configurable than the current custom tasks implementation.
Just for transparency, the initial discussions have been down this path, which is probably more than suitable.
- being able to create custom tasks at the organization level
- creating rule sets on the task/in the organization that would allow you to restrict
- which projects or environments can run the task (regex/pattern matching etc.)
- which group within the org can run the task (based on role still)
- which environment types will be able to run the task (dev or prod envs)
- which permission level can view/execute the task (guest, maintaner, etc..)
Since tasks are wrapped in permissions (ie who can execute, who can add them, which tasks are available to which project etc..), having some way to enable to disable tasks in the .lagoon.yml would not be able to override the permissions of a task, as that would potentially allow someone with git access to change the permission required to perform a task, or just enable a task randomly which maybe you don't want them to do. So you'd still need some way to limit which tasks could be requested/enabled/disabled in the .lagoon.yml still.
Tasks at the org level would definitely be a help.