Draft: Fix duplicate pipelines for invalid syntax

What does this MR do?

This is draft MR, no test, no feature flag...

This MR fixes the problem of duplicate pipelines for invalid syntax.

Copying from the comments (1, 2)

In a scenario where I don't use Merge Request Pipelines. When I push a second commit to an MR, Ci::CreatePipelineService is called twice;

1. For push source.
2. For merge_request_event source.

The first call successfully creates the pipeline, but the second one does not. Why? =>

• In the Seed step, we try to build jobs/stages, etc.
• When building a job, we check @only.all? { |spec| spec.satisfied_by?(@pipeline, evaluate_context) } before adding it to the pipeline.
• Since the default only is [branches, tags], we do not return true for merge request pipelines.

This default condition helps us not to have duplicate pipelines. However, if the pipeline is invalid before the Seed step, the duplicate one for merge_request_event is created. For example; when the syntax is invalid, it returns from the Config::Process step and creates an invalid pipeline.

Also, it does not matter if I use Merge Request Pipelines.

After adding

include:
  - template: 'Workflows/MergeRequest-Pipelines.gitlab-ci.yml'

duplicate pipelines are still created because we drop the pipeline in the Config::Process step when the syntax is invalid. So the EvaluateWorkflowRules step is not run at all.

Screenshots (strongly suggested)

Before this MR

We have our initial commit in the MR

Here are the pipelines

We have the second commit in the MR, which makes the syntax invalid

And we have duplicate pipelines

After this MR

We have our initial commit in the MR

Here are the pipelines

We have the second commit in the MR, which makes the syntax invalid

And we don't have duplicate pipelines

Does this MR meet the acceptance criteria?

Conformity

• 📋 Does this MR need a changelog?
  • I have included a changelog entry.
  • I have not included a changelog entry because _____.
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• Tested in all supported browsers
• Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• Label as security and @ mention @gitlab-com/gl-security/appsec
• The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• Security reports checked/validated by a reviewer from the AppSec team