Create bin/* files #4
Conversation
There was a problem hiding this comment.
Hmm, I'm slightly in two minds about this now. It means that individual WordPress projects can be self-contained (aside from the docker-compose,whippet and git dependencies), but what happens if we want to amend/add new .bin/ scripts? We'd have to do that on a project-by-project basis.
And ideally it'd be good if internal.sh always looks the same, with the project-by-project differences being contained in a .yml file. But that's a bigger change.
These are more points for discussion than firm requests for changes though.
|
This does something along the lines of what we might want for taking theme/plugin activation details from a .yml file: https://github.com/philcook/squick |
bin/wpc_init
Outdated
|
|
||
| docker-compose up -d | ||
| `dirname $0`/../setup/external.sh | ||
| docker-compose exec wordpress /usr/src/app/setup/internal.sh |
There was a problem hiding this comment.
I'm finding this doesn't always work first time through, depending on how long external.sh takes to run. The mysql container takes quite a while to get fully running and connected, so that can result in the internal.sh script erroring out because it can't connect to the db. But if you run setup.sh again straight afterwards, it works.
There was a problem hiding this comment.
And just checking whether mysql is accepting connections on port 3306 doesn't seem to be enough - even then it can still fail. Grr.
There was a problem hiding this comment.
Hmm. Perhaps we should leave out the docker-compose up -d line, and ask users to execute it manually (and warn them that ./bin/setup might fail if MySQL isn't running yet)?
There was a problem hiding this comment.
That might be the easiest way to solve it for now - docker-compose up is how users would be starting a site generally, so it wouldn't be inconsistent to ask them to do it the first time they set up the site, just with an extra step afterwards.
No description provided.