< Previous (Continuous Integration)

Linking Continuous Integration (aka Real CI)

If we want real CI then that means that we must trigger e2e tests in different situations

  • There were changes to e2e-tests itself: new tests added/modified, fixed, etc.
  • Changes to frontend: make sure that those changes don't break the e2e tests
  • Changes to backend: same

So we need to work on cross-triggering e2e execution. First lets understand what is a "change" for us

Defining triggers for e2e tests (what's a change?)

The concept of "changes" come in a number of different ways. Can be fine-grained as

  • every push on any branch
  • every push to certain branches
  • pull requests

Depending on your choices here you could diverge from my strategy.

My decision here was based on the fact that e2e-tests run are "heavy" and take time, so I don't want to introduce too much delays on build feedback, or overhead to servers (and costs). So I would say that E2E tests must be run:

  • on PRs: so that before merging one can catch errors with e2e tests
  • pushes to dev/master: so that PR merged and any bypassed push to these important branches are also checked.

Current Tests limitations

Our current e2e-tests are modeled with docker-compose. But if you check the definition you will see the relation with front+back is "fixed" to:

  • work against the real code (uses github repo URL)
  • build the master branch

(just to remind you)

  build: 'https://github.com/javierfernandes/docker-e2e-backend.git#master'
  build: 'https://github.com/javierfernandes/docker-e2e-frontend.git#master'

That was good enough to made them run before having "automatic docker image building with CI" ! But now, each module gets built and published to dockerhub automatically. So, we don't need any more to "rebuild" the image from the source.

Solution

As with other problems in software dev this can be done probably in a number of different ways. This is just one, I believe it is the simplest.

We are going to keep the relation sourcecode (push) => CI, for each module. Instead of interconnecting CI builds (like one travis build triggering the e2e-build), which could be quite complex and basically will loose the idea of having e2e as part of the "check" of a single push/change, we will **embed e2e tests within our module's build.

We can do this, since now e2e-tests is a docker image (or will be pretty soon).

// TODO diagram The idea:

  • each module gets built with its CI (as any common CI job)
  • each module knows how to run e2e-tests with docker-compose, using its own code and the other module's docker images.

First we need to adjust some things on our modules

E2E Tests docker image

First, if we want to run e2e tests, we need to also make its own image (its Dockerfile) be automatically built on CI. So lets add this to e2e-tests .travis.yml

after_success:
  - if [ "$TRAVIS_BRANCH" == "master" ]; then
    docker build -t jfernandes/e2e-tests .; 
    docker login --username="$DOCKER_USERNAME" --password="$DOCKER_PASSWORD";
    docker push jfernandes/e2e-tests;
    fi

Then add the env variables to the project in travis site and push it. It should build and publish the image in dockerhub.

Running E2E tests from the frontend

Now go to the frontend folder and create a new docker-compose.yml with the following content:


mongo:
  image: mongo
  ports:
    - "27018:27017"
  command: "--smallfiles --logpath=/dev/null"
backend:
  image: jfernandes/e2e-backend
  ports:
    - "3001:3001"
  links:
    - mongo
  environment: 
    MONGO_URL: 'mongodb://mongo/docker-e2e'
frontend:
  build: .
  ports:
    - "3000:3000"
  links:
    - backend
  environment: 
    BACKEND_URL: 'http://backend:3001/'
tests:
  image: jfernandes/e2e-tests
  links:
    - frontend
    - mongo
  environment:
    - CODECEPT_URL=http://frontend:3000
    - MONGO_URL=mongodb://mongo/docker-e2e
  volumes:
    - /tmp/e2e-output:/app/output

Note: that it is similar to the one in e2e-tests project, BUT not exactly the same. The difference:

  • we are using docker images instead of Git URL for other modules besides the frontend (backend + tests)
  • the current project (frontend) image gets build from the current directory (instead of using a git URL), which will allow us to test against local changes, without having to build the image.

Now you could run this manually with

docker-compose build
docker-compose run tests

But we want travis to do it for us, so edit .travis.yml, we will customize the steps for the build

script:
  - yarn test
  - docker-compose run tests

That's it, now just push and it will run e2e tests on the frontend.

Running E2E tests from the backend

Same as with frontend, here is the docker-compose.yml file


mongo:
  image: mongo
  ports:
    - "27018:27017"
  command: "--smallfiles --logpath=/dev/null"
backend:
  build: .
  ports:
    - "3001:3001"
  links:
    - mongo
  environment: 
    MONGO_URL: 'mongodb://mongo/docker-e2e'
frontend:
  image: jfernandes/e2e-frontend
  ports:
    - "3000:3000"
  links:
    - backend
  environment: 
    BACKEND_URL: 'http://backend:3001/'
tests:
  image: jfernandes/e2e-tests
  links:
    - frontend
    - mongo
  environment:
    - CODECEPT_URL=http://frontend:3000
    - MONGO_URL=mongodb://mongo/docker-e2e
  volumes:
    - /tmp/e2e-output:/app/output

And remember to also update .travis.yml in the same way as for frontend.

< Back | Next >

results matching ""

    No results matching ""