ddev: mkcert error on Travis upon creating the web container
Describe the bug In Travis CI environment, in a not steadily reproducible way, we face with the following error:
Failed to start schuler-scholar: web container failed: log=, err=container exited, please use 'ddev logs -s web
to find out why it failed`
After adding ddev logs
to the CI script, that’s the output of that:
+ sudo chown -R 2000:2000 /mnt/ddev-global-cache/ /home/travis/.ssh /home/travis/.drush /home/travis/.gitconfig /home/travis/.my.cnf
+ '[' -d /mnt/ddev_config/homeadditions ']'
+ cp -r /mnt/ddev_config/homeadditions/. /home/travis/
+ mkcert -install
ERROR: failed to save CA key: open /mnt/ddev-global-cache/mkcert/rootCA-key.pem: permission denied
To Reproduce
Steps to reproduce the behavior:
On a Travis-based environment, start a DDEV instance with Solr aside, skipping the configuration for mkcert
there.
Expected behavior
ddev
web container should start.
Screenshots
Version and configuration information (please complete the following information):
- Host computer OS and Version:
Build language: php
Build group: stable
Build dist: trusty
Build id: 128908179
Job id: 238529129
Runtime kernel version: 4.4.0-101-generic
travis-build version: 24382795bc479c6eb9a0651f15dd00c2dca32750
Build image provisioning date and time
Tue Dec 5 19:58:13 UTC 2017
Operating System Details
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
Release: 14.04
Codename: trusty
- Docker version information (use
docker version
) and insert it here.
docker-ce_18.06.3~ce~3-0~ubuntu_amd64.deb
- ddev version information (use
ddev version
)
v1.11.0
- config.yaml contents for the misbehaving project
APIVersion: v1.11.0
name: foobar-foobar
type: drupal8
docroot: web
php_version: "7.3"
webserver_type: nginx-fpm
router_http_port: "8081"
router_https_port: "8043"
xdebug_enabled: false
additional_hostnames: []
additional_fqdns: []
mariadb_version: "10.2"
nfs_mount_enabled: false
provider: default
hooks:
post-import-db:
- exec: drush config-set system.site name Foobar
- exec: drush en -y environment_indicator
- exec: drush cr
- exec: drush uli
post-start:
- exec: drush site-install foobar -y --db-url=mysql://db:db@db/db --account-pass=admin
--existing-config
- exec: drush en foobar_migrate
- exec: drush sapi-c
- exec: drush migrate:import --group=foobar
# For Code sniffer
- exec: composer global require drupal/coder:^8.3.1
- exec: composer global require dealerdirect/phpcodesniffer-composer-installer
# For Drupal's private files
- exec: mkdir /var/www/private
- exec: drush uli
use_dns_when_possible: true
timezone: ""
- Do you have any custom configuration (nginx, php, mysql) in the .ddev folder? If so, have you tried without them? N/A
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 39 (37 by maintainers)
Commits related to this issue
- Make sure CAROOT exists, fixes #1848 — committed to rfay/ddev by rfay 5 years ago
@rfay I’ll remove that double install workaround then soon and do the
mkcert
install. Anyways it’s better to test with HTTPS, browser-based tests could catch mixed content anomalies that would happen in production, etc.It looks to me like this stanza:
should
sudo mkdir -p $CAROOT && sudo chown -R ... && sudo chmod
before running the mkcert -install.I think your problem would go away if you installed mkcert on test runners and ran
mkcert -install
@rfay Now we caught this hiding bug. Failed job: https://travis-ci.org/Gizra/drupal-elm-starter/jobs/599102837
Successful job: https://travis-ci.org/Gizra/drupal-elm-starter/jobs/599095306
The diff between is in markdown, so we can say the source code is 100% identical.
Source code: https://github.com/Gizra/drupal-elm-starter/blob/8.x-travis-failure-trigger/ci-scripts/install_server.sh
DDEV config: https://github.com/Gizra/drupal-elm-starter/blob/8.x-travis-failure-trigger/server/.ddev/config.yaml
I’ll contact the support of Travis in the meantime, because I suspect that it might be their environment somehow as well.
@rfay https://github.com/Gizra/drupal-elm-starter/pull/224 Here we have the PR for the public repository. I’ll let you know when we have the wanted failure there, but essentially that’s the diff that caused issues for one of the projects. I might need to update DDEV version there too, I’ll see.
Thanks for the offer. As I think about more, we have 5+ client projects on DDEV, using Travis and only one fails. So it must be project specific, however on the long run, I see that by 50% chance, it succeeds. I’ll try to kill all the project specific stuff and still reproduce it, now I think i will find some time for it.