Feature/docker for testing #308

TomHAnderson · 2018-04-02T06:15:13Z

New Doctrine modules are coming down the pipe. To avoid trying to manipulate my bare metal I wrote this Docker container set for use in development and testing.

This isn't normal for Zend packages so please let me know your thoughts on including Docker container with complex repositories and let's get this merged and ready for the upcoming Doctrine changes.

coveralls · 2018-04-02T06:23:52Z

Coverage remained the same at 53.925% when pulling 05aa000 on TomHAnderson:feature/docker-for-testing into 6d45064 on zfcampus:master.

michalbundyra · 2018-04-02T07:45:26Z

@TomHAnderson I like that idea, I'll have a look on it later on ! Thanks a lot!

TomHAnderson · 2018-04-03T05:55:54Z

Before you approve this, if you choose, see @Ocramius comment on the linked doctrine PR.
If you think this should be a part of this module I think the mongodb should be part of the php build and not its own container thereby simulating (more closely) the Travis environment.

Ocramius · 2018-04-03T05:59:55Z

If you plan to use docker in the examples, then make sure that the project eats its own dogfood and has a pipeline entry (in CI) that uses the advertised docker setup for testing too. It is extremely painful for users to jump into a project and find out-of-sync startup scripts and such 😱

TomHAnderson · 2018-04-20T22:10:19Z

This has been rewritten to a minimal Docker footprint

…ote to account for unknown order

TomHAnderson · 2018-04-22T06:01:41Z

Includes a fix to a unit test which changed order.

TomHAnderson · 2018-04-22T06:03:38Z

@Ocramius was right, as usual, so I added docker-compose to travis testing. I had to use a script because I didn't know how to escape a pipe to run all the commands on the same command line.

Docker is php:latest so all 7.2 tests also test Docker with the same dependencies as the test.

thomasvargiu

With this changes you can simplify the environment, speeding up tests, and making it more flexible.
You can even use docker configuration for multiple PHP versions using environment variables in travis-ci.

A contributor can easily start tests with one single command:

docker-compose run --rm php

thomasvargiu · 2018-04-22T11:20:21Z

docker/Dockerfile

@@ -0,0 +1,11 @@
+FROM php:latest


You can use an alpine image to speed up tests, something like this:

ARG PHP_VERSION=7.2 FROM php:${PHP_VERSION}-alpine RUN apk add --no-cache \ autoconf \ make \ g++ RUN pecl install mongodb && docker-php-ext-enable mongodb RUN set -o pipefail && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer RUN echo -e '#!/bin/sh' >> /usr/local/bin/entrypoint.sh \ && echo -e 'while ! nc -z ${MONGO_HOST:-mongo} ${MONGO_PORT:-9000}; do sleep 1; done' >> /usr/local/bin/entrypoint.sh \ && echo -e 'exec "$@"' >> /usr/local/bin/entrypoint.sh \ && chmod +x /usr/local/bin/entrypoint.sh WORKDIR /docker ENTRYPOINT ["/usr/local/bin/entrypoint.sh"] CMD ["./vendor/bin/phpunit"]

You can specify a build argument to say which image to build.
I also added an entry-point to wait mongodb service to be up.

Obviously you should change code where mongodb host is localhost, using environment variables $MONGO_HOST and $MONGO_PORT

thomasvargiu · 2018-04-22T11:21:39Z

.travis.yml


 before_install:
  - if [[ $TEST_COVERAGE != 'true' ]]; then phpenv config-rm xdebug.ini || return 0 ; fi
+  - if [[ $DOCKER == 'true' ]]; then docker-compose up -d; fi


We don't need this

thomasvargiu · 2018-04-22T11:22:41Z

.travis.yml

@@ -85,6 +90,7 @@ install:
 script:
  - if [[ $TEST_COVERAGE == 'true' ]]; then composer test-coverage ; else composer test ; fi
  - if [[ $CS_CHECK == 'true' ]]; then composer cs-check ; fi
