Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/user/project/settings/index.md')
-rw-r--r--doc/user/project/settings/index.md228
1 files changed, 48 insertions, 180 deletions
diff --git a/doc/user/project/settings/index.md b/doc/user/project/settings/index.md
index 5c2118e02cf..4407986f354 100644
--- a/doc/user/project/settings/index.md
+++ b/doc/user/project/settings/index.md
@@ -1,7 +1,7 @@
---
stage: Manage
group: Workspace
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments"
+info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
type: reference, index, howto
---
@@ -40,187 +40,24 @@ To assign topics to a project:
1. In the **Topics** text box, enter the project topics. Popular topics are suggested as you type.
1. Select **Save changes**.
-## Compliance frameworks **(PREMIUM)**
+If you're an instance administrator, you can administer all project topics from the
+[Admin Area's Topics page](../../admin_area/index.md#administering-topics).
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/276221) in GitLab 13.9.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/287779) in GitLab 13.12.
+## Add a compliance framework to a project **(PREMIUM)**
-You can create a compliance framework label to identify that your project has certain compliance
-requirements or needs additional oversight. The label can optionally apply
-[compliance pipeline configuration](#compliance-pipeline-configuration).
+[Compliance frameworks](../../group/manage.md#compliance-frameworks) can be assigned to projects within group that has a
+compliance framework using either:
-Group owners can create, edit, and delete compliance frameworks:
-
-1. On the top bar, select **Main menu > Groups** and find your group.
-1. On the left sidebar, select **Settings** > **General**.
-1. Expand the **Compliance frameworks** section.
-
-Compliance frameworks created can then be assigned to projects within the group using:
-
-- The GitLab UI, using the project settings page.
+- The GitLab UI:
+ 1. On the top bar, select **Main menu > Projects > View all projects** and find your project.
+ 1. On the left sidebar, select **Settings** > **General**.
+ 1. Expand the **Compliance frameworks** section.
+ 1. Select a compliance framework.
+ 1. Select **Save changes**.
- In [GitLab 14.2](https://gitlab.com/gitlab-org/gitlab/-/issues/333249) and later, using the
- [GraphQL API](../../../api/graphql/reference/index.md#mutationprojectsetcomplianceframework).
-
-NOTE:
-Creating compliance frameworks on subgroups with GraphQL causes the framework to be
-created on the root ancestor if the user has the correct permissions. The GitLab UI presents a
-read-only view to discourage this behavior.
-
-### Compliance pipeline configuration **(ULTIMATE)**
-
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3156) in GitLab 13.9, disabled behind `ff_evaluate_group_level_compliance_pipeline` [feature flag](../../../administration/feature_flags.md).
-> - [Enabled by default](https://gitlab.com/gitlab-org/gitlab/-/issues/300324) in GitLab 13.11.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/331231) in GitLab 14.2.
-
-Compliance framework pipelines allow group owners to define
-a compliance pipeline in a separate repository that gets
-executed in place of the local project's `.gitlab-ci.yml` file. As part of this pipeline, an
-`include` statement can reference the local project's `.gitlab-ci.yml` file. This way, the compliance
-pipeline jobs can run alongside the project-specific jobs any time the pipeline runs.
-Jobs and variables defined in the compliance
-pipeline can't be changed by variables in the local project's `.gitlab-ci.yml` file.
-
-When you set up the compliance framework, use the **Compliance pipeline configuration** box to link
-the compliance framework to specific CI/CD configuration. Use the
-`path/file.y[a]ml@group-name/project-name` format. For example:
-
-- `.compliance-ci.yml@gitlab-org/gitlab`.
-- `.compliance-ci.yaml@gitlab-org/gitlab`.
-
-This configuration is inherited by projects where the compliance framework label is applied. The
-result forces projects with the label to run the compliance CI/CD configuration in addition to
-the project's own CI/CD configuration. When a project with a compliance framework label executes a
-pipeline, it evaluates configuration in the following order:
-
-1. Compliance pipeline configuration.
-1. Project-specific pipeline configuration.
-
-The user running the pipeline in the project must at least have the Reporter role on the compliance
-project.
-
-Example `.compliance-gitlab-ci.yml`:
-
-```yaml
-# Allows compliance team to control the ordering and interweaving of stages/jobs.
-# Stages without jobs defined will remain hidden.
-stages:
- - pre-compliance
- - build
- - test
- - pre-deploy-compliance
- - deploy
- - post-compliance
-
-variables: # Can be overridden by setting a job-specific variable in project's local .gitlab-ci.yml
- FOO: sast
-
-sast: # None of these attributes can be overridden by a project's local .gitlab-ci.yml
- variables:
- FOO: sast
- image: ruby:2.6
- stage: pre-compliance
- rules:
- - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
- when: never
- - when: always # or when: on_success
- allow_failure: false
- before_script:
- - "# No before scripts."
- script:
- - echo "running $FOO"
- after_script:
- - "# No after scripts."
-
-sanity check:
- image: ruby:2.6
- stage: pre-deploy-compliance
- rules:
- - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
- when: never
- - when: always # or when: on_success
- allow_failure: false
- before_script:
- - "# No before scripts."
- script:
- - echo "running $FOO"
- after_script:
- - "# No after scripts."
-
-audit trail:
- image: ruby:2.6
- stage: post-compliance
- rules:
- - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
- when: never
- - when: always # or when: on_success
- allow_failure: false
- before_script:
- - "# No before scripts."
- script:
- - echo "running $FOO"
- after_script:
- - "# No after scripts."
-
-include: # Execute individual project's configuration (if project contains .gitlab-ci.yml)
- project: '$CI_PROJECT_PATH'
- file: '$CI_CONFIG_PATH'
- ref: '$CI_COMMIT_REF_NAME' # Must be defined or MR pipelines always use the use default branch
-```
-
-When used to enforce scan execution, this feature has some overlap with [scan execution policies](../../application_security/policies/scan-execution-policies.md),
-as we have not [unified the user experience for these two features](https://gitlab.com/groups/gitlab-org/-/epics/7312).
-For details on the similarities and differences between these features, see
-[Enforce scan execution](../../application_security/index.md#enforce-scan-execution).
-
-### Ensure compliance jobs are always run
-
-Compliance pipelines use GitLab CI/CD to give you an incredible amount of flexibility
-for defining any sort of compliance jobs you like. Depending on your goals, these jobs
-can be configured to be:
-
-- Modified by users.
-- Non-modifiable.
-
-At a high-level, if a value in a compliance job:
-
-- Is set, it cannot be changed or overridden by project-level configurations.
-- Is not set, a project-level configuration may set.
-
-Either might be wanted or not depending on your use case.
-
-There are a few best practices for ensuring that these jobs are always run exactly
-as you define them and that downstream, project-level pipeline configurations
-cannot change them:
-
-- Add a `rules:when:always` block to each of your compliance jobs. This ensures they are
- non-modifiable and are always run.
-- Explicitly set any variables the job references. This:
- - Ensures that project-level pipeline configurations do not set them and alter their
- behavior.
- - Includes any jobs that drive the logic of your job.
-- Explicitly set the container image file to run the job in. This ensures that your script
- steps execute in the correct environment.
-- Explicitly set any relevant GitLab pre-defined [job keywords](../../../ci/yaml/index.md#job-keywords).
- This ensures that your job uses the settings you intend and that they are not overridden by
- project-level pipelines.
-
-### Avoid parent and child pipelines in GitLab 14.7 and earlier
-
-NOTE:
-This advice does not apply to GitLab 14.8 and later because [a fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78878) added
-compatibility for combining compliance pipelines, and parent and child pipelines.
-
-Compliance pipelines start on the run of _every_ pipeline in a relevant project. This means that if a pipeline in the relevant project
-triggers a child pipeline, the compliance pipeline runs first. This can trigger the parent pipeline, instead of the child pipeline.
-
-Therefore, in projects with compliance frameworks, we recommend replacing
-[parent-child pipelines](../../../ci/pipelines/downstream_pipelines.md#parent-child-pipelines) with the following:
-
-- Direct [`include`](../../../ci/yaml/index.md#include) statements that provide the parent pipeline with child pipeline configuration.
-- Child pipelines placed in another project that are run using the [trigger API](../../../ci/triggers/index.md) rather than the parent-child
- pipeline feature.
-
-This alternative ensures the compliance pipeline does not re-start the parent pipeline.
+ [GraphQL API](../../../api/graphql/reference/index.md#mutationprojectsetcomplianceframework). If you create
+ compliance frameworks on subgroups with GraphQL, the framework is created on the root ancestor if the user has the
+ correct permissions. The GitLab UI presents a read-only view to discourage this behavior.
## Configure project visibility, features, and permissions
@@ -255,7 +92,8 @@ Use the toggles to enable or disable features in the project.
| **Snippets** | ✓ | Enables [sharing of code and text](../../snippets.md). |
| **Pages** | ✓ | Allows you to [publish static websites](../pages/index.md). |
| **Operations** | ✓ | Control access to Operations-related features, including [Operations Dashboard](../../../operations/index.md), [Environments and Deployments](../../../ci/environments/index.md), [Feature Flags](../../../operations/feature_flags.md). |
-| **Metrics Dashboard** | ✓ | Control access to [metrics dashboard](../integrations/prometheus.md). |
+| **Metrics Dashboard** | ✓ | Control access to [metrics dashboard](../integrations/prometheus.md). |
+| **Releases** | ✓ | Control access to [Releases](../releases/index.md). |
When you disable a feature, the following additional features are also disabled:
@@ -372,7 +210,7 @@ where GitLab is installed.
Prerequisites:
-You must be a project maintainer or administrator to rename a repository.
+You must be a project maintainer, owner, or administrator to rename a repository.
NOTE:
When you change the repository path, users may experience issues if they push to, or pull from, the old URL. For more information, see
@@ -538,3 +376,33 @@ Configure Error Tracking to discover and view [Sentry errors within GitLab](../.
[Add Storage credentials](../../../operations/incident_management/status_page.md#sync-incidents-to-the-status-page)
to enable the syncing of public Issues to a [deployed status page](../../../operations/incident_management/status_page.md#create-a-status-page-project).
+
+## Troubleshooting
+
+When working with project settings, you might encounter the following issues, or require alternate methods to complete specific tasks.
+
+### Remove a fork relationship through console
+
+If removing the fork through the UI or API is not working, you can attempt the fork relationship removal in a [Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+
+```ruby
+p = Project.find_by_full_path('<project_path>')
+u = User.find_by_username('<username>')
+Projects::UnlinkForkService.new(p, u).execute
+```
+
+### Transfer a project through console
+
+If transferring a project through the UI or API is not working, you can attempt the transfer in a [Rails console session](../../../administration/operations/rails_console.md#starting-a-rails-console-session).
+
+```ruby
+p = Project.find_by_full_path('<project_path>')
+
+# To set the owner of the project
+current_user = p.creator
+
+# Namespace where you want this to be moved
+namespace = Namespace.find_by_full_path("<new_namespace>")
+
+Projects::TransferService.new(p, current_user).execute(namespace)
+```