Currently, when someone clicks on CI/CD in GitLab's main navigation, they are directed to the Pipelines page empty state which links to the documentation. This isn't the optimal first time experience for CI/CD onboarding.
Proposal
With the introduction of a dedicated CI/CD authoring/onboarding tool Pipeline Editor, now it makes more sense to guide the user directly towards the first step in CI/CD onboarding.
When someone clicks on CI/CD in the main nav, we should take them to the Pipeline Editor empty state, from where they can start their first pipeline configuration and run it. This improvement will help us reduce time to green pipeline, which is our goal.
Given when ADO is enabled the pipelines are created in the pipelines page as if there was a CI yaml in the repo, we should keep the Pipelines page the default landing page for the CI/CD section when any form of CI is enabled, which means either ADO is enabled, or if there's a CI configuration.
When there's no CI and no ADO, the Pipeline Editor will be the default landing page for the CI/CD section.
Further information
This idea was discussed in the Growth + Verify UX Sync where we discussed ideas for leveraging the Pipeline Editor better to ease CI/CD onboarding for new GitLab users, as well as ideas to enable other GitLab features using Pipeline Editor.
Thanks for opening this issue, i believe once we will have the empty page sorted out we can start working on making the pipeline editor the default experience for new users (as you mention users that dont have a running pipeline), we should also revisit the CTA button we have on the Jobs page, we should consider redirecting our user to the pipeline editor empty page
Nadia Sotnikovachanged title from Make Pipeline Editor empty state the default landing page for CI/CD to Make Pipeline Editor empty state the default landing page for CI/CD for new CI/CD users
changed title from Make Pipeline Editor empty state the default landing page for CI/CD to Make Pipeline Editor empty state the default landing page for CI/CD for new CI/CD users
Nadia Sotnikovachanged the descriptionCompare with previous version
In app/views/layouts/nav/sidebar/_project.html.haml, we build all the links in the project and we can change the default link there. We already have can_view_pipeline_editor? helper that takes the project instance as an argument and define if a user can see/access the pipeline editor so the conditional would require this to be taken into account.
Updating that link itself isn't too hard, but we have to consider that some E2E spec probably rely CI / CD default value, so we might need to update that.
The other thing we need to make this work is if the project has no CI configuration yet. I've looked around and I found a couple of helpers around that already exists and would probably make this easy.
On project instances, we can use methods repository_exists? and empty_repo?, though we might not need them since in app/models/project.rb, we have has_ci on project
@dhershkovitch@nadia_sotnikova Have we considered what happens for a user that has auto_devops enabled? They technically already have a system of deployment, just not with a Ci configuration. In that case, should we take them to the Editor section as default too? (It might be worth having a different default message for our section if we know you have auto devops as well)
backend If a user has no repository, can we have has_ci safely? Or do we need to first make sure repository_exists? returns true? cc @matteeyah
The most probable answer is that we would do a combine boolean check so that we would redirect you to the editor if: !has_ci && can_view_pipeline_editor
Given all of that, I would make this a frontend-weight3 mostly to give some room for the E2E specs that might require updates.
Have we considered what happens for a user that has auto_devops enabled? They technically already have a system of deployment, just not with a Ci configuration. In that case, should we take them to the Editor section as default too? (It might be worth having a different default message for our section if we know you have auto devops as well)
Its probably deserve a separate issue, ideally, when we would look at the entire ADO experience, for now I believe we should take all users to the pipeline editor
Just one question for @nadia_sotnikova : When clicking on CI/CD, I want to make sure we agree on the conditions that will determine where we take the user. In the issue description, it says once there is at least one pipeline, so it that the condition to stop redirecting the user to the Pipeline editor section, or is it then the project has any form of CI enabled (so the user has a CI/CD file configured or autodevops) or even just if there is a defined CI/CD file?
@f_caplette Good point. We want to take the user to the Pipeline Editor empty state when there's no defined CI/CD file because that's where you define the file.
When Auto DevOps is enabled, do you see pipelines in the Pipelines list page? If yes, we should keep showing it as the default for CI/CD then.
@nagyv-gitlab When Auto DevOps is enabled, do we show the ADO pipelines in the Pipelines list page? Or they're fully implicit and there's no way to see the ADO pipeline run?
In the issue description, it says once there is at least one pipeline, so it that the condition to stop redirecting the user to the Pipeline editor section, or is it then the project has any form of CI enabled (so the user has a CI/CD file configured or autodevops) or even just if there is a defined CI/CD file?
Given when ADO is enabled the pipelines are created in the pipelines page as if there was a CI yaml in the repo, we should keep the Pipelines page the default landing page for the CI/CD section when any form of CI is enabled, which means either ADO is enabled, or if there's a CI configuration.
When there's no CI and no ADO, the Pipeline Editor will be the default landing page for the CI/CD section.
@matteeyah Looping you in here, I know we have @project.auto_devops to know if a project has auto devops enabled, but to know if a root CI config file is defined, do we have any properties/method we could use to get that information on the frontend?
@project.ci_config_path should get you the user configured ci config path. If you want either that or the default you can use @project.ci_config_path_or_default.
@dhershkovitch I've been thinking about the CI/CD empty states and now think that we should just remove the empty state screen from the Editor page altogether. Here's my reasoning.
Pipelines page makes sense as the top level page for CI/CD where the onboarding starts since Pipelines is the core concept of our CI/CD offering.
When onboarding onto CI/CD you can see the other pages in the CI/CD nav section such as Jobs, Schedules, Test Cases. Those don't have a separate empty state, user can explore what those features are about by looking at their UI.
Obfuscating the editor UI with an empty state makes it less clear what the configuration entails. The current Editor empty state doesn't provide additional value like the Pipelines page empty state does.
Instead of making the pipeline editor the default page or reusing the pipelines empty state on the editor page, we could do something like this. This way new users can see that we will validate the configuration, for example. They can also see all the other tabs that suggest further functionality. They know more or less what to expect.
Wdyt?
cc @kcomoli since you've been working on the CI/CD empty states. I might be slightly misusing that empty state component, but the idea is to have the empty state inside the editor window itself.
But I think we can do something more in line with the fact that it's embedded into the editor.
What are the options to create the configuration file?
@kcomoli For sure! I was thinking along the lines of a bare-bones MVC.
Otherwise, one could create a config in the following ways using the pipeline editor:
Select a basic "boilerplate" template
Select a template for a specific project type or type of job they need done
Create a blank file and start from scratch
Right now there's no way to browse the pipeline templates in the pipeline editor, you need to open the directory with templates (we provide a link), open the needed file, copy and paste it back into the pipeline editor. So adding a way to browse templates would be a significant complication on our way to a better empty state. We should do it, but I wouldn't add it in the first iteration.
I'd say we should allow you to either create a blank file or use the boilerplate content, which is what happens now when you click "create configuration" in the current pipeline editor empty state.
I'd say we should allow you to either create a blank file or use the boilerplate content, which is what happens now when you click "create configuration" in the current pipeline editor empty state.
I agree that makes sense. I guess what confused me here is that we are displaying part of the pipeline editor U.I although you did not activate the feature yet. Should your empty state look like this:
So that we progressively disclose the U.I? We start first with the empty state, then we display the rest after people create a configuration file? See related discussion here
Let's add some guidance to the empty state guidelines, establish that it's ok to hide the UI in some occasions but that it needs to be carefully thought through as there are cases when showing the UI, even if there's seemingly nothing to show still makes sense and offers more value to the user and hence produces a better user experience.
This is why I propose to show some of the pipeline editor UI. An editor is one of those tools that isn't like a feature that you need to activate. Usually when you open an editor (for example WebIDE or VSCode), you can see its UI and you can create a file. There's some empty state, but the UI controls are available so you get the idea for what this thing can do.
I think the UI tells a better story than the text in an empty state. I'd like to keep the UI and have an embedded empty state of sort that allows you to create a config file.
Perhaps it'd make more sense to style the empty state area differently, I like the idea of adding two cards here instead of the usual empty state layout with an illustration and CTA buttons, I find that the heading is too overpowering and we should emphasize the available actions more.
I think the UI tells a better story than the text in an empty state. I'd like to keep the UI and have an embedded empty state of sort that allows you to create a config file.
@nadia_sotnikova Got it! That makes sense. I think the 2 cards option could work. Alternatively, to echo your point above, would it be possible to create these files directly via the editor window?
@dhershkovitch The proposal in the issue needs to be re-worked, it's workflowready for design . We can remove the weight, it'll need to be re-weighted with a new proposal.
Right now the pipelines page empty state is the better experience, so the current proposal isn't the best anymore.