Add --pr-only option to build:env:create and build:env:push

[ataylorme]

Example WordPress Composer is only creating multidevs environments on Pantheon when a pull request is created. See this comment thread for reasoning.

There is logic in Example WordPress Composer to determine if a deployment to Pantheon should happen (e.g. is the build a pull request). Ideally this logic can live in the Terminus build tools plugin behind a --pr-only option for build:env:create and build:env:push

[stevector]

CircleCI already has it's own option for only building on pull request. I think Travis does too. So this option would be for the usecase of a team that wants unit tests/code sniffing even if there isn't a pull request but not deploys to Pantheon?

[ataylorme]

@stevector that's correct. This idea is that developers can create a branch and push to GitHub as they have commits, even if it's not ready for review by others. At this point code sniffing and unit tests would run. If those fail the code can be refactored. This should be a quick, iterative process and deploying to Pantheon and running Behat each time will slow things down when work isn't ready to be reviewed anyway.

Once the work is complete and ready for review by others a pull request is created. At that point a code review on GitHub can commence and a multidev on Pantheon is created and linked in the pull request for review of the changes in a fully built site. Behat tests can also run at this point.

The multidev environments on Pantheon are also named pr-[n] to correspond with the pull reques tissue number. This makes identifying which multidev belongs to what code on the external repository easier. When truncating the GitHub branch name to 11 characters for multidev use this can become harder to decipher and has the possibility for collisions.

See these comments for further discussion as well.

[greg-1-anderson]

Wouldn't it be better to have a has pull request method, and have the client wrap the call to build:env:push in an if statement? I have the same basic opinion about build:project:create. The flag is somewhat more defensible there, but I feel these use cases are different than the filtering option of a similar name on build:env:delete, and the pattern isn't as applicable.

[ataylorme]

Closing in favor of #118