Open ataylorme opened 5 years ago
@rvtraveller I met with an agency today who was using the Quicksilver deploy_product
(new site creation) hook to ping Zapier, which called the Gitlab API and set up a new project in reverse (Pantheon site first, GitLab second).
They want users in their organization to be able to create sites on Pantheon at-will while still getting a CI workflow.
I'm working if we could do something similar with build:project:create
once there is support for an existing Pantheon site.
See an old proof of concept where I used Quicksilver and wp-cli to install themes and plugins on a new Pantheon install after site creation. Not directly related, but it gives a good idea of the flexibility of Quicksilver.
Maybe we could have a "CI" upstream that created a Pantheon site first then scaffolded CI?
It seems that the overwrite option is too dangerous, and the utility of the function does not justify the risk.
The idea of starting off CI creation from the dashboard is interesting and sounds very useful. Maybe an overwrite is not necessary if the upstream is based on example-*-composer?
Or we have a modified version of the empty upstreams with nothing but quicksilver scripts that run on site creation. Then an override after CI is set up seems less destructive
I'm still kind of worried about someone using the destructive option and pointing at the wrong site. Not an issue from the Quicksilver-related starting point, but if someone made a mistake on the command line, that would be unfortunate.
It would be best if this could be made to work without force-push.
I'm still kind of worried about someone using the destructive option and pointing at the wrong site
I agree. If a backup is run before the force push that would help.
Not an issue from the Quicksilver-related starting point
This agency was not using Composer, so after the external Git provider project was created they pushed the Pantheon site there as-is. With a Composer set up, we could use the existing framework of Quicksilver Pushback that modifies .gitignore
before pushing to the external Git provider.
Some advantages they mentioned doing it this way:
This should provide a warning and confirmation as the existing site repo and external repo will be overwritten with a force push.