-
Notifications
You must be signed in to change notification settings - Fork 123
Conversation
.circleci/config.yml
Outdated
|
||
- run: | ||
name: dependencies | ||
command: ./.circleci/scripts/00-set-enviornment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe enviornment
should be environment
?
|
||
# Create a new multidev site to test on | ||
terminus -n env:wake "$TERMINUS_SITE.dev" | ||
terminus -n build:env:create "$TERMINUS_SITE.dev" "$TERMINUS_ENV" --yes --clone-content --notify="$NOTIFY" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@greg-1-anderson isn't this always creating the multidev from dev/master
on Pantheon, rather than the code of the branch in the external Git repository?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
build:env:create
will first create a new multidev environment from the specified base environment (here, the dev environment), and then will overlay the code found at the cwd in the new multidev.
If a multidev of the requested name already exists, then it will be re-used, and again, the code from the cwd will be pushed to this multidev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
and then will overlay the code found at the cwd in the new multidev.
Ah, I was forgetting about that part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It still seems --notify="$NOTIFY"
is running on each commit, even after a multidev exists. Do you think it makes sense to modify build:env:create
so that --notify="$NOTIFY"
only fires if the multidev doesn't already exist?
Not having multiple notifications is my only motivation for using this conditional in example-wordpress-composer
rather than just build:env:create
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's put that logic in the Build Tools plugin itself: pantheon-systems/terminus-build-tools-plugin#105
…Run behat directly, not through Composer.
The odd thing here is that the test failed when I ran behat via a Composer script instead of direct execution. Not sure if that was just a fluke. |
So, at this point the contents of the The 00-set-environment script is tied to the docker container that is being used; perhaps it could be moved into the docker container itself. Once we support multiple test platforms, we might need separate versions of this script for circle, travis, etc. (if we decide to use docker on travis). |
Things that the WordPress example project is doing that we do not do here:
Things that the Drupal example project is doing that is not needed by WordPress:
Also, both projects have different behat parameters. Perhaps these custom steps can be factored out as composer scripts, and customized in the composer.json file for the respective framework. |
I think this is important as Behat tests will make changes to content. After tests pass it would be ideal to have a multidev ready for stakeholder review. Without backup/restore of the database we would be showing off a multidev with Behat changes applied, rather than reflecting the actual content. An alternative might be to re-clone the database from another environment and then do a config import but I think a restore is faster/easier. |
This helped me avoid timeouts and other Terminus errors when using the wp-cli drive via Terminus for WordHat |
I don't think a test admin user should be left around after testing is complete. |
Those are CMS specific details and could go in Quicksilver scripts in The differences in the WordPress repo are not CMS specific but developer workflow decisions. They should be consistent between our example repos IMO. |
It might be necessary to run the wp-cli |
+1 to coming to a consensus |
Could I get a +1 on merging this PR as-is? Next step would be making QS scripts for the CMS-specific updatedb / config-import, and then tackle workflow unification decisions in follow-on issues. |
You've got my 👍 as long as we open those other issues and don't lose track of these conversations/additional work |
OK, I will make separate issues in this project for the issues raised above. |
Created #111 to keep an index to issues with active workflow unification discussion. If you create an issue for one of these topics, link to it here. I'll eventually start separate issues for each if someone else doesn't get to them first. |
Also created #112 for the Quicksilver script conversion. |
No description provided.