Fix create pipeline service spec

We swapped the order of this file around because it was failing when run on its own. This was due to the protected branch examples in the middle of the file: they were persisting data in the Redis cache that then continued to future examples, and led to stale data (reporting that the project had some protected branches when there were none).

We can fix this by putting the specs back where they were and clearing the cache between each spec.

See #373717 (comment 1101874343) for more details.

changed milestone to %15.4

added maintenancerefactor teamScalability-Observability typemaintenance labels

assigned to @smcgivern

Suggested Reviewers (beta)

The individuals below may be good candidates to participate in the review based on various factors.

You can use slash commands in comments to quickly assign /assign_reviewer @user1.

Suggested Reviewers
@tkuah, @marcel.amirault, @smcgivern, @rspeicher, @cablett

If you do not believe these suggestions are useful, please apply the label Bad Suggested Reviewer. You can also provide feedback for this feature on this issue: https://gitlab.com/gitlab-org/gitlab/-/issues/357923.

Automatically generated by Suggested Reviewers Bot - an experimental ML-based recommendation engine created by ~"group::applied ml".

added backend label

Reviewer roulette

Changes that require review have been detected!

Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:

Category	Reviewer	Maintainer
backend	Jay Montal (@jmontal) (UTC-6, 7 hours behind @smcgivern)	Allen Cook (@acook.gitlab) (UTC-4, 5 hours behind @smcgivern)

To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.

To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.

Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.

If needed, you can retry the danger-review job that generated this comment.

Generated by Danger

@rossfurhman could you take the first review, please?

requested review from @rossfuhrman

approved this merge request

requested review from @acook.gitlab and removed review request for @rossfuhrman

@rossfuhrman, thanks for approving this merge request.

This is the first time the merge request is approved. To ensure full test coverage, a new pipeline has been started.

For more info, please refer to the following links:

• rspec minimal jobs
• jest minimal jobs
• merging a merge request.

mentioned in merge request !97910 (merged)

approved this merge request

resolved all threads

merged

@acook.gitlab, did you forget to run a pipeline before you merged this work? Based on our code review process, if the latest pipeline finished more than 2 hours ago, you should:

1. Ensure the merge request is not in Draft status.
2. Start a pipeline (especially important for Community contribution merge requests).
3. Set the merge request to merge when pipeline succeeds.

This is a guideline, not a rule. Please consider replying to this comment for transparency.

This message was generated automatically. You're welcome to improve it.

mentioned in commit 2761f389

added workflowstaging-canary label

added workflowcanary label and removed workflowstaging-canary label