On 2016-07-16 22:34, Sebastiaan Koppe wrote:
Just to let you guys know - and to be sure no one is doing the same - I
decided to go ahead and *start* writing an autotester that will fetch
dmd nightly and unittest each dub package.

It will be using a classic master-worker architecture and will leverage
docker containers.

I am aiming really low at first, but will eventually add things like
memory usage, history, notifications, etc.

Just as a test I setup a project on GitLab.com [1]. This is an example of a build [2]. The config for building that looks like:

- curl -L -o dvm https://github.com/jacob-carlborg/dvm/releases/download/v0.4.4/dvm-0.4.4-linux-debian7-x86_64
    - chmod +x dvm
    - ./dvm install dvm
    - source ~/.bashrc
    - dvm install 2.071.1
    - dvm use 2.071.1 -d
- curl -o dub.tar.gz 'http://code.dlang.org/files/dub-1.0.0-linux-x86_64.tar.gz'
    - tar -xzf dub.tar.gz
    - ./dub test

"linux" is the name of the job and "script" is the commands that should be executed.

The setup I was thinking about would work something like this:

1. Create one or more runners for each supported platform
2. Tag those in GitLab with the name of the platform
3. Create one job per platform that should be tested
4. Use the tags to specify which runner should be used, something like this [3]:

    - linux_x86_64
    - ./gitlab.sh

    - windows
  script: gitlab.bat

    - osx
  script: ./gitlab.sh

5. Update code.dlang.org to mirror the repository to GitLab when it finds an update in GitHub
6. Trigger a build using the GitLab API [4]:

curl -X POST \
  -F token=TOKEN \
  -F ref=master \

One issue is to get the .gitlab-ci.yml file in the repository.

Since it's possible to host GitLab and the runners you get full control of everything.

[1] https://gitlab.com/Carlborg/orange
[2] https://gitlab.com/Carlborg/orange/builds/2450044
[3] https://gitlab.com/help/ci/yaml/README.md
[4] https://gitlab.com/help/ci/triggers/README.md

/Jacob Carlborg

Reply via email to