We’ve enabled merge trains, but one drawback with merge trains is that we end up having to do the build portion twice: once in the merge train pipeline, and again in the main branch. This isn’t as much of a concern for our main branch pipelines, but we’ve been discussing also using merge trains for our dev pipeline to reduce failures in our dev branch pipeline. Build speed on the dev pipeline is very important, and it wouldn’t hurt to speed up our main branch builds as well.
In our case we have high confidence that if the build succeeds in the merge train, it will also work in the branch build. Our build can produce a docker image, but we currently skip that in the merge train to progress to the branch build more quickly. However, the portion before the docker build still takes some time. I’d like to try building the docker image in the merge train pipeline, and then fetch the image created by the merge train pipeline while running the branch pipeline to avoid the extra time for the branch build. However, I’d like a reliable way to detect whether the commit in the branch pipeline has the same file contents as the commit in the merge train pipeline. If they don’t match (e.g. a manual push, or when bypassing the merge train), I’d like to run the full build in the branch pipeline.
My questions are:
- Is there a Gitlab way to detect that a pipeline that runs as a result of a successful merge train? Can we use Gitlab provided information construct a ref with which we can compare the file contents with those from the current merge commit?
- If not, is there a reasonably simple way to derive that information reliably, e.g. from the API or something similar?
- If we are checking that the file contents are identical, are there flaws with this approach I’m not seeing?