Next

Resources

FE

We had to revert this MR as it doesn't work nice with External CI Services: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12127#note_33854371.

We should get back to it and re-implement handling of ci_status for merge request widget, to properly support internal, external pipelines, and legacy old CI services. Currently we derive this message from various sources:

• has_ci=true, status=running and head_pipeline=nil is yet another valid case => it indicates external CI service using polling mode,

• has_ci=true, status=running and head_pipeline!=nil => it indicates either external or internal CI pipeline, the CI permissions doesn't apply here,

• if has_ci=false then head_pipeline will always be nil => it indicates that pipelines are disabled,

• we don't have a way to check if external pipeline should be created if GitLab CI is disabled.

We should instead have a single source of trouth, probably detailed CI merge request status that would be handled by frontend and provided by backend.

This status would represent exactly the states:

• cannot connect to CI services: if this is external legacy CI service,
• waiting for Pipeline: if this is internal GitLab CI,
• (no information/or showing waiting): if this is external CI service (Jenkins, using Commit Status).