+  - if [[ $DOCKER == 'true' ]]; then docker exec -it $(docker ps -f name=zfapigilitydoctrine_php_1 | awk '{print $1;}' | tail -n 1) bash /docker/.travis.docker; fi


We can directly run:
docker-compose run --rm php with the Docker file in my previous comment

thomasvargiu · 2018-04-22T11:32:45Z

docker-compose.yml

@@ -0,0 +1,15 @@
+version: "3"


docker-compose cam be changed with:

version: "3" services: php: build: context: . args: - PHP_VERSION=${PHP_VERSION:-7.2} dockerfile: docker/Dockerfile depends_on: - mongo volumes: - ./:/docker mongo: image: mongo:latest

You can optionally pass PHP_VERSION as environment variable in .travis.yml, using it for different PHP versions

thomasvargiu · 2018-04-22T11:34:03Z

docker/connect

@@ -0,0 +1 @@
+docker exec -it $(docker ps -f name=zfapigilitydoctrine_php_1 | awk '{print $1;}' | tail -n 1) bash


With previous changes, you don't need this

thomasvargiu · 2018-04-22T11:35:48Z

.travis.docker

@@ -0,0 +1,3 @@
+cd /docker


With previous changes, you don't need this anymore

TomHAnderson · 2018-04-22T18:04:27Z

Tested failed unit tests in docker fail the build tested with #310

TomHAnderson · 2018-04-23T04:19:54Z

Starting with @thomasvargiu suggestions I've engineered the tests to run Docker for every test. You can compose a docker container with

docker-compose build --build-arg PHP_VERSION=5.6

All travis tests use the current testing version of PHP in the Docker tests.

thomasvargiu · 2018-04-22T20:01:51Z

docker-compose.yml

+    volumes:
+      - ./:/docker
+    environment:
+      - MONGO_HOST=mongo


These are the default one, you can avoid these environment variables, because you can override it in travis.yml

Running locally the environment variables are correct. The "default" ones are localhost/27017. We cannot move these to .travis.yml only because the local Docker needs them too.

Additionally this Docker configuration is correct for the docker-compose and the current project. Moving the docker connect information to environment variables means we're encouraging the user to setup their own hardware to run the repository which is fine if they don't want to use Docker.

thomasvargiu · 2018-04-22T20:03:33Z

test/config/ODM/local.php

