Use the Pipeline Wizard for Pages Onboarding

What does this MR do and why?

This MR utilises the Pipeline Wizard to onboard users to GitLab Pages. Since this is the initial use of the Wizard, this is behind a feature flag for controlled rollout.

This MR introduces 2 changes:

1. Refactor the GitLab Pages view and controller for easier readability / maintainability

This MR introduced yet another 3 if/else pathways in the show.html.haml view, rendering this view ever more complex. Since some of the views did render entirely different things, some of that logic has been moved up into the controller.

2. Introduce a pages/new route with a vue app that shows the pipeline wizard

This MR introduces a pages/new endpoint in addition to the #show action. This displays the pipeline wizard allowing the user to set up / commit a new .gitlab-ci.yml file to deploy a pages app.

The #show action will redirect to #new in case @project.show_pages_onboarding? is true. This means that navigating to pages will show the pipeline onboarding wizard when this hasn't been set up for the project before but shows the pages settings once the onboarding has been completed.

You may ask "why not toggle the onboarding view on the settings view?", By creating a new path for the #new action, the user can actively return to the onboarding screen to update/change the .gitlab-ci.yml even if the onboarding had been completed before. The user may have made a mistake but wants to use the familiar interface again, so allowing a second visit to the onboarding screen is a great user experience.

Initially there will be a link back to the /new path on the waiting view.

The waiting view is also being introduced with this MR. It's an interim empty state, displayed after the onboarding has been completed, but before the first pages deployment has succeeded. This allows the user to see "Hey, you've successfully completed the onboarding journey, now we just need to wait for the pages deployment jobs to complete.". The usually take several minutes, so this view needs to survive a page reload (!79955 (merged) introduced a backend state for this).

Feature Flag

This change is behind a feature flag, there will be follow up MRs that provide the corresponding documentation changes, tracking and an alert for users to provide feedback

Screenshots or screen recordings

The new Pipeline Wizard:

Waiting state view

This is displayed after committing .gitlab-ci.yml with a pages config for the first time.

These are strongly recommended to assist reviewers and reduce the time to merge your change.

How to set up and validate locally

1. Enable the feature flag with echo "Feature.enable(:use_pipeline_wizard_for_pages)" | rails c

2. Open a repository that you have owner access to.

3. Go to Settings > Pages.

4. Use the Pipeline wizard, click "commit" at the end

5. See the page reloading to waiting state

6. Confirm the waiting state is still there after a page reload

7. If you

   • have your runner set up correctly
   • work in an actual static site app repo (e.g. an Astro app)
   • and have used actual, real settings during the wizard set up a page reload will show the pages settings after reload instead of the "waiting" view.

   alternatively, simulate a successful deploy with the console by running rails c, then:

   project = Project.find(<project-id>)
   project.pages_metadatum.update(deployed: true)

   (note that this will not actually deploy your pages site)

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.