Hiding triggered multip-project pipeline runs in downstream project

GitLab CI/CD
1

Hello GitLab community.

So we have two projects in our GitLab, let’s call them “component” and “system”. The .gitlab-ci.yml in “system” has a job that is not run for merge requests/pushes to “system”, but only when triggered from “component”. This is so that “component” merge requests will get quick feedback on whether or not the change is likely to work with “system”.

This works pretty well so far, but one issue is annoying us now: when showing a commit’s build status (in the commit list, or on top of the default project view) for the “system” project, GitLab will always reference the latest job that ran, which oftentimes is just the small validation job for “component”. This validation job doesn’t do the full build of “system”, and has no artifacts. When i want the latest artifacts for a branch/master, i now have to go search through the jobs log, find my branch, find the one of many builds that wasn’t just a validation run, but the full “system” build, and click that, where previously i could click the checkmark on the project start page and be directly taken to the build result.

Things i have tried:

  • Using an automatic URL to the latest artifacts on a branch, like https://gitlab.mycompany/group/system/-/jobs/artifacts/master/browse?job=build, where by specifying ?job=build i had hoped to get the latest job that included a build (as opposed to ?job=component-validation), but instead i get an error, because the latest (component-validation) pipeline doesn’t have a ?job=build.
  • I have searched a bit for gitlab settings, but to no avail; happy if someone knows more than me there :slight_smile:

Workarounds i have thought about:

  • Move the component-validation job to the “component” repo. duplicates some of the code, gitlab build caches etc, but would probably work
  • Add some code to the pipeline which will remove itself as the last step at the end of a successful run, so at least only the failed component-validation runs will show up, increasing the likelihood that the latest build in “system” for a commit will actually have been a “system” build.

Glad to hear your thoughts/more ideas to try out :slight_smile: