In our case it's 'default'.

Add a Helm Chart column for each application so that users can cross-reference RBAC resouce documentation

Document `gitlab` service account creation. Re-word to make documentation flow in both cluster addtion and creation scenarios

Add table of resources created for ease of scannning

This is similar to the option in the Add Existing cluster form

This also solves the async nature of the automatic creation of default
service tokens for service accounts. It also makes explicit which
service account token we always use.

create cluster role binding only if the provider has legacy_abac
disabled.

Add create_secret to KubeClient

Drive creation of a rbac platform_kubernetes off provider#legacy_abac so that there is one single source of truth.

Keeps existing behaviour for ABAC cluster

Explicitly persist the legacy_abac value of the cluster_provider_gcp so that we can disable abac if the `:rbac_clusters` feature flag is enabled

Fix spec warning: removing `initialize' may cause serious problems

Actually verify that `service.create_cluster` is called with expected
request_body and other args

Only create new service account with cluster-admin clusterrolebinding for when we have the rbac cluster FF enabled.

This syncs up with `authorization_type`.

Adds "More information" link from the RBAC cluster form element to the documentation from the previous commit

This is the same as with adding an existing cluster

When provisioning a new cluster, create gitlab service account so that GitLab can perform operations in a RBAC-enabled cluster.

Correspondingly, use the token of the gitlab service account, vs the
default service account token which will have no privs.

This is in preparation to share some common code with another service
which will also need a kubeclient utilizing master username and password

Enable frozen string in app/graphql + app/finders

See merge request gitlab-org/gitlab-ce!21681

Update Gitlay server version to 0.121.0

See merge request gitlab-org/gitlab-ce!21725

Fixed resolved discussions not toggling expanded on changes tab

Closes #51370

See merge request gitlab-org/gitlab-ce!21676

Fix column differences in `db/schema.rb`

See merge request gitlab-org/gitlab-ce!21718

Add project to jupyter cluster app factory spec

See merge request gitlab-org/gitlab-ce!21717

Document abstraction levels and code reuse

See merge request gitlab-org/gitlab-ce!21254

This is based on the discussion in
https://gitlab.com/gitlab-org/gitlab-ce/issues/49653 and the example
merge request found at
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20908. The idea
is fairly straightforward: we define a variety of abstractions, then
state which can reuse which. This should ultimately foster _better_ code
reuse, make it easier to debug problems, and make it harder to
accidentally introduce a performance regression.

Add RuboCop cops to enforce code reusing rules

See merge request gitlab-org/gitlab-ce!21391

Enable omniauth by default

Closes #49990

See merge request gitlab-org/gitlab-ce!21700

Display click to expand on collapsed diffs

Closes #51466

See merge request gitlab-org/gitlab-ce!21716

project_custom_attributes and group_custom_attributes used datetime
instead of datetime_with_timezone column type in database schema. But
actually migration defines `t.timestamps_with_timezone`.

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Merge branch '50808-choosing-initialize-repo-with-a-readme-breaks-project-created-from-template' into 'master'

Resolve "Choosing “Initialize repo with a README” breaks project created from template"

Closes #50808

See merge request gitlab-org/gitlab-ce!21646