How to show tests from another repository in GitLab CI

votes

So I have my project with it's unit tests and they show nicely as green or red circles when I do a merge request after I've configured the CI system in GitLab.

But now I also have some integration tests, which reside in a separate repository (why you ask? because I have multiple micro-services that need to be tested together, and each has it's own repository).

When I do a merge request on this integration tests' repository, they show nicely, but what I need it for those tests to show on the merge requests of the other repositories.

I did manage to trigger them from the micro-services' repositories with a URL/command that GitLab CI gives me, something like this: curl -X POST -F token=... -F ref=master https://gitlab.com/api/v4/projects/.../trigger/pipeline

But in the micro-services' repositories, it always shows as a green circle, meaning it successfully started the integration tests, but I don't know how to display the tests results (or at least if they broke or not).

Could anyone point me to the right documentation, if there is one, or just explain to me how to do it and if it's even possible?

The best solution I could think of was to create my integration tests as a library, then I'd import and use that library on all the other projects, but I'd definitely rather avoid this, since it would force me to write the integration tests in the same programming language as the projects (assuming they are the same) or make some hack to run it on the other languages.

Thank you.

continuous-integrationgitlabintegration-testing

If you have multiple repos, but each can only merge if everything passes, then what advantage do you have over a mono-repo? – Oliver Charlesworth

All the micro-services' advantages: teams can work independently; projects can be written in different programming languages; etc. Plus, the multiple repositories decision is not up for discussion :/ (Ps.: not my decision). – Rodrigo Ruiz

That's micro-services, not multi-repo. Basically, it sounds like you've been asked to build a fragmented mono-repo. But yeah, I guess this is beyond the scope of the question ;) – Oliver Charlesworth

Usually each micro-service is created in a separate repository, specially if you wanna scale them separately or support multiple languages. – Rodrigo Ruiz

1 Answers

votes

What you could do is expand on what you're currently doing using a Python/Bash script;

From the main project, using said script:

Trigger the micro-service pipeline (and capture the pipeline ID)
Poll the status of the pipeline, using the captured ID (which can be running, pending, failed, canceled or skipped)
Raise an exception / error if it has failed...

This should do what you require, but would mean that you would be using a runner just to be constantly sending a curl request to the GitLab instance (and that this runner can't pick up another job, depending on how you have setup the runner's limit and concurrent settings).

Example run_pipeline.py:

import gitlab
import time, timeit
import sys

from datetime import timedelta

gl = gitlab.Gitlab("https://your_gitlab_instance.com/",
                    private_token="you_private_token")

project = gl.projects.get('your_project')
create_pipeline = project.pipelines.create({'ref': 'master'})

# Set default
status = "pending"
start_time = timeit.default_timer()

while (status == "running" or status == "pending"):
    pipeline = project.pipelines.get(create_pipeline.id)

    status = pipeline.status

    elapsed_time = timeit.default_timer() - start_time
    formated_time = str(timedelta(seconds=elapsed_time))
    sys.stderr.write("Still running pipeline... ({})\n".format(formated_time))

    if status == "success":
        sys.stderr.write("\nPipeline success\n")
        break
    elif status == "failed":
        raise Exception
    elif status == "canceled":
        raise Exception

    time.sleep(10)

And then call this python script as a stage in your gitlab-ci.yml.