pipeline on merge_request only
since 11.6 (i think) there is the only: merge_request
parameter in CI config.
this is ideally to run tools like danger.
so i went to change our current danger implemenation to use the "merge_requests" only way.
but, i am not sure if it is by-plan or by-accident.
having following pipelines:
- test
- test:cs
- test:static_analyise
- test:danger
before the merge_request
thing.
on every commit, to every branch all the jobs where run. MR was mergeable when everthing is
changing the job test:danger
to only: merge_requests
- at first sight does what it should do, runs on MR pushes, sets ENV and so on.
BUT - then the MR is mergebable if the merge_request
job is passing, ignoring the other jobs.
so i explictly added:
only:
- branches
- tags
- merge request
this - at first, seems to work, MR is again mergeable only if all passes, BUT - and this is where i "feel" its a bug:
there are 2 pipelines created. on with merge_request
context, and one without, running the exact same jobs.
is that by plan? what i ideally want is the MR_IID exposed during a specific job to be able to run DANGER.
what we now do is like:
ENV['DANGER_GITLAB_HOST'] = "gitlab.krone.at"
ENV['DANGER_GITLAB_API_BASE_URL'] = "http://gitlab.krone.at/api/v4"
ENV['DANGER_GITLAB_API_TOKEN'] = 'xxxxxxxx'
# if the merge_request_context would work we could simplyfie it like this
# if ENV['CI_MERGE_REQUEST_ID']
# # Gitlab now nativly supports that
# ENV['CI_MERGE_REQUEST_ID'] = ENV['CI_MERGE_REQUEST_IID']
# begin
# puts "GL NATIVE"
# danger
# rescue StandardError => ex
# puts "Danger failed"
# end
else
remotes = sh("git ls-remote -q origin merge-requests\\*head|grep #{ENV['CI_COMMIT_SHA']} || echo 'no pr' ")
match_data = /.*merge-requests\/([0-9]+)\//.match(remotes)
if match_data && match_data[1]
ENV['CI_MERGE_REQUEST_ID'] = match_data[1]
begin
danger
rescue StandardError => ex
puts "DAnger failed"
end
else
UI.important "not a MR"
end
end