project.local.protocol=https causes checkCiConfig to fail on Travis CI

[candrews]

My system information:

• Operating system type: Travis CI
• Operating system version: trusty
• BLT version: 8.9.9

Start a new project, use blt ci:travis:init to setup CI, edit blt/project.yml setting project.local.protocol to https.

When Travis runs, it fails with this output:

[Acquia\Blt\Robo\Tasks\DrushTask] Running /home/travis/build/censored/web/vendor/bin/drush @self cache-rebuild --uri=default --yes in /home/travis/build/censored/web/docroot
Cache rebuild complete. [ok]
[Acquia\Blt\Robo\Tasks\DrushTask] Done in 8.244s
Checking for features overrides...
Checking for config overrides...
[Acquia\Blt\Robo\Tasks\DrushTask] Running /home/travis/build/censored/web/vendor/bin/drush @self cex sync --uri=default --no in /home/travis/build/censored/web/docroot
Differences of the active config to the export directory:
Collecti Config Operation
on
core.entity_view_display.node.location.tea update
ser
core.entity_view_display.node.page.teaser update
core.entity_view_display.node.page.default update
core.entity_form_display.node.page.default update
The .yml files in your export directory (/home/travis/build/censored/web/config/default) will be deleted and replaced with the active config. (y/n): n
Cancelled. [cancel]
[Acquia\Blt\Robo\Tasks\DrushTask] Exit code 75 Time 1.396s
[error] Configuration in the database does not match configuration on disk. You must re-export configuration to capture the changes. This could also indicate a problem with the import process, such as changed field storage for a field with existing content. To permit configuration overrides, set cm.allow-overrides to true in blt/project.yml.

[error] Command `setup:config-import ` exited with code 1.

[error] Command `setup:drupal:install ` exited with code 1.

01:33 total time elapsed.

blt tests:all --define drush.alias='${drush.aliases.ci}' --define tests.run-server=true --yes -v

> tests:behat

[warning] tests.run-server is enabled, but the server URL does not match Drupal's base URL.

[warning] project.local.uri = https://127.0.0.1:8888

[warning] tests.server.url = http://127.0.0.1:8888

[warning] local.extensions.Behat\MinkExtension.base_url = https://127.0.0.1:8888
[warning] Behat is not configured properly.
BLT can (re)generate tests/behat/local.yml using tests/behat/example.local.yml.
[warning] tests.run-server is enabled, but the server URL does not match Drupal's base URL.
[warning] project.local.uri = https://127.0.0.1:8888
[warning] tests.server.url = http://127.0.0.1:8888
[warning] local.extensions.Behat\MinkExtension.base_url = https://127.0.0.1:8888
[error] Behat is not configured properly. Please run `blt doctor` to diagnose the issue.
[error] Command `tests:behat ` exited with code 1.
0.654s total time elapsed.

I would expect the tests to pass. Setting project.local.protocol=http works fine.

[grasmash]

I think we can easily work around this issue by changing the following default configuration in build.yml:

tests:
  run-server: false
  # This is used for ad-hoc creation of a server via `drush runserver`.
  server:
    port: 8888
    url: http://127.0.0.1:${tests.server.port}

To:

tests:
  run-server: false
  # This is used for ad-hoc creation of a server via `drush runserver`.
  server:
    port: 8888
    protocol: ${project.local.protocol}
    url: ${tests.server.protocol}://127.0.0.1:${tests.server.port}

[danepowell]

@candrews in the meantime I think you can work around this by setting tests.server.url to the appropriate value (i.e. https://127.0.0.1:8888) in project.yml

[candrews]

@danepowell I don't think that workaround works.

I added this block to blt/project.yml:

tests:
  server:
    protocol: ${project.local.protocol}
    url: ${tests.server.protocol}://127.0.0.1:${tests.server.port}

Then Travis failed with this message:

blt tests:all --define drush.alias='${drush.aliases.ci}' --define tests.run-server=true --yes -v

> tests:behat
[info] Killing all processing containing string 'runserver'...
[info] Killing all processes on port '8888'...
[info] Running server at https://127.0.0.1:8888...
[info] Waiting for response from https://127.0.0.1:8888...
[info] Waiting for response from https://127.0.0.1:8888...
<lots more waiting... then...>
[error] Timed out.
[Tue Oct 24 20:13:19 2017] 127.0.0.1:45858 Invalid request (Unsupported SSL request)
[Tue Oct 24 20:13:20 2017] 127.0.0.1:45898 Invalid request (Unsupported SSL request)

I think the server at 127.0.0.1:8888 is http, not https, hence the failure.

[grasmash]

Invalid request (Unsupported SSL request) hmmm. I wonder if drush runserver doesn't support SSL? Or perhaps you need to modify your Behat config to ignore invalid certs:

https://github.com/acquia/blt/blob/9.1.x/template/tests/behat/example.local.yml#L39

  extensions:
    DMore\ChromeExtension\Behat\ServiceContainer\ChromeExtension: ~
    Behat\MinkExtension:
      browser_name: chrome
      javascript_session: default
      # configure the base url for your site
      base_url: ${project.local.uri}
      # set default command for "Show last response" step.
      show_cmd: "open %s"
      # use the following lines to disable SSL authentication for goutte.
      # goutte:
      #   guzzle_parameters:
      #     redirect.disable: true
      #     ssl.certificate_authority: system
      #     curl.options:
      #       CURLOPT_SSL_VERIFYPEER: false
      #       CURLOPT_SSL_VERIFYHOST: false
      #       CURLOPT_CERTINFO: false
      #       CURLOPT_TIMEOUT: 120

Uncomment the segment under "use the following lines to disable SSL authentication for goutte."

[candrews]

drush runserver doesn't support https.

I've already tested it with the settings necessary to ignore invalid ssl certificates because that's necessary to get blt test:all to work locally when project.local.protocol is https.

[candrews]

Perhaps, instead of using drush runserver, blt could instead use https://github.com/mpyw/php-hyper-builtin-server because it supports both http and https (so we can do whatever is appropriate)?

[danepowell]

I definitely appreciate that there's a use case for HTTPS, but this is the first time I've seen anyone request it. I'm reluctant to add a new dependency when the drush server has worked so well for so long.

However, you should be able to support php-hyper-builtin-server on your project by overriding tests:server:start.

Documentation on overriding BLT commands: https://github.com/acquia/blt/blob/9.1.x/readme/extending-blt.md#replacingoverriding-a-robo-command
tests:server:start is defined here: https://github.com/acquia/blt/blob/9.1.x/src/Robo/Commands/Tests/ServerCommand.php

You'd basically just copy that class and swap out the calls to Drush runserver with calls to php-hyper-builtin-server.

If that works out it might be worth documenting in case future projects need HTTPS.

[candrews]

this is the first time I've seen anyone request it

Isn't every request requested for a first time? :) Furthermore, not all users report issues; changes are, I'm not the first person to encounter this error, I'm just the first person to put in the effort to report it.

HTTPS is becoming increasing prevalent. As BLT gains more users, it's increasingly likely that they'll want HTTPS support. Furthermore, BLT should encourage and actively try to make HTTPS as easy as possible because it's in everyone's best interest to have secure software.

Notably, I'm just giving php-hyper-builtin-server as an example; any other approach to support HTTPS would also be valid, of course.

[danepowell]

Fair enough... I'm not sure I can commit to this but I'll leave it open for discussion.