Closed enotick closed 4 years ago
@enotick Well, this pull request can't be merged as-is because the commits contain the robots.txt and settings.php files which should not be checked into the drupal-project itself. Normally, we would add those to the gitignore file, but we actually do want people to check them in when they clone this repo for their own project.
However, I'm also not sure how feedback on the status is supposed to be communicated to the user. There are echo statements saying when things have worked, but where is that output actually shown? Is there some place the feedback is shown in the pantheon dashboard that I am not aware of?
I was thinking that if we wanted to incorporate the cache clears and config imports to the CI workflow, it would have to involve running terminus commands during the Circle build process, like in this example: https://github.com/pantheon-systems/example-drops-8-composer/blob/master/.ci/deploy/pantheon/dev-multidev
However, that involves using a different circle image that brings in a bunch of build tools, which makes everything a lot more complicated.
@enotick Well, this pull request can't be merged as-is because the commits contain the robots.txt and settings.php files which should not be checked into the drupal-project itself. Normally, we would add those to the gitignore file, but we actually do want people to check them in when they clone this repo for their own project.
However, I'm also not sure how feedback on the status is supposed to be communicated to the user. There are echo statements saying when things have worked, but where is that output actually shown? Is there some place the feedback is shown in the pantheon dashboard that I am not aware of?
I was thinking that if we wanted to incorporate the cache clears and config imports to the CI workflow, it would have to involve running terminus commands during the Circle build process, like in this example: https://github.com/pantheon-systems/example-drops-8-composer/blob/master/.ci/deploy/pantheon/dev-multidev
@mikemccaffrey I am sorry but I respectfully disagree. There is no problem to have settings.php and robots.txt checked into the project. As long as they don't have hosting / projects specific info. settings.local.php is a different story. Settings.php is useful to have checked in especially since it can contain great presets for the environment indicator and splits that makes things easier form the get go. The key is to make it abstract enough. I've been using this technique for years and it worked well for our clients. The same is with robots.txt
Answering your second question the feedback messages are displayed in the terminal - it's normal pantheon communication. When circle deploys it will also be shown in CI output there as with any terminal communication.
We could run commands with terminus as you suggested - this is another approach but that said there are no major disadvantages or advantages of either one. With terminus during circle deployment in my experience it was heavier than with quick silver.
@RobLoach @mikemccaffrey cleaned it up please review and let me know what you think. I will move settings.php environment indicator into a different PR. Thanks. :)
EDF trials
Move to a repo with quicksilver scripts in the repo.
@mikemccaffrey @RobLoach I have changed the workflow stage to be on sync_code it only occurs on dev and multidev from what I see. https://pantheon.io/docs/quicksilver