Sign in or sign up before continuing. Don't have an account yet? Register now to get started.
Onboarding Workstream - Public Preview
In the public beta state, we will make the GitLab - GCP integration available for any customer to opt-in to a “beta-state”. From a feature and capability standpoint, the goal of this milestone is to enable customers both within GCP and GitLab to discover this integration, sign-up for a self-service free GitLab plan and onboard their accounts.
As part of this phase, we will unlock the following additional CUJs:
### Discovery, Opt-in and Upgrade
CUJ #1 - Discovery of the integration within the GCP marketplace Dependency with the marketplace team. See this ticket.
CUJ #2 - Upgrade to GitLab paid plans via sales workflow from GCP Marketplace (existing functionality)
CUJ #3 - Discovery of available GCP services within GitLab
CUJ #5 - Discoverability of GitLab as a Source Solution within the GCP console
CUJ #6 - GitLab integration landing page
### Account Setup and Linking
CUJ #9b - Workload Identity Pool and Provider creation in GCP (in GitLab)
CUJ #10b -GCP resource policy creation in GitLab for Workload Identity Provider (in GitLab)
CUJ #13 - Highlight missing GCP permissions within GitLab
## Progress Table
<table>
<tr>
<th>CUJ #</th>
<th>Title</th>
<th>Use Case</th>
<th>Progress</th>
</tr>
<tr>
<td>1</td>
<td>Discovery of the integration within the GCP marketplace Dependency with the marketplace team.</td>
<td>As an existing GCP customer, I need to be able to discover the GCP / GitLab integration.</td>
<td>Hannah asked Ben for what this means on GCP side - is what we built for Private Preview sufficient?</td>
</tr>
<tr>
<td>2</td>
<td>Upgrade to GitLab paid plans via sales workflow from GCP Marketplace (existing functionality)</td>
<td>I want to be able to purchase an upgraded GitLab plan</td>
<td>This sounds like a requirement for the Google Cloud team. Hannah confirming with Ben.</td>
</tr>
<tr>
<td>3</td>
<td>Discovery of available GCP services within GitLab</td>
<td>From GitLab.com, I can easily see a list of GCP services that would work with my project.</td>
<td>
Hannah asked Pedro/Erika if we have any research or thoughts on what we want to support here.
Ideas from PRD:
> Possible discovery moments, pending UX research:
>
> \- Creating a blank project that will be deployed to GCP
>
> \- Creating a project from a template that supports deploying to GCP
>
> \- New “Google Cloud” project settings page to configure all use cases supported by the integration
>
> \- In the existing project settings pages for each use case
Currently these are under `Settings > Integrations` for `IAM` and `Artifact Registry`.
</td>
</tr>
<tr>
<td>5</td>
<td>Discoverability of GitLab as a Source Solution within the GCP console</td>
<td>From the GCP console. I can recognize GitLab as a supply source and easily reach the GitLab website.</td>
<td>This is a Google Cloud item.</td>
</tr>
<tr>
<td>6</td>
<td>GitLab integration landing page</td>
<td>From the GitLab UI, I am given appropriate messaging after ingressing from GCP on next steps on how to set up the integration.</td>
<td>We already have this today with the docs page. Hannah asked Ben if we need to build something specific on top of docs.</td>
</tr>
<tr>
<td>9b</td>
<td>Workload Identity Pool and Provider creation in GCP (in GitLab)</td>
<td>As a GCP and GitLab customer (GitLab Group Owner), I would like to create a Workload Identity Pool and Provider to allow GitLab users to authenticate with GCP when executing CI workloads that utilize GCP services.</td>
<td>
This is created today via script. Does the UX need to change for public preview? Hannah asked for UX to chime in on PRD
Imre: For `Artifact Registry`, IAM policies are created via a script. This is still in-progress, but will be included in the private preview. For the public preview, I assume these will be migrated to UI-based flows
</td>
</tr>
<tr>
<td>10b</td>
<td>GCP resource policy creation in GitLab for Workload Identity Provider (in GitLab)</td>
<td>
I want to provide unattended / machine based process execution with fine grained access to GCP resources based on GitLab OpenID attributes\_.\_
</td>
<td>
Imre: Yes, these are created via a script. As far as I know, for public review, we want include it in the UI, and access Google Cloud via OAuth.
.
</td>
</tr>
<tr>
<td>13</td>
<td>Highlight missing GCP permissions within GitLab</td>
<td>As a user, I would like any missing GCP permissions and roles highlighted to me when and where I am taking action within the GitLab UI to solve for when I don’t have the appropriate permissions enabled or the permissions have been changed</td>
<td>Imre: We will document the required permissions for the private preview. Requests with insufficient permission will fail. However, in many cases, the error returned contains the missing permissions, so we might be able to build on that.</td>
</tr>
</table>
epic