1

I am new to GitLab-CI and Docker, I am stuck getting a runner to run my phpunit builds. Following the instructions here: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/docs/install/linux-repository.md

However, The container per their instructions obviously doesn't contain the tools I need. So question is, what is the configuration when registering a multi-runner to have a runner that supports phpunit, composer so I can test my laravel builds.

edi9999
  • 19,701
  • 13
  • 88
  • 127
Vincent Duke
  • 11
  • 1
  • 4
  • I tool am new to GitLab-CI and docker but hopefully this won't be completely useless. The idea would be to either configure and setup your own docker image with everything ready to go for your tests or you perform the installation/configuration by specifying the correct commands in the `.gitlab-ci.yml' file in the top of your repo. – Nathan S. Watson-Haigh Jun 30 '15 at 00:29

2 Answers2

2

Follow their instructions to register gitlab-ci-multi-runner with docker executor. Than in your .gitlab-ci.yml give an appropriate image that contains bare minimum for your requirements. Everything else you can install through command line in before_script. I'm posting a sample working config for you:

image: tetraweb/php
services:
    - mysql
variables:
    MYSQL_DATABASE: effiocms_db
    MYSQL_USER: effio_user
    MYSQL_PASSWORD: testpassword
    WITH_XDEBUG: "1"
before_script:
    # enable necessary php extensions
    - docker-php-ext-enable zip && docker-php-ext-enable mbstring && docker-php-ext-enable gd && docker-php-ext-enable pdo_mysql
    # composer update
    - composer self-update && composer --version
    - composer global require --no-interaction --quiet "fxp/composer-asset-plugin:~1.1.0"
    - export PATH="$HOME/.composer/vendor/bin:$PATH"
    - composer install --dev --prefer-dist --no-interaction --quiet
    # codeception install
    - composer global require --no-interaction --quiet "codeception/codeception=2.0.*" "codeception/specify=*" "codeception/verify=*"
    # setup application
    - |
      php ./init --env=Development --overwrite=All
      cd tests/codeception/backend && codecept build
      cd ../common && codecept build
      cd ../console && codecept build
      cd ../frontend && codecept build
      cd ../../../
    - cd tests/codeception/bin && php yii migrate --interactive=0 && cd ../../..
codeception:
    stage: test
    script:
        - |
          php -S localhost:8080 > /dev/null 2>&1 &
          cd tests/codeception/frontend
          codecept run

Obviously this config is for my application running on Yii2. So you need to adjust it per your requirements.

Community
  • 1
  • 1
Arman P.
  • 4,314
  • 2
  • 29
  • 47
2

Inline with what Arman P. said. When running your tests, make sure you have a docker image which contains all the tools that you will need for your build/test.

You have two options:

  1. You can build your own image, with all the tools you need, and maintain this as your project evolves; or,

  2. you can simply install a basic image from the docker hub and install all the tools before you run your jobs.

Both options have their pros and cons:

Option (1) gives you complete control, but you would need to add this to a private registry which the CI can pull from (Gitlab gives you a private registry support). The only slight con here is that you would have to setup the private registry (e.g Gitlab's) first. Not too difficult, and only need to do it once.

But then it is up to you to maintain the images, etc.

Option (2) allows you to run all the tools without having to maintain a private registry or the docker containers. You simply run the install scrips before your jobs as Arman P. mentioned. The disadvantage on that is that your jobs and builds/tests take longer to run as you now have to wait for the install to happen before every run.


A simple example: Using option (2)

We need PHPUnit and composer.

So, use a container from the public docker hub which has php: select one that has the version of PHP you want to test (e.g. 5.6 or 7). Let's assume 5.6.

In that container we need to install composer and PHPUnit before we can run our tests. This is what your CI file might look like:

.gitlab-ci.yml

image: php:5.6.25-cli

stages:
    - build
    - test

.install_composer_template:&install_composer
    - apt-get install -y git
    - curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

before_script:
    <<:*install_composer

build app:
    stage: build
    script:
        - composer install
        - composer dump-autoload -o

test app:
    stage: test
    before_script:
        <<:*install_composer
        - composer global require -q phpunit/phpunit
    script:
        - phpunit --colors=always

Quick summary of what this actually does

Every job -- here we only have "build app" and "test app" -- will run through the official PHP 5.6 image.

We have two stages defined, build and test -- note: these are defined by default, but here we are being explicit for clarity.

The first job that runs will be the "build app" as it occurs in the first stage, build. Before the script runs in this job, the global before_script runs, which installs git and composer (Composer requires Git). Then the script runs and installs all our composer dependencies. Done.

The next stage then executes, which is test. So our jobs attached to that run (in parallel if we had more than one), which for us is just "test app". Here, we use YML features to reuse the install composer instructions: the local before_script overrides the global before_script, installing Composer (via the YML template) and PHPUnit. Then the actual script runs: which runs our unit tests. The unit tests assume you have a phpunit config in the root -- you can customise this command as you would on you own terminal.

Note here, that due to the stage setup, the output of the build stages are automatically made available in the test stage. So we don't have to do anything, Gitlab will pass all the files for us!

The main reason for using the install_composer template is to improve job execution time. Most things are going to require Composer. So we have a global template and a script that runs for every job. If you need something a bit more specific, with tools that are only required for that job, e.g. PHPUnit, then override the before_script locally in the job and install the required tools. This way we don't have to install a whole load of tools which we might not need in every job!

tgallacher
  • 1,594
  • 1
  • 10
  • 7
  • That aliasing/merging markup doesn't work for me - after some rummaging I found [this question](https://stackoverflow.com/questions/9254178/is-there-yaml-syntax-for-sharing-part-of-a-list-or-map) about merging keys - and it seems it doesn't apply to sequences like these. – Synchro Jan 18 '18 at 15:06