Merging update pipeline editor and create MR with pipeline editor specs

Description of the test

Not really a new test but rather an extended test case.

Related gitlab-org/quality/quality-engineering/team-tasks#1816 (closed)

After we have done shifting multiple test cases for Pipeline Editor to feature level tests

• gitlab-org/quality/quality-engineering/team-tasks#1699 (closed)
• gitlab-org/quality/quality-engineering/team-tasks#1700 (closed)

It is now possible to merge pipeline_editor_can_create_merge_request_spec.rb and update_ci_file_with_pipeline_editor_spec.rb together to have 1 test case that checks:

When user update a CI file in a project:

• User set source branch as a non-existing branch, this branch will automatically get created when the commit is submitted
• A new pipeline is created accordingly
• There is also option to create new MR simultaneously, once this option is check, user is redirected to create new MR page when submitting the change and will be able to create a new MR with the changes from there.

Note: I also remove runner creation in here. We don't need a successful pipeline to meet the expectations for this test case. We only care about pipeline creation, having the pipeline fails immediately with invalid syntax will save us time and resources.

How to set up and validate locally

• Running against Staging - From the qa directory:

GITLAB_USERNAME="gitlab-qa" GITLAB_PASSWORD=<password> GITLAB_QA_USER_AGENT=<agent> QA_GITLAB_URL=https://staging.gitlab.com bundle exec rspec qa/specs/features/browser_ui/4_verifty/pipeline/update_ci_file_with_pipeline_editor_spec.rb

• Running against GDK - From the qa directory:

QA_GITLAB_URL=http://<local.ip.address>:3000 bundle exec rspec qa/specs/features/browser_ui/4_verify/pipeline/update_ci_file_with_pipeline_editor_spec.rb

Checklist

• Confirm the test has a testcase: tag linking to an existing test case in the test case project.
• Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
• Follow the end-to-end tests style guide and best practices.
• Use the appropriate RSpec metadata tag(s).
• Most resources will be cleaned up via the general cleanup task. Check that is successful, or ensure resources are cleaned up in the test:
  • New resources have api_get_path and api_delete_path implemented if possible.
  • If any resource cannot be deleted in the general delete task, make sure it is ignored.
  • If any resource cannot be deleted in the general delete task, remove it in the test (e.g., in an after block).
• Ensure that no transient bugs are hidden accidentally due to the usage of waits and reloads.
• Verify the tags to ensure it runs on the desired test environments.
• If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
• (If applicable) Create a follow-up issue to document the special setup necessary to run the test: ISSUE_LINK
• If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the GITLAB_QA_ADMIN_ACCESS_TOKEN provided.