Skip to content

Draft: Add onboarding_complete column to pages_metadata

Janis Altherr requested to merge pages-onboarding-metatdatum into master

What does this MR do and why?

This MR adds an onboarding_complete boolean to project_pages_metadata. This should subsequently be used to decide whether or not to show the onboarding interface when opening the Pages UI.

While we do already have a deployed boolean, that in most cases carries the information I need, it does not exactly represent the state required.

Following this MR I'll introduce an interactive onboarding screen for GitLab Pages that uses the Pipeline Wizard to help the user create a .gitlab-ci.yml file.

Imagine the following:

  • The user creates the .gitlab-ci.yml file.
  • The user commits the file.
  • The pipeline starts.
  • The deployed boolean will be set to true after (!) the pipeline has successfully finished.

So during the time after the user has committed their file, but before the pipeline has successfully finished, we have no persistent way of identifying whether or not to display the onboarding screen.

This will especially cause confusion if the Pipeline for any reason isn't able to finish, because it fails, is invalid, runners are unavailable, etc.

This MR will solve that.

The onboarding_complete boolean will be set to true right after successfully committing the .gitlab-ci.yml file, using a GraphQL Mutation. This way it is independent of the job succeeding.

Considerations

I had considered instead of introducing a new Mutation to set the onboarding_complete at the beginning of the UpdatePagesService, similar to how deployed is set. However, this has two issues:

  • it does not happen immediately after the commit, so a page reload would likely still present the user with the unexpected onboarding screen again
  • it still depends on the Pipeline to start, so a verification issue, unavailable runner etc. would also prevent the value to be set correctly.

How to set up and validate locally

  1. Apply the migration
    bin/rails db:migrate
  2. Log in and identify a project that does not have a pages deployment yet.
  3. Open http://localhost:3000/-/graphql-explorer (Use the same browser you logged in with to keep your auth token, or feel free to use another method to authenticate while using graphql-explorer)
  4. Using the path of the previously identified project, run the following mutation:
mutation {
  pagesMarkOnboardingComplete(input: {
    projectPath: "<Insert Project Path>"
  }) {
    onboardingComplete
    errors
  }
}

MR acceptance checklist

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

Edited by Janis Altherr

Merge request reports