gitlab-branch-source-plugin
gitlab-branch-source-plugin copied to clipboard
How to trigger and show status on multi repositories on the same pipeline
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
Hi everyone,
Is anyone have an idea for the solution?
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"