### Summary A pipeline ran for a Merge Request and has the `detached` label and we can't identify why. The pipeline was in failure. When a more recent pipeline ran and is successful, the pipeline taken into consideration for the merge request is not the successful one and, when the configuration allows to merge the MR only when the pipeline is successfull, this bug wrongly blocks the approval process! ### Why it happens When users push a new commit to a merge request (i.e. source branch), there are two pipeline creation events happen 1. `push` pipeline creation 2. `merge-requests` pipeline creation. Most of the pipeline, the `merge-requests` pipeline creation is filtered out by the default `only/except` rules i.e. `only: [branches, tags]`, however, when the gitlab-ci.yml is invalid, the `merge-requests` pipeline creation reacts to the event and thus creates two pipelines regardless of that the MR author doesn't have an intention to turn on [Pipelines for merge requests](https://docs.gitlab.com/ee/ci/merge_request_pipelines/). We should ignore pipeline creation when yaml is invalid. ### Steps to reproduce We don't know why the detached label was affected... Documentation is unclear about it... ### What is the current *bug* behavior? A failing pipeline with the `detached` label is taken into consideration as result for a MR while a most recent and succesfull exists. ### What is the expected *correct* behavior? The most recent successful pipeline should be taken into consideration. ### Relevant logs and/or screenshots  ### Output of checks #### Results of GitLab environment info <details> <summary>Expand for output related to GitLab environment info</summary> <pre> GitLab version: GitLab Enterprise Edition 11.11.5-ee, Silver </pre> </details>