Current approach

At the moment, Travis for our packages (non-meta repositories) runs both unit tests, integration tests and behat tests; however, for behat tests, we use an extensive procedure that checks out ezplatform, changes the composer requirements to use the local version of the tested package, and run behat from there.

Consequences

The consequences are that:
a) This "install ezplatform" step is duplicated on all of the packages .travis.yml (fortunately, most of the logic lies in a script in ezplatform itself)
b) It makes testing of changes that require multiple pull-requests difficult

New approach

Another way to do this would be to use the Travis API to launch an ezplatform(-ee) build, with the tested package, and have the build execution reported back to the pull-request / branch.

Workflow and tech details

• Builds would be triggered from github using a webhook to a script hosted by us
• A travis build can be triggered using the REST API. Any element of
  .travis.yml can be customized using the request's body
• Travis can report back once finished using a hook configured in the API call that triggers the build: https://docs.travis-ci.com/user/notifications/#Configuring-webhook-notifications.

Advantages

To be written