Recovering Allen CI pipeline

• move ecal decoding and electron lines in non-default sequence (!675 (merged))
• temporarily disabling hlt1_pp_no_gec tests (!665 (merged)), remove Jenkins tests (in Moore?) and tests related to hlt1_pp_no_gec (MooreAnalysis!53 (merged))
• move to merge request pipelines (https://docs.gitlab.com/ee/ci/yaml/index.html#workflowrules-templates)
• Specify tag docker-privileged-xl in build runners (https://cern.service-now.com/service-portal/?id=kb_article&n=KB0005851) (!676 (merged))

!508 (closed) can solve the problem at long term

assigned to @ascarabo

changed the description

changed the description

mentioned in merge request !675 (merged)

mentioned in merge request !676 (merged)

changed the description

mentioned in merge request MooreAnalysis!53 (merged)

changed the description

marked the checklist item move ecal decoding and electron lines in non-default sequence (!675 (merged)) as completed

marked the checklist item temporarily disabling hlt1_pp_no_gec tests (!665 (merged)), remove Jenkins tests (in Moore?) and tests related to hlt1_pp_no_gec (MooreAnalysis!53 (merged)) as completed

Do we need to enable branch pipelines? The benefit of using MR pipelines is a CI pipeline is not created unless there is some intention by the author to get the branch merged i.e. by opening a MR.

Hi @roneil, sorry I actually wanted to write the opposite: to move from branch pipelines (where the pipeline is run also if you do a commit in a branch with no MR open) to MR pipelines. What do you think? Can we do something like this https://docs.gitlab.com/ee/ci/pipelines/merge_request_pipelines.html ?

changed the description

marked the checklist item Specify tag docker-privileged-xl in build runners (https://cern.service-now.com/service-portal/?id=kb_article&n=KB0005851) (!676 (merged)) as completed

Closing this, since the CI pipeline has been recovered.

closed