gitlab-branch-source-plugin icon indicating copy to clipboard operation
gitlab-branch-source-plugin copied to clipboard

How to trigger and show status on multi repositories on the same pipeline

Open usinelogicielle opened this issue 3 years ago • 2 comments

What feature do you want to see added?

Hello,

We have found a legit use case for the plugin, which I explain below.

We have a GitLab repository containing the source files of the project which we will call source-repository and a GitLab repository containing the continuous integration for the the source-repository (build, test, deploy) which we will call ci-repository.

Our need would be to clone the ci-repository via Jenkins web app and then the possibility of choosing:

  • We would like to select the repository where the status will be displayed.
  • The automatic triggering of the pipeline (push, mr, tag) from the source-repository and the ci-repository

Another case is a project composed of several modules separated in different GitLab repositories and a common CI is needed.

Is this functionality already possible or is it possible to implement this feature?

Thanks for your help.

Usine Logicielle

Upstream changes

No response

usinelogicielle avatar May 18 '22 14:05 usinelogicielle

Hi everyone,

Is anyone have an idea for the solution?

usinelogicielle avatar Sep 26 '23 13:09 usinelogicielle

IMHO, your workflow contradicts the idea of having a multibranch pipeline where the CI is part of the source repo. This is the key concept. You can try to have two different multibranch pipelines, one for CI and for source. Then call a common build workflow from a shared library or trigger a common job which does the actual build. gitlab-branch-source will always notify the current "scm", but this can be turned off. You can use the GitLab REST API directly to set the build status (see https://docs.gitlab.com/ee/api/commits.html#set-the-pipeline-status-of-a-commit). You can use e.g. https://www.jenkins.io/doc/pipeline/steps/http_request/ which AFAIK does not require a node to be acquired so you can notify GitLab at an very early stage without the need to wait for an agent (the request will always be done from the controller, not from an agent. Requires resources on the controller, though).

For your second case you can try having a top level repo with the Jenkinsfile, integrating the modules as "git submodule"

gordin123 avatar Sep 26 '23 21:09 gordin123