CODEWITHSUNDEEP
asp.netseleniumgitlabgitlab-ci
faulty
faulty

Reputation: 8347

Gitlab-ci running build then hand over to test on separate machine

I'm relatively new to CI and also Gitlab/Gitlab-CI. I've recently setup Gitlab as our small shop VCS and started exploring Gitlab-CI to do our build. Our code are mainly ASP.Net C#, but I believe the setup is generic. Now we're thinking to run unit test after build, but since our unit test takes a lot longer to run, we're exploring if we can configure to build on one machine, and have another dedicated test machine to run those unit test and maybe include selenium based automated testing in the future.

I would like to know is it possible and how should it be configure, so the build process can hand off testing to another machine. Also, whether separate notification can be sent for build and test.

EDIT: This is not a duplicate to How do I create 2 stages that each on a different runner? The OP in that question is asking about running 2 parallel build+test on diff machine. I'm looking for ways to run build in one machine then test in another, but the result is summed up in 1 build process in Gitlab CI.

Upvotes: 4

Views: 2286

Answers (2)

Danny
Danny

Reputation: 1703

this is a standard way of working by defining stages,using artifacts and using tags to identify your build/test server e.g.:

stages:
 - build
 - test

build:
  stage: build
  tags: build-server-tag
  script:
  - ./buildmyproject
  - mkdir tests
  - cp myexe tests/
  artifacts:
    paths:
      - tests
test:
  stage: test
  tags: test-server-tag
  dependencies:
   - build
  variables:
    GIT_STRATEGY: none
  script:
  - tests/myexe

this will execute myexe on your test server which is build on your build server.

note

  • dependencies is added for clarity, by default all artifacts will be loaded from previous stages.
  • GIT_STRATEGY: none will not pull your repository onto the test server.

Upvotes: 1

Ilya Kuchaev
Ilya Kuchaev

Reputation: 91

Here is the quote from GitLab documentation:

Use Tags

You must setup a runner to be able to run all the different types of jobs that it may encounter on the projects it's shared over. This would be problematic for large amounts of projects, if it wasn't for tags.

By tagging a Runner for the types of jobs it can handle, you can make sure shared runners will only run the jobs they are equipped to run.

For instance, at GitLab we have runners tagged with "rails" if they contain the appropriate dependencies to run Rails test suites.

Here is an example .gitlab-ci.yml file. So you can setup another one (even more) runner with the required tags and process your long running tests separately.

Upvotes: 2

Related Questions