I’m fairly new to Concourse and trying to wrap my head around the ways to use it with Merge Requests/Pull Requests. Our team is using GitLab to host a mono-repository of several micro-services and we currently use Jenkins to trigger our whole pipeline (linting & unittests per micro-service, e2e tests, etc.) on every MR. We want to migrate to Concourse.
Now, I see that there will be some improvements coming soon with v10 of the roadmap on the “handling of MRs” front, but until then I want to ask for a possible workflow with running the whole pipeline on every MR and to not get everything mixed up.
As our project is meant to be run/deployed in docker containers I see the rough outline of our pipeline like this:
MR_Resource |--triggers--> Create_Images_Job |-- --> UT_Service1_Job --| --> E2E_Tests_Job |-- --> UT_Service2_Job /
After the E2E_Tests_Job I have to post a message in GitLab’s MR that CI has passed or not.
Let’s suppose that there are 2 MRs issued almost at the same time.
My questions are:
Since for passing inputs/outputs between jobs one needs to
putthem in an external resource and later
getthem in another what would happen if: the first MR triggers
Create_Images_Job, but shortly after that the second MR comes in and triggers another build of images. If second MR removed some code its
Create_Images_Jobjob will finish first so the dependent jobs (the unittests jobs) will be executed 2 times with the images corresponding to the second MR (and respectively, not executed with images corresponding to MR 1), is this correct? If it is, how can I fight against it?
My understanding is that even if the unittests (and subsequent jobs) have “passed” constraint on the Images_Resource (what is put by Create_Images_Job), they again will be run with the last version of the resource that also has successful Create_Images_Job build. In other words, Resources with “passed” constraint don’t run with the Resource version produced by the previous job, but the last version of that resource that happened to be at the time the dependent job starts that also has any successful build in the previous job?
If the above is correct, it means that there is no reliable way to update the GitLab MR with the status of the CI? Will I be able to access the version of the MR1 at the end of the pipeline if MR2 triggered another round through the pipeline before MR1 finished?
We use Concourse version 5.8.