diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/architecture/blueprints/cells/impacted_features/your-work.md | 2 | ||||
| -rw-r--r-- | doc/architecture/blueprints/remote_development/index.md | 49 | ||||
| -rw-r--r-- | doc/development/documentation/review_apps.md | 1 | ||||
| -rw-r--r-- | doc/development/integrations/jenkins.md | 2 | ||||
| -rw-r--r-- | doc/integration/jenkins.md | 19 | ||||
| -rw-r--r-- | doc/tutorials/plan_and_track.md | 2 | ||||
| -rw-r--r-- | doc/update/versions/gitlab_15_changes.md | 118 | ||||
| -rw-r--r-- | doc/user/analytics/index.md | 49 |
8 files changed, 182 insertions, 60 deletions
diff --git a/doc/architecture/blueprints/cells/impacted_features/your-work.md b/doc/architecture/blueprints/cells/impacted_features/your-work.md index 413c8a42d9d..5a72d50fbea 100644 --- a/doc/architecture/blueprints/cells/impacted_features/your-work.md +++ b/doc/architecture/blueprints/cells/impacted_features/your-work.md @@ -44,7 +44,7 @@ Your Work will be scoped to an Organization, giving the user an overview of all - Issue, Merge request and To-Do list counts will refer to the selected Organization. - The URL will reference the Organization with the following URL structure `/-/organizations/<organization>/dashboard`. -- The default URL `/dashboard` will refer to the default Organization. +- The default URL `/dashboard` will refer to the [Home Organization](../impacted_features/user-profile.md#3-proposal). ## 4. Evaluation diff --git a/doc/architecture/blueprints/remote_development/index.md b/doc/architecture/blueprints/remote_development/index.md index c7d1ec29add..d64fbfc8b55 100644 --- a/doc/architecture/blueprints/remote_development/index.md +++ b/doc/architecture/blueprints/remote_development/index.md @@ -485,7 +485,11 @@ RestartRequested -left-> Running : status=Running ## Injecting environment variables and files into a workspace -Like CI, there is a need to inject environment variables and files into a workspace. These environment variables and files will be frozen in time during workspace creation to ensure the same values are injected into the workspace every time it starts/restarts. Thus, a new database table, on the lines of `ci_job_variables` will be required. This table will contain the following columns - +Like CI, there is a need to inject environment variables and files into a workspace. +These environment variables and files will be frozen in time during workspace creation to ensure the same values +are injected into the workspace every time it starts/restarts. +Thus, a new database table, on the lines of `ci_job_variables` will be required. +This table will contain the following columns - - `key` - To store the name of the environment variable or the file. - `encrypted_value` - To store the encrypted value of the environment variable or the file. @@ -493,29 +497,40 @@ Like CI, there is a need to inject environment variables and files into a worksp - `workspace_id` - To reference the workspace the environment variable or the file is to be injected into. - `variable_type` - To store whether this data is to be injected as an environment variable or a file. -To perform the encryption, a secret key would be required. This would be uniquely generated for each workpsace upon creation. -Having a unique secret key which is used for encrypting the corresponding workspace's environment variable and file data in the workspace, improves the security profile. +To perform the encryption, the GitLab instance level secret key is used. The data about the environment variables +and files will only be sent to the Agent when required i.e. -Because of the nature of reconciliation loop between Agent and Rails, it is not scalable to decrypt these values at Rails side for each request. -Instead, the `key`, `encrypted_value` and `encrypted_value_iv` of each environment variable of the workspace are sent to the Agent along with the workspace's `secret_key` -for the Agent to decrypt them in place. +- When new workspace creation request has been received from the user and an Agent initiates a Partial Reconciliation request +- When an Agent initiates a Full Reconciliation request -To optimize this further, the data about the environment variables and files along with the secret key will only be sent when required i.e. +More details about the implementation details can be found in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/10882). -- When new workspace creation request has been received from the user and an Agent initiates a Partial Reonciliation request -- When an Agent initiates a Full Reconciliation request +We need to keep in mind potential performance concerns of decrypting workspace variables on the Rails side, +and perform benchmarks of what scale we will reach unacceptably long request times for a reconcile request. -When a workspace is created from a project, it will inherit all the variables from the group/subgroup/project hierarchy which are defined under -[`Settings > CI/CD > Variables`](../../../ci/variables/index.md#define-a-cicd-variable-in-the-ui). This aspect will be generalized to allow for defining `Variables` -which will be inherited in both CI/CD and Workspaces. +e.g. a reconcile request for 100 workspaces with 20 encrypted values each == 2000 decryptions in a single request. -A user will also be able to define, at a user level, environment variables and files to be injected into each workspace created by them. +More details about the benchmarking can be found in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/421504). -When a new workspace is created, a new personal access token associated to the user who created the workspace will be generated. -This personal access token will be tied to the lifecycle of the workspace and will be injected into the workspace as an environment variable or a file -to allow for cloning private projects and supporting transparent Git operations from within the workspace out-of-the-box among other things. +When a workspace is created from a project, it will inherit all the variables from the group/subgroup/project hierarchy +which are defined under [`Settings > CI/CD > Variables`](../../../ci/variables/index.md#define-a-cicd-variable-in-the-ui). +This aspect will be generalized to allow for defining `Variables` which will be inherited in both CI/CD and Workspaces. +A user will also be able to define, at a user level, environment variables and files to be injected into each +workspace created by them. While creating a workspace, a user would be able to override any environment variable +or file that is inherited from the group/subgroup/project/user hierarchy. -More details about the implementation details can be found in this [epic](https://gitlab.com/groups/gitlab-org/-/epics/10882). +## Git operations from within a workspace + +When a new workspace is created, a new personal access token associated to the user who created the workspace +will be generated. This personal access token will be tied to the lifecycle of the workspace and will be injected +into the workspace as a file to allow for cloning private projects and supporting transparent Git operations from +within the workspace out-of-the-box among other things using a +[custom Git credential helper](https://git-scm.com/book/en/v2/Git-Tools-Credential-Storage). + +[Investigation](https://gitlab.com/gitlab-org/gitlab/-/issues/421289#note_1511631931) into using +ephemeral tokens(JWTs/OAuth/OIDC/etc.) instead of Personal Access Tokens revealed the need to have a common +JWT Authentication/Authorization layer at GitLab which can be tracked in this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/421983). +Once such a feature is available, Personal Access Tokens for each workspace would be replaced with JWT tokens. ## Workspace user traffic authentication and authorization diff --git a/doc/development/documentation/review_apps.md b/doc/development/documentation/review_apps.md index adc9d727844..483145d1f44 100644 --- a/doc/development/documentation/review_apps.md +++ b/doc/development/documentation/review_apps.md @@ -16,6 +16,7 @@ Review apps are enabled for the following projects: - [Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab) - [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) - [GitLab Charts](https://gitlab.com/gitlab-org/charts/gitlab) +- [GitLab Operator](https://gitlab.com/gitlab-org/cloud-native/gitlab-operator) Alternatively, check the [`gitlab-docs` development guide](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/README.md#development-when-contributing-to-gitlab-documentation) or [the GDK documentation](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/gitlab_docs.md) diff --git a/doc/development/integrations/jenkins.md b/doc/development/integrations/jenkins.md index 73b77051d9c..2f88abda21a 100644 --- a/doc/development/integrations/jenkins.md +++ b/doc/development/integrations/jenkins.md @@ -55,7 +55,7 @@ To set up the Jenkins project you intend to run your build on, read You can configure your integration between Jenkins and GitLab: -- With the [recommended approach for Jenkins integration](../../integration/jenkins.md#configure-a-jenkins-integration-recommended). +- With the [recommended approach for Jenkins integration](../../integration/jenkins.md#configure-a-jenkins-integration). - [Using a webhook](../../integration/jenkins.md#configure-a-webhook). ## Test your setup diff --git a/doc/integration/jenkins.md b/doc/integration/jenkins.md index 462e9137c9d..e01541f5317 100644 --- a/doc/integration/jenkins.md +++ b/doc/integration/jenkins.md @@ -113,10 +113,10 @@ Set up the Jenkins project you intend to run your build on. Configure the GitLab integration with Jenkins in one of the following ways. -### Configure a Jenkins integration (recommended) +### Configure a Jenkins integration -GitLab recommends this approach for Jenkins integrations because it is easier to configure -than the [webhook integration](#configure-a-webhook). +You should use this approach for Jenkins integrations if you can provide GitLab +with your Jenkins server URL and authentication information. 1. On the left sidebar, select **Search or go to** and find your project. 1. Select **Settings > Integrations**. @@ -129,25 +129,24 @@ than the [webhook integration](#configure-a-webhook). 1. Enter the **Jenkins server URL**. 1. Optional. Clear the **Enable SSL verification** checkbox to disable [SSL verification](../user/project/integrations/index.md#manage-ssl-verification). 1. Enter the **Project name**. - The project name should be URL-friendly, where spaces are replaced with underscores. To ensure the project name is valid, copy it from your browser's address bar while viewing the Jenkins project. -1. If your Jenkins server requires - authentication, enter the **Username** and **Password**. +1. If your Jenkins server requires authentication, enter the **Username** and **Password**. 1. Optional. Select **Test settings**. 1. Select **Save changes**. ### Configure a webhook -If you are unable to provide GitLab with your Jenkins server login, you can use this option -to integrate GitLab and Jenkins. +If you cannot [provide GitLab with your Jenkins server URL and authentication information](#configure-a-jenkins-integration), you can configure a webhook to integrate GitLab and Jenkins. 1. In the configuration of your Jenkins job, in the GitLab configuration section, select **Advanced**. 1. Under **Secret Token**, select **Generate**. 1. Copy the token, and save the job configuration. -1. In GitLab, create a webhook for your project, enter the trigger URL - (such as `https://JENKINS_URL/project/YOUR_JOB`) and paste the token in **Secret Token**. +1. In GitLab: + - [Create a webhook for your project](../user/project/integrations/webhooks.md#configure-a-webhook-in-gitlab). + - Enter the trigger URL (such as `https://JENKINS_URL/project/YOUR_JOB`). + - Paste the token in **Secret Token**. 1. To test the webhook, select **Test**. ## Related topics diff --git a/doc/tutorials/plan_and_track.md b/doc/tutorials/plan_and_track.md index 7dcafbd26ce..c5c2919cac7 100644 --- a/doc/tutorials/plan_and_track.md +++ b/doc/tutorials/plan_and_track.md @@ -12,8 +12,6 @@ issues, epics, and more. | Topic | Description | Good for beginners | |-------|-------------|--------------------| | [GitLab Agile Project Management](https://levelup.gitlab.com/courses/gitlab-agile-project-management) | Learn how to use planning features to manage your projects in this self-paced course. | **{star}** | -| [Create a project from a template](https://gitlab.com/projects/new#create_from_template) | Choose a project template and create a project with files to get you started. | | -| [Migrate to GitLab](../user/project/import/index.md) | If you are coming to GitLab from another platform, you can import or convert your projects. | | | [Build a protected workflow for your project](protected_workflow/index.md) | Set up a workflow for your teams, and enforce protections with approval rules. | | | [Run an agile iteration](agile_sprint/index.md) | Use group, projects, and iterations to run an agile development iteration. | | [Set up a single project for issue triage](issue_triage/index.md) | Use labels to set up a project for issue triage. | **{star}** | diff --git a/doc/update/versions/gitlab_15_changes.md b/doc/update/versions/gitlab_15_changes.md index 672c7b1bd81..6ebbeeb1d32 100644 --- a/doc/update/versions/gitlab_15_changes.md +++ b/doc/update/versions/gitlab_15_changes.md @@ -21,6 +21,18 @@ For more information about upgrading GitLab Helm Chart, see [the release notes f - **Upgrade to patch release 15.11.3 or later**. This avoids [issue 408304](https://gitlab.com/gitlab-org/gitlab/-/issues/408304) when upgrading from 15.5.0 and earlier. +### Linux package installations + +In GitLab 15.11, PostgreSQL will automatically be upgraded to 13.x except for the following cases: + +- You are running the database in high availability using Patroni. +- Your database nodes are part of a GitLab Geo configuration. +- You have specifically [opted out](https://docs.gitlab.com/omnibus/settings/database.html#opt-out-of-automatic-postgresql-upgrades) from automatically upgrading PostgreSQL. +- You have `postgresql['version'] = 12` in your `/etc/gitlab/gitlab.rb`. + +Fault-tolerant and Geo installations support manual upgrades to PostgreSQL 13, +see [Packaged PostgreSQL deployed in an HA/Geo Cluster](https://docs.gitlab.com/omnibus/settings/database.html#packaged-postgresql-deployed-in-an-hageo-cluster). + ### Geo installations **(PREMIUM SELF)** - Some project imports do not initialize wiki repositories on project creation. See @@ -385,6 +397,14 @@ For more information about upgrading GitLab Helm Chart, see [the release notes f to GitLab 15.6.2. The issue can also be worked around: [read about how to create these indexes](https://gitlab.com/gitlab-org/gitlab/-/issues/378343#note_1199863087). +### Linux package installations + +In GitLab 15.6, the [PostgreSQL versions shipped with `omnibus-gitlab` packages](../../administration/package_information/postgresql_versions.md) +have been upgraded to 12.12 and 13.8. Unless +[explicitly opted out](https://docs.gitlab.com/omnibus/settings/database.html#automatic-restart-when-the-postgresql-version-changes), +this can cause an automatic restart of the PostgreSQL service, and can +potentially cause downtime. + ### Geo installations **(PREMIUM SELF)** - `pg_upgrade` fails to upgrade the bundled PostregSQL database to version 13. See @@ -682,8 +702,6 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706) - The [certificate-based Kubernetes integration (DEPRECATED)](../../user/infrastructure/clusters/index.md#certificate-based-kubernetes-integration-deprecated) is disabled by default, but you can be re-enable it through the [`certificate_based_clusters` feature flag](../../administration/feature_flags.md#how-to-enable-and-disable-features-behind-flags) until GitLab 16.0. - When you use the GitLab Helm Chart project with a custom `serviceAccount`, ensure it has `get` and `list` permissions for the `serviceAccount` and `secret` resources. - The `FF_GITLAB_REGISTRY_HELPER_IMAGE` [feature flag](../../administration/feature_flags.md#enable-or-disable-the-feature) is removed and helper images are always pulled from GitLab Registry. -- The `AES256-GCM-SHA384` SSL cipher is no longer allowed by NGINX. - See how you can [add the cipher back](https://docs.gitlab.com/omnibus/update/gitlab_15_changes.html#aes256-gcm-sha384-ssl-cipher-no-longer-allowed-by-default-by-nginx) to the allow list. ### Linux package installations @@ -693,6 +711,102 @@ A [license caching issue](https://gitlab.com/gitlab-org/gitlab/-/issues/376706) than `<custom_hooks_dir>/<hook_name>`. - Use `gitaly['custom_hooks_dir']` in `gitlab.rb` ([introduced in 14.3](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4208)) for Omnibus GitLab. This replaces `gitlab_shell['custom_hooks_dir']`. +- PostgreSQL 13.6 is being shipped as the default version for fresh installs and + 12.10 for upgrades. You can manually upgrade to PostgreSQL 13.6 following the + [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). + Because of underlying structural changes, the running PostgreSQL process + **_must_** be restarted when it is upgraded before running database + migrations. If automatic restart is skipped, you must run the following + command before migrations are run: + + ```shell + # If using PostgreSQL + sudo gitlab-ctl restart postgresql + + # If using Patroni for Database replication + sudo gitlab-ctl restart patroni + ``` + + If PostgreSQL is not restarted, you might face + [errors related to loading libraries](https://docs.gitlab.com/omnibus/settings/database.html#could-not-load-library-plpgsqlso). + +- Starting with GitLab 15.0, `postgresql` and `geo-postgresql` services are + automatically restarted when the PostgreSQL version changes. Restarting + PostgreSQL services causes downtime due to the temporary unavailability of the + database for operations. While this restart is mandatory for proper functioning + of the Database services, you might want more control over when the PostgreSQL + is restarted. For that purpose, you can choose to skip the automatic restarts as + part of `gitlab-ctl reconfigure` and manually restart the services. + + To skip automatic restarts as part of GitLab 15.0 upgrade, perform the following + steps before the upgrade: + + 1. Edit `/etc/gitlab/gitlab.rb` and add the following line: + + ```ruby + # For PostgreSQL/Patroni + postgresql['auto_restart_on_version_change'] = false + + # For Geo PostgreSQL + geo_postgresql['auto_restart_on_version_change'] = false + ``` + + 1. Reconfigure GitLab: + + ```shell + sudo gitlab-ctl reconfigure + ``` + + NOTE: + It is mandatory to restart PostgreSQL when underlying version changes, to avoid + errors like the [one related to loading necessary libraries](https://docs.gitlab.com/omnibus/settings/database.html#could-not-load-library-plpgsqlso) + that can cause downtime. So, if you skip the automatic restarts using the above + method, ensure that you restart the services manually before upgrading to GitLab + 15.0. + +- Starting with GitLab 15.0, the `AES256-GCM-SHA384` SSL cipher will not be allowed by + NGINX by default. If you require this cipher (for example, if you use + [AWS's Classic Load Balancer](https://docs.aws.amazon.com/en_en/elasticloadbalancing/latest/classic/elb-ssl-security-policy.html#ssl-ciphers)), + you can add the cipher back to the allow list by following the steps below: + + 1. Edit `/etc/gitlab/gitlab.rb` and add the following line: + + ```ruby + nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384" + ``` + + 1. Reconfigure GitLab: + + ```shell + sudo gitlab-ctl reconfigure + ``` + +- Support for Gitaly's internal socket path is removed. + In GitLab 14.10, Gitaly introduced a new directory that holds all runtime + data Gitaly requires to operate correctly. This new directory replaces the + old internal socket directory, and consequentially the usage of + `gitaly['internal_socket_dir']` was deprecated in favor of + `gitaly['runtime_dir']`. + + The old `gitaly['internal_socket_dir']` configuration was removed in this release. + +- Background uploads settings for object storage are removed. + Object storage now preferentially uses direct uploads. + + The following keys are no longer supported in `/etc/gitlab/gitlab.rb`: + + - `gitlab_rails['artifacts_object_store_direct_upload']` + - `gitlab_rails['artifacts_object_store_background_upload']` + - `gitlab_rails['external_diffs_object_store_direct_upload']` + - `gitlab_rails['external_diffs_object_store_background_upload']` + - `gitlab_rails['lfs_object_store_direct_upload']` + - `gitlab_rails['lfs_object_store_background_upload']` + - `gitlab_rails['uploads_object_store_direct_upload']` + - `gitlab_rails['uploads_object_store_background_upload']` + - `gitlab_rails['packages_object_store_direct_upload']` + - `gitlab_rails['packages_object_store_background_upload']` + - `gitlab_rails['dependency_proxy_object_store_direct_upload']` + - `gitlab_rails['dependency_proxy_object_store_background_upload']` ### Self-compiled installations diff --git a/doc/user/analytics/index.md b/doc/user/analytics/index.md index 9e99d9aeaaf..023c1cd81fc 100644 --- a/doc/user/analytics/index.md +++ b/doc/user/analytics/index.md @@ -6,57 +6,52 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Analyze GitLab usage **(FREE ALL)** -## Instance-level analytics +GitLab provides different types of analytics insights at the instance, group, and project level. -Instance-level analytics make it possible to aggregate analytics across -GitLab, so that users can view information across multiple projects and groups -in one place. +## Instance-level analytics -For more information, see [instance-level analytics](../admin_area/analytics/index.md). +Use [instance-level analytics](../../administration/analytics/index.md) to aggregate analytics across GitLab, +so that you can view information across multiple projects and groups in one place. ## Group-level analytics > Moved to GitLab Premium in 13.9. -GitLab provides several analytics features at the group level. Some of these features require you to use a higher tier than GitLab Free. +Use group-level analytics to get insights into your groups': -- [Application Security](../application_security/security_dashboard/index.md) -- [Contribution](../group/contribution_analytics/index.md) -- [DevOps Adoption](../group/devops_adoption/index.md) +- [Security Dashboards](../application_security/security_dashboard/index.md) +- [Contribution analytics](../group/contribution_analytics/index.md) +- [DevOps adoption](../group/devops_adoption/index.md) - [Insights](../group/insights/index.md) -- [Issue](../group/issues_analytics/index.md) -- [Productivity](productivity_analytics.md) -- [Repositories](../group/repositories_analytics/index.md) -- [Value Stream Management Analytics](../group/value_stream_analytics/index.md), and [Value Stream Management Dashboard](value_streams_dashboard.md) +- [Issue analytics](../group/issues_analytics/index.md) +- [Productivity analytics](productivity_analytics.md) +- [Repositories analytics](../group/repositories_analytics/index.md) +- [Value Stream Management Analytics](../group/value_stream_analytics/index.md) and [Value Stream Management Dashboard](value_streams_dashboard.md) ## Project-level analytics -You can use GitLab to review analytics at the project level. Some of these features require you to use a higher tier than GitLab Free. +Use project-level analytics to get insights into your projects': - [Analytics dashboards](analytics_dashboards.md), enabled with the `combined_analytics_dashboards_editor` [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development) -- [Application Security](../application_security/security_dashboard/index.md) -- [CI/CD & DORA](ci_cd_analytics.md) -- [Code Review](code_review_analytics.md) +- [Security Dashboards](../application_security/security_dashboard/index.md) +- [CI/CD analytics and DORA metrics](ci_cd_analytics.md) +- [Code review analytics](code_review_analytics.md) - [Contributor statistics](../../user/analytics/contributor_statistics.md) - [Insights](../project/insights/index.md) -- [Issue](../../user/analytics/issue_analytics.md) -- [Merge Request](merge_request_analytics.md), enabled with the `project_merge_request_analytics` +- [Issue analytics](../../user/analytics/issue_analytics.md) +- [Merge request analytics](merge_request_analytics.md), enabled with the `project_merge_request_analytics` [feature flag](../../development/feature_flags/index.md#enabling-a-feature-flag-locally-in-development) -- [Repository](repository_analytics.md) -- [Value Stream Management Analytics](../group/value_stream_analytics/index.md), and [Value Stream Management Dashboard](value_streams_dashboard.md) +- [Repository analytics](repository_analytics.md) +- [Value Stream Management Analytics](../group/value_stream_analytics/index.md) and [Value Stream Management Dashboard](value_streams_dashboard.md) ## User-configurable analytics -The following analytics features are available for users to create personalized views: - -- [Application Security](../application_security/security_dashboard/index.md#security-center) - -Be sure to review the documentation page for this feature for GitLab tier requirements. +View vulnerabilities of your selected projects in the [Security Center](../application_security/security_dashboard/index.md#security-center). ## Value streams management -You can use the following analytics features to analyze and visualize the performance of your projects and groups: +Analyze and visualize the performance of your projects and groups with: - [Value stream analytics for projects and groups](../group/value_stream_analytics/index.md) - [Value streams dashboard](value_streams_dashboard.md) |