@@ -8,8 +8,8 @@
    'doctrine' => [
        'connection' => [
            'odm_default' => [
-                'server' => 'localhost',
-                'port' => '27017',
+                'server' => (getenv('MONGO_HOST')) ? getenv('MONGO_HOST') : 'localhost',


Simplify it with ?: 'localhost'

and also remove brackets around getenv('MONGO_HOST')

thomasvargiu · 2018-04-23T09:10:46Z

.gitignore

@@ -4,3 +4,4 @@ test/data/
 test/assets/module/*/config/module.config.php
 clover.xml
 coveralls-upload.json
+docker/data/


I don't see any usage of this folder, can we remove it?

Was a remnant; removed

thomasvargiu · 2018-04-23T09:14:56Z

Dockerfile

+	openssl-dev
+
+RUN echo "memory_limit=2G" >> /usr/local/etc/php/php.ini
+RUN if [ ${PHP_VERSION:0:3} == "5.6" ] ; then pecl install mongo && echo "extension=mongo.so" >> /usr/local/etc/php/php.ini ; else pecl install mongodb && docker-php-ext-enable mongodb ; fi


Would be better to make it explicit with another build argument? What do you think?

Because we use TRAVIS_PHP_VERSION a build argument is not the correct solution here. Comparing the substr of the PHP_VERSION works nicely.

The point that @thomasvargiu is making is that we can provide this as a flag instead of a version number via a build argument in docker-compose.yml (as he demonstrates in another comment). If the initial docker-compose (build|up --build) operation includes appropriate ENV variables, these can be referenced via docker-compose.yml build arguments and referenced in the Dockerfile. That would arguably be better than parsing versions in the Dockerfile, and make it more explicit the scenarios we are testing.

michalbundyra

@TomHAnderson In general looks good, just small issues, agree with @thomasvargiu comments.

Thanks for doing it. Great job!

michalbundyra · 2018-04-23T12:19:03Z

test/config/ODM/local.php

@@ -8,8 +8,8 @@
    'doctrine' => [
        'connection' => [
            'odm_default' => [
-                'server' => 'localhost',
-                'port' => '27017',
+                'server' => (getenv('MONGO_HOST')) ? getenv('MONGO_HOST') : 'localhost',


and also remove brackets around getenv('MONGO_HOST')

michalbundyra · 2018-04-23T12:19:44Z

Dockerfile

@@ -0,0 +1,21 @@
+ARG PHP_VERSION=7.2


Let's move it into .docker directory and add this directory to .gitattributes (also other files with docker configuration)

The only files with Docker configuration are Dockerfile and docker-compose.yml. Adding these to .gitattributes is fine but creating a directory for the Dockerfile isn't necessary.

If we eventually add more assets, however, we'll want to create that directory. I'd rather create it now so that once that happens, existing contributors are not then confused about where the files moved.

michalbundyra · 2018-04-23T12:21:27Z

DOCKER.md

@@ -0,0 +1,33 @@
+# Docker for Development


Maybe we don't need separate file and we should have this as a section in CONTRIBUTING.md only? @weierophinney what do you think?

I agree; add this to the existing CONTRIBUTING.md file.

thomasvargiu · 2018-04-23T16:03:37Z

.travis.yml

@@ -85,6 +80,7 @@ install:
 script:
  - if [[ $TEST_COVERAGE == 'true' ]]; then composer test-coverage ; else composer test ; fi


We should use docker here too. We need to install xdebug on the docker image and then we can run tests with coverage:

$ docker-compose run --rm php ./vendor/bin/phpunit --colors=always --coverage-clover clover.xml

or, for test only:

$ docker-compose run --rm php ./vendor/bin/phpunit --colors=always

Coverage is only tested on one matrix element. The output of running coverage on Docker would not be used. I don't think Docker coverage is necessary. Is there a place the output would be used I'm not seeing?

@TomHAnderson We need to find a way to load xdebug extension only for coverage test.

I think should be better to create a .docker directory to put there docker files as @webimpress suggested.

Then we could:

Write the entry point file and use COPY or ADD in the Dockerfile, without to write it "on the fly" building the image

Install xdebug extension, without enabling it

Create sh commands and copy them in the Dockerfile image

Then we can use a test-with-coverage script that will enable xdebug first:

#!/bin/sh docker-php-ext-enable xdebug \ && ./vendor/bin/phpunit --colors=always --coverage-clover clover.xml

What do you think?

I don't understand the need for coverage inside Docker. What benefit do we get?

@TomHAnderson My idea is that if we are implementing docker, we should use it for everything.

It's not just a coverage, but are tests too. Right now tests are executed 2 times. First in the travis-ci environment (that it's different from the container) with coverage, then from the container.

I think we should use every command from the container, even composer install and php-coveralls.

After all these changes, we don't need to do anything on travis-ci environment, and then we can use a simple image on travis.

It's just my opinion and a suggestion :)

I understand that, thanks.

In this same thread @Ocramius suggests doing inside (Docker) and out (Travis) testing: #308 (comment)

@webimpress I need sign-off from you too before I'm going to go with a Docker-only approach to unit tests.

I get the reasoning from @Ocramius , and generally agree. The idea should be to run the tests via docker always, for every environment, and not using the travis-ci environment; the rationale is to ensure that the CI environment mimics the environment maintainers use.

That said: only do it if it can be feasibly setup. If this is going to take you days to accomplish, then I'm not 100% convinced it's worth it; in that case, the docker setup is simply so contributors do not need to have the required services (mongo, RDBMS systems, etc) running on their own machine, nor need to configure a phpunit.xml with the specifics of their own services.

If it is possible to do easily, let's do it. Use build arguments to do things like enable xdebug and indicate test coverage should be run.

thomasvargiu · 2018-04-23T16:04:35Z

.travis.yml

@@ -85,6 +80,7 @@ install:
 script:
  - if [[ $TEST_COVERAGE == 'true' ]]; then composer test-coverage ; else composer test ; fi
  - if [[ $CS_CHECK == 'true' ]]; then composer cs-check ; fi
+  - docker-compose run --rm php


This is duplicated, it's the 2nd time tests are executed

Correct, we want to run tests in Travis and run them again in Docker.

TomHAnderson · 2018-04-26T18:53:32Z

I fixed xdebug. You didn't read slide 11: https://docs.google.com/presentation/d/1KhcfyU4nKVUoaTczCuMPNVymw3GaTWrtfUTwB-TzJrs/edit#slide=id.g378fb9fb7b_0_99

michalbundyra

@TomHAnderson Some notes to improve a bit documentation and it looks GREAT to me 😃

michalbundyra · 2018-04-26T21:25:12Z

.travis.yml

  - stty cols 120 && composer show

 script:
  - if [[ $TEST_COVERAGE == 'true' ]]; then composer test-coverage ; else composer test ; fi
  - if [[ $CS_CHECK == 'true' ]]; then composer cs-check ; fi

 after_script:
-  - if [[ $TEST_COVERAGE == 'true' ]]; then travis_retry php vendor/bin/php-coveralls -v ; fi
-
-notifications:


Not sure why it is removed, we need it back.

michalbundyra · 2018-04-26T21:29:41Z

CONTRIBUTING.md

+Next, from the root directory of this project, run
+
+```
+docker-compose build --build-arg PHP_VERSION=7.2 --build-arg XDEBUG=0 --no-cache php


I think we can simplify it here:

$ docker-compose build

because as said above PHP_VERSION=7.2 and XDEBUG=0 are default values. Then we should say if you want customize your container with different php version or enabled xdebug run:

$ docker-compose build --build-arg PHP_VERSION=7.1 --build-arg XDEBUG=1

(not sure also if we need --no-cache param - I need to check it).

I like --no-cache in .travis.yml. I had instances using cached build 'parts' with php 5.6 used for all builds while testing. Could have been anything but I think Docker doesn't consider build parameters when cache is enabled.

michalbundyra · 2018-04-26T21:31:06Z

CONTRIBUTING.md

+To connect to the php container for development run
+
+```
+docker-compose run php bash


I think we need here also --rm param.

Developing locally it's not necessary to remove the container each time. But putting it in the docs is fine by me.

michalbundyra · 2018-04-26T21:32:27Z

CONTRIBUTING.md

+docker-compose run php bash
+```
+
+### RUNNING UNIT TESTS IN THE CONTAINER

 First, use [Composer](https://getcomposer.org) to install all dependencies:


We don't need that anymore as it is installed on docker. Just we need to note that following commands have to be run in docker container (so after connection as described in previous section).

But it isn't installed in docker. Travis runs composer. A fresh copy of the module and running Docker will not run composer.

It is installed in our docker container:
https://github.com/zfcampus/zf-apigility-doctrine/pull/308/files#diff-ed3ef792c56bca0b45e534f8b1444c01R15 :)

Hah, sorry, of course, composer is installed but dependencies are not :) I red this paragraph wrong.

michalbundyra · 2018-04-26T21:33:58Z

CONTRIBUTING.md

+You may run the unit tests through the container without running bash via
+
+```
+docker-composer run --rm php


I removed the command form Dockerfile so it is no longer working. In previous section we already have how to run tests. We can note that is it possible also tu run tests or just command using:

$ docker-compose run --rm php composer test

michalbundyra · 2018-04-26T21:35:02Z

docker-compose.yml

+  php:
+    build:
+      context: .
+      dockerfile: docker/Dockerfile


I think we should have .docker directory instead. I've seen it somewhere and I think it's better convention.
In other repos we usually uses .ci dir for travis config.

michalbundyra · 2018-04-26T21:35:48Z

docker/Dockerfile

+ARG PHP_VERSION=7.2
+FROM php:${PHP_VERSION}-alpine
+
+ARG XDEBUG=0


Just to note: this is really important !! MUST BE HERE, cannot be above FROM :) Thanks @TomHAnderson !!

michalbundyra · 2018-04-26T21:36:23Z

docker/Dockerfile

+
+RUN echo -e 'memory_limit=2G' > /usr/local/etc/php/conf.d/memory.ini
+RUN set -o pipefail && curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer
+RUN if [ ${PHP_VERSION:0:3} == "5.6" ] ; then \


I was trying it before, and I think we can just have here $PHP_VERSION == "5.6"

No-can-do. Removing the substr and brackets breaks the build.

Docker installs v 5.6.16 or something so it's not about the parameter Docker accepts, it's about the value Travis supplies.

michalbundyra · 2018-04-26T21:36:38Z

docker/Dockerfile

+    else \
+        pecl install mongodb && docker-php-ext-enable mongodb ; \
+    fi
+RUN if [ ${XDEBUG} == "1" ] ; then pecl install xdebug && docker-php-ext-enable xdebug ; fi


Also here probably we don't need {}

Maybe, but I'm keeping them.

I think ${VAR} converts $VAR to a string. For best flexibility, if this is true, then we should keep it as ${XDEBUG} as a user could use --build-arg XDEBUG=1 or --build-arg XDEBUG="1"

michalbundyra · 2018-04-27T06:34:16Z

.gitattributes

@@ -5,3 +5,5 @@
 .travis.yml export-ignore
 phpcs.xml export-ignore
 phpunit.xml.dist export-ignore
+docker-compose.yml export-ignore
+Dockerfile export-ignore


Missed it before: we need to have here the whole /.docker/ directory, not just the Dockerfile.

Done following test example in same file

thomasvargiu · 2018-04-27T09:34:44Z

Nice work @TomHAnderson!

Other proposals:

Ignore the `docker-compose.yml` file FROM VCS

Usually in projects the docker-compose.yml is ignored from VCS to let the user to change it. We could rename it in docker-compose.yml.dist and add docker-compose.yml to .gitignore. In travis-ci we can copy it before to execute commands and tests.

We let the user to use the default image with the "latest" PHP version but if he wants to change it in different environment can easily change it. An example could be:

A contributor wants to test it against different PHP versions:

version: "3"
services:
  php71:
    build:
# .....

  php72:
    build:

And the user could easily run docker-compose run --rm php71 on his host.

I'm just suggesting to ignore the docker-compose.yml file, not to change it.

Move the entrypoint to a file

Since we have a .docker directory, we can move the entrypoint script to an external file and change the Dockerfile with:

# ...
COPY ./entrypoint.sh /usr/local/bin/entrypoint.sh

You can chmod +x it on VCS or building the image.
The Dockerfile will result more clear.

@TomHAnderson @webimpress what do you think?

michalbundyra · 2018-04-27T09:40:37Z

@thomasvargiu

Ignore the docker-compose.yml file FROM VCS

Not sure about it. If you want to test with different PHP version you can do:

$ docker-compose build --build-arg PHP_VERSION=7.1

and then:

$ docker-compose run --rm php composer test

(or maybe it is even possible to do in one line?)

But in general I can see your point, we just need to think what will be the most convenient for contributors.

Move the entrypoint to a file

Yes! This is a very good idea. The script will be clearer.

TomHAnderson · 2018-04-27T17:56:39Z

Agree with @thomasvargiu that we should include as a dist allowing devs to have their own docker-compose.yml

TomHAnderson · 2018-04-27T19:19:42Z

I've used docker-compose.yml.dist now because @Ocramius thought (at one point) it was good to have my own composer environment to work on a repo and I agree. Using a .dist allows for custom environments.

Now that entrypoint.sh is a script I've added a touch of ascii art to the shell when you login to the php container. I feel strongly this should stay as-is.

This PR is now at RC

michalbundyra · 2018-04-27T23:05:02Z

@TomHAnderson @thomasvargiu I was looking again on docker-compose.yml.dist file solution. I have found this in the docker documentation: https://docs.docker.com/compose/extends/
So we have file docker-compose.yml as it is, and in local if we want to have different env we use docker-compose.override.yml, these by default are red by docker, and I would prefer to go this way instead of requiring one more step do contributors - copying .dist file... It's harder then to make some changes in this file, contributors need to check it everytime, and basically I can see many more issues... and not sure what are the advantages?

TomHAnderson · 2018-04-28T18:59:51Z

I like the docker supported method for this over the .dist approach.

michalbundyra · 2018-04-30T09:51:22Z

.gitignore

@@ -4,3 +4,4 @@ test/data/
 test/assets/module/*/config/module.config.php
 clover.xml
 coveralls-upload.json
+docker-compose.yml


We shouldn't ignore that file, but docker-compose.override.yml.

I've changed this around to override.

michalbundyra · 2018-05-07T07:42:35Z

composer.json

@@ -70,7 +70,12 @@
            "ZFTest\\Apigility\\Doctrine\\": "test/src/"
        }
    },
+    "bin": [
+        "./scripts/mongodb-shim"


I was thinking about it, and I think we shouldn't have it here. Maybe it should be a part of https://github.com/doctrine/mongodb because of it we need to install that extra dependency on PHP 7+.

What I will do here... As we still support PHP 5.6 I would change default version in docker container to PHP 5.6 so then we don't need to install anything extra, and then describe in the docs (any maybe show message on container building) that for PHP 7+ we need install extra dependency. What do you think, @TomHAnderson ?

I think your proposed solution is workable.

Using the least common denominator of PHP 5.6 is like I don’t try to predict the future. I try to prevent it. I could very well be overly pessimistic here. I liked the pro-active approach better. What about not installing the script in composer / 'everyone gets a copy' and instead installing in a bin/ directory local to the project so it is only ran from composer events? But, I have to plead ignorance, would the event be fired when the repository is included in another project too? If so I fall back to 1.

weierophinney · 2019-12-31T20:27:16Z

This repository has been closed and moved to laminas-api-tools/api-tools-doctrine; a new issue has been opened at laminas-api-tools/api-tools-doctrine#3.

weierophinney · 2019-12-31T20:27:58Z

This repository has been moved to laminas-api-tools/api-tools-doctrine. If you feel that this patch is still relevant, please re-open against that repository, and reference this issue. To re-open, we suggest the following workflow:

Squash all commits in your branch (git rebase -i origin/{branch})
Make a note of all changed files (`git diff --name-only origin/{branch}...HEAD
Run the laminas/laminas-migration tool on the code.
Clone laminas-api-tools/api-tools-doctrine to another directory.
Copy the files from the second bullet point to the clone of laminas-api-tools/api-tools-doctrine.
In your clone of laminas-api-tools/api-tools-doctrine, commit the files, push to your fork, and open the new PR.
We will be providing tooling via laminas/laminas-migration soon to help automate the process.

TomHAnderson force-pushed the feature/docker-for-testing branch from 322ce33 to b9d9673 Compare April 2, 2018 06:49

TomHAnderson mentioned this pull request Apr 3, 2018

Docker containers for PHP 7.1 development doctrine/DoctrineMongoODMModule#197

Closed

TomHAnderson added 2 commits April 20, 2018 14:54

Added docker-compose for development

2afe41b

Instructions for Docker

857298a

TomHAnderson force-pushed the feature/docker-for-testing branch from b097cf9 to 857298a Compare April 20, 2018 21:50

TomHAnderson added 3 commits April 20, 2018 16:31

proofreading DOCKER.md

e6c6465

Added docker-compose and unit tests to travis

97ca995

The results in this test have changed order but are still valid. Rewr…

a6b1272

…ote to account for unknown order

TomHAnderson mentioned this pull request Apr 22, 2018

The results in this test have changed order but are still valid. Rew… #309

Closed

TomHAnderson force-pushed the feature/docker-for-testing branch from 2af4d27 to a6b1272 Compare April 22, 2018 06:00

thomasvargiu suggested changes Apr 22, 2018

View reviewed changes

TomHAnderson added 2 commits April 22, 2018 13:11

Incorporated suggestions from @thomasvargiu for Docker

32cec04

Added docker tests to travis

c7b4d02

TomHAnderson force-pushed the feature/docker-for-testing branch from 593e7f5 to c7b4d02 Compare April 23, 2018 03:47

Organized .travis.yml

6894562

thomasvargiu suggested changes Apr 23, 2018

View reviewed changes

michalbundyra reviewed Apr 23, 2018

View reviewed changes

Made changes based on feedback on github

05aa000

thomasvargiu reviewed Apr 23, 2018

View reviewed changes

First test run of non-php specific travis test

a2c7bdb

Re-added COMPOSER_ARGS

7954365

michalbundyra reviewed Apr 26, 2018

View reviewed changes

TomHAnderson added 3 commits April 26, 2018 20:28

Implemented all ideas from @webimpress

7a07548

Put brackets back around variables

b6f19ce

Put brackets back around variables

f91132a

michalbundyra reviewed Apr 27, 2018

View reviewed changes

TomHAnderson added 4 commits April 27, 2018 12:00

Move docker-compose to dist; move entrypoint to file; add ascii art

8173b69

Made entrypoint.sh executable

acf0cf0

Added ascii art

3043a23

Updated docs and ascii art

a7c0657

TomHAnderson mentioned this pull request Apr 28, 2018

Create Docker environment for testing zfcampus/zf-doctrine-querybuilder#47

Open

Removed .dist in favor of Docker override

142233a

michalbundyra reviewed Apr 30, 2018

View reviewed changes

TomHAnderson added 3 commits April 30, 2018 10:48

Add override to .gitignore

4469bfb

Added install and update hooks for comopser for MongoDB Shim

1090652

Added JSON_UNESCAPED_SLASHES

78cdf71

michalbundyra reviewed May 7, 2018

View reviewed changes

weierophinney mentioned this pull request Dec 31, 2019

Feature/docker for testing laminas-api-tools/api-tools-doctrine#3

Open

weierophinney mentioned this pull request Dec 31, 2019

Create Docker environment for testing laminas-api-tools/api-tools-doctrine-querybuilder#4

Closed

TomHAnderson mentioned this pull request Feb 19, 2020

Use Docker Testing doctrine/DoctrineMongoODMModule#212

Merged

greg0ire mentioned this pull request Feb 20, 2020

Don't mind me just testing things out doctrine/DoctrineMongoODMModule#213

Closed

		@@ -0,0 +1 @@
		docker exec -it $(docker ps -f name=zfapigilitydoctrine_php_1 \| awk '{print $1;}' \| tail -n 1) bash

		@@ -85,6 +80,7 @@ install:
		script:
		- if [[ $TEST_COVERAGE == 'true' ]]; then composer test-coverage ; else composer test ; fi

Feature/docker for testing #308

Are you sure you want to change the base?

Feature/docker for testing #308

Conversation

TomHAnderson commented Apr 2, 2018

coveralls commented Apr 2, 2018 • edited Loading

michalbundyra commented Apr 2, 2018

TomHAnderson commented Apr 3, 2018

Ocramius commented Apr 3, 2018

TomHAnderson commented Apr 20, 2018 • edited Loading

TomHAnderson commented Apr 22, 2018

TomHAnderson commented Apr 22, 2018

thomasvargiu left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomHAnderson commented Apr 22, 2018

TomHAnderson commented Apr 23, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michalbundyra left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

TomHAnderson commented Apr 26, 2018

michalbundyra left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

thomasvargiu commented Apr 27, 2018 • edited Loading

Ignore the docker-compose.yml file FROM VCS

Move the entrypoint to a file

michalbundyra commented Apr 27, 2018

TomHAnderson commented Apr 27, 2018

TomHAnderson commented Apr 27, 2018

coveralls commented Apr 2, 2018 •

edited

Loading

TomHAnderson commented Apr 20, 2018 •

edited

Loading

thomasvargiu commented Apr 27, 2018 •

edited

Loading

Ignore the `docker-compose.yml` file FROM VCS

TomHAnderson May 7, 2018 •

edited

Loading