3

Scenario

  1. Create a new virtual machine with runner installed
  2. Trigger a pipeline to run (from another project), which runs on this new virtual machine
  3. Do something else, or fail if pipeline above fails on the new virtual machine

Question

I'm using GitLabs Triggers API to run a pipeline from a project, however would like it to run on this newly created virtual machine.

What would be the best way of parsing this information to the GitLab API, or would something like tags be the best way of doing this?


.gitlab-ci.yml

stages:
  - deploy to test
  - test
  - deploy to prod

Terraform Deploy To Test:
  stage: deploy to test
  script:
    - cd test_deploy
    - python deploy.py

Testing:
  stage: test
  script:
    - curl --request POST --form token=TOKEN --form ref=master http://gitlab.example.com/api/v4/projects/12/trigger/pipeline

Terraform Deploy to Prod:
  stage: deploy to prod
  script:
    - do something if the above testing succeeds, or fail

The above gitlab-ci file would generate a new build machine and deploy it to the "test group" within vsphere with a python script. (Deploying it would activate a gitlab-runner and tie it to a specific project and have some tags associated with it).

To test, it then triggers a pipeline call using the GitLab API, and I would like that pipeline to run on the new generated build machine on vsphere.


Would a work around maybe be something like using gitlab runner exec command or using environments?

  • The pipeline will run locally or on a runner, without insight of what kind of pipeline it is it's hard to answer. Could you extend to give more details and maybe show your .gitlab-ci.yml so we can have a better idea of what it is supposed to do ? – Tensibai Oct 24 '17 at 7:48
  • I think I see the overall idea, but that's very broad and if your deploy.py doen't give a return about the machine which has been spin up, that's just a dead end, and we have no idea what your porject 12 .gitlab-ci.yml does and as such no way to give advice on how to deport it on the created machine. (All in all this sounds a bad approach to the problem) – Tensibai Oct 24 '17 at 12:20
  • @Tensibai thanks for the comment - the deploy.py is just running some Terraform commands and can output the ip of the machine generated. I was more thinking of using tags, but then there are issues of tags on the existing project. Project 12 is just a test project with echo calls in a pipeline. Would you have any other suggestions on how to do something like this? – Rekovni Oct 24 '17 at 13:26
  • For the second part, just as any async batch job, loop asking for the status of this pipeline id (which id is returned by the trigger call within the json object), knowing what this second pipeline does and if it can do it through ssh or if it need some other convoluted way is a matter of divination – Tensibai Oct 24 '17 at 13:29
  • @Tensibai was thinking of something similar using the GitLab API to get the status of the job - thanks for clarifying. Any ideas for the first part? – Rekovni Oct 24 '17 at 13:57
2

There currently isn't a solution for building on a specific runner in GitLab, but there is an issue open for Sticky Runners, which hopefully will be out in the next 3-6 months according to the Milestones!


The work around I've done so far to build a project on a specific runner is to use the GitLab Runner API, in a rather hacky way, along the lines of:

  • Get all project runners
  • As I know I've deployed the latest runner, that would have the highest runner "number"
  • Pause all the other runners associated with the project in question
  • Trigger the pipeline to build on the latest runner
  • Poll the GitLab API to get the status of the pipeline
  • Once that succeeds, resume all other runners!
  • If the pipeline fails, remember to resume the paused runners...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.