diff options
Diffstat (limited to 'doc')
25 files changed, 225 insertions, 156 deletions
diff --git a/doc/administration/raketasks/github_import.md b/doc/administration/raketasks/github_import.md index 5e96813103f..3c64e1fef8e 100644 --- a/doc/administration/raketasks/github_import.md +++ b/doc/administration/raketasks/github_import.md @@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w # GitHub import Rake task **(FREE SELF)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390690) in GitLab 15.9, Rake task no longer automatically creates namespaces or groups that don't exist. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/390690) in GitLab 15.9, Rake task no longer automatically creates namespaces or groups that don't exist. +> - Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. To retrieve and import GitHub repositories, you need a [GitHub personal access token](https://github.com/settings/tokens). A username should be passed as the second argument to the Rake task, diff --git a/doc/api/import.md b/doc/api/import.md index 356977a1b9e..e762de4a0fa 100644 --- a/doc/api/import.md +++ b/doc/api/import.md @@ -8,22 +8,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w Use the Import API to import repositories from GitHub or Bitbucket Server. -## Prerequisites - -For information on prerequisites for using the Import API, see: - -- [Prerequisites for GitHub importer](../user/project/import/github.md#prerequisites). -- [Prerequisites for Bitbucket Server importer](../user/project/import/bitbucket_server.md#import-your-bitbucket-repositories). - ## Import repository from GitHub -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381902) in GitLab 15.8, GitLab no longer automatically creates namespaces or groups if the namespace or group name specified in `target_namespace` doesn't exist. GitLab also no longer falls back to using the user's personal namespace if the namespace or group name is taken or `target_namespace` is blank. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381902) in GitLab 15.8, GitLab no longer automatically creates namespaces or groups if the namespace or group name specified in `target_namespace` doesn't exist. GitLab also no longer falls back to using the user's personal namespace if the namespace or group name is taken or `target_namespace` is blank. +> - Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. Import your projects from GitHub to GitLab using the API. -The namespace set in `target_namespace` must exist. The namespace can be your user namespace or an existing group that -you have at least the Maintainer role for. Using the Developer role for this purpose was -[deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. +Prerequisites: + +- [Prerequisites for GitHub importer](../user/project/import/github.md#prerequisites). +- The namespace set in `target_namespace` must exist. +- The namespace can be your user namespace or an existing group that you have at least the Maintainer role for. Using + the Developer role for this purpose was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab + 15.8 and will be removed in GitLab 16.0. ```plaintext POST /import/github @@ -169,13 +167,16 @@ Returns the following status codes: ## Import repository from Bitbucket Server -Import your projects from Bitbucket Server to GitLab via the API. +Import your projects from Bitbucket Server to GitLab using the API. -NOTE: The Bitbucket Project Key is only used for finding the repository in Bitbucket. You must specify a `target_namespace` if you want to import the repository to a GitLab group. If you do not specify `target_namespace`, the project imports to your personal user namespace. +Prerequisites: + +- For more information, see [prerequisites for Bitbucket Server importer](../user/project/import/bitbucket_server.md#import-your-bitbucket-repositories). + ```plaintext POST /import/bitbucket_server ``` diff --git a/doc/api/project_import_export.md b/doc/api/project_import_export.md index 98f154c17d7..15f2e878570 100644 --- a/doc/api/project_import_export.md +++ b/doc/api/project_import_export.md @@ -138,6 +138,8 @@ ls *export.tar.gz ## Import a file +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. + ```plaintext POST /projects/import ``` diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md index 40a5d2a2abc..87d2da016d6 100644 --- a/doc/development/feature_flags/index.md +++ b/doc/development/feature_flags/index.md @@ -505,9 +505,12 @@ Feature.remove(:feature_flag_name) ## Changelog +We want to avoid introducing a changelog when features are not accessible by an end-user either directly (example: ability to use the feature) or indirectly (examples: ability to take advantage of background jobs, performance improvements, or database migration updates). + +- Database migrations are always accessible by an end-user indirectly, as self-managed customers need to be aware of database changes before upgrading. For this reason, they **should** have a changelog entry. - Any change behind a feature flag **disabled** by default **should not** have a changelog entry. - - **Exception:** database migrations **should** have a changelog entry. -- Any change related to a feature flag itself (flag removal, default-on setting) **should** have [a changelog entry](../changelog.md). +- Any change behind a feature flag that is **enabled** by default **should** have a changelog entry. +- Changing the feature flag itself (flag removal, default-on setting) **should** have [a changelog entry](../changelog.md). Use the flowchart to determine the changelog entry type. ```mermaid @@ -519,7 +522,6 @@ Feature.remove(:feature_flag_name) A -->|no changelog| D ``` -- Any change behind a feature flag that is **enabled** by default **should** have a changelog entry. - The changelog for a feature flag should describe the feature and not the flag, unless a default on feature flag is removed keeping the new code (`other` in the flowchart above). - A feature flag can also be used for rolling out a bug fix or a maintenance work. In this scenario, the changelog diff --git a/doc/integration/cas.md b/doc/integration/cas.md index bfeabde8a36..d2a29161a53 100644 --- a/doc/integration/cas.md +++ b/doc/integration/cas.md @@ -8,76 +8,6 @@ redirect_to: '../administration/auth/index.md' # CAS OmniAuth provider (removed) **(FREE SELF)** -WARNING: -This feature was -[deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/369127) in GitLab -15.3 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/369128) in 16.0. - -To enable the CAS OmniAuth provider you must register your application with your -CAS instance. This requires the service URL GitLab supplies to CAS. It should be -something like: `https://gitlab.example.com:443/users/auth/cas3/callback?url`. -Handling for Single Logout (SLO) is enabled by default, so you only have to -configure CAS for back-channel logout. - -1. On your GitLab server, open the configuration file. - - For Omnibus package: - - ```shell - sudo editor /etc/gitlab/gitlab.rb - ``` - - For installations from source: - - ```shell - cd /home/git/gitlab - - sudo -u git -H editor config/gitlab.yml - ``` - -1. Configure the [common settings](omniauth.md#configure-common-settings) - to add `cas3` as a single sign-on provider. This enables Just-In-Time - account provisioning for users who do not have an existing GitLab account. - -1. Add the provider configuration: - - For Omnibus package: - - ```ruby - gitlab_rails['omniauth_providers'] = [ - { - name: "cas3", - label: "Provider name", # optional label for login button, defaults to "Cas3" - args: { - url: "CAS_SERVER", - login_url: "/CAS_PATH/login", - service_validate_url: "/CAS_PATH/p3/serviceValidate", - logout_url: "/CAS_PATH/logout" - } - } - ] - ``` - - For installations from source: - - ```yaml - - { name: 'cas3', - label: 'Provider name', # optional label for login button, defaults to "Cas3" - args: { - url: 'CAS_SERVER', - login_url: '/CAS_PATH/login', - service_validate_url: '/CAS_PATH/p3/serviceValidate', - logout_url: '/CAS_PATH/logout' } } - ``` - -1. Change 'CAS_PATH' to the root of your CAS instance (such as `cas`). - -1. If your CAS instance does not use default TGC lifetimes, update the `cas3.session_duration` to at least the current TGC maximum lifetime. To explicitly disable SLO, regardless of CAS settings, set this to 0. - -1. Save the configuration file. - -1. For the changes to take effect: - - If you installed via Omnibus, [reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure). - - If you installed from source, [restart GitLab](../administration/restart_gitlab.md#installations-from-source). - -On the sign in page there should now be a CAS tab in the sign in form. +This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/369127) +in GitLab 15.3 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/369128) +in 16.0. diff --git a/doc/update/index.md b/doc/update/index.md index 9990a2e8ffe..74aec1bdf1e 100644 --- a/doc/update/index.md +++ b/doc/update/index.md @@ -270,12 +270,24 @@ and [Helm Chart deployments](https://docs.gitlab.com/charts/). They come with ap every Sidekiq process also listens to those queues to ensure all jobs are processed across all queues. This behavior does not apply if you have configured the [routing rules](../administration/sidekiq/processing_specific_job_classes.md#routing-rules). +### 15.11.1 + +- Many [project importers](../user/project/import/index.md) and [group importers](../user/group/import/index.md) now + require the Maintainer role instead of only requiring the Developer role. For more information, see the documentation + for any importers you use. + ### 15.11.0 - Upgrades to GitLab 15.11 directly from GitLab versions 15.5.0 and earlier on self-managed installs will fail due to a missing migration until the fix for [issue 408304](https://gitlab.com/gitlab-org/gitlab/-/issues/408304) is released in an upcoming patch release. Affected users wanting to upgrade to 15.11.x can either: - Perform an intermediate upgrade to any version between 15.5 and 15.10 before upgrading to 15.11, or - Target the forthcoming patch release. +### 15.10.5 + +- Many [project importers](../user/project/import/index.md) and [group importers](../user/group/import/index.md) now + require the Maintainer role instead of only requiring the Developer role. For more information, see the documentation + for any importers you use. + ### 15.10.0 - Gitaly configuration changes significantly in Omnibus GitLab 16.0. You can begin migrating to the new structure in Omnibus GitLab 15.10 while backwards compatibility is diff --git a/doc/user/admin_area/settings/external_authorization.md b/doc/user/admin_area/settings/external_authorization.md index ff0d6ae1e87..072873ba7f6 100644 --- a/doc/user/admin_area/settings/external_authorization.md +++ b/doc/user/admin_area/settings/external_authorization.md @@ -53,7 +53,8 @@ The external authorization service can be enabled by an administrator: ### Allow external authorization with deploy tokens and deploy keys -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386656) in GitLab 15.9. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/386656) in GitLab 15.9. +> - Deploy tokens no longer being able to access container or package registries [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/387721) in GitLab 16.0. You can set your instance to allow external authorization for Git operations with [deploy tokens](../../project/deploy_tokens/index.md) or [deploy keys](../../project/deploy_keys/index.md). @@ -71,6 +72,9 @@ To allow authorization with deploy tokens and keys: - Select **Allow deploy tokens and deploy keys to be used with external authorization**. 1. Select **Save changes**. +WARNING: +If you enable external authorization, deploy tokens cannot access container or package registries. If you use deploy tokens to access these registries, this measure breaks this use of these tokens. Disable external authorization to use tokens with container or package registries. + ## How it works When GitLab requests access, it sends a JSON POST request to the external diff --git a/doc/user/application_security/breach_and_attack_simulation/index.md b/doc/user/application_security/breach_and_attack_simulation/index.md index 0d662f7d469..bb67150d4fa 100644 --- a/doc/user/application_security/breach_and_attack_simulation/index.md +++ b/doc/user/application_security/breach_and_attack_simulation/index.md @@ -7,10 +7,11 @@ type: reference, howto # Breach and Attack Simulation **(ULTIMATE)** -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/402784) in GitLab 15.11. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/402784) in GitLab 15.11 as an Incubating feature. +> - [Included](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119981) in the `Security/BAS.latest.gitlab-ci.yml` in GitLab 16.0. DISCLAIMER: -Breach and Attack Simulation is a set of experimental features being developed by the Incubation Engineering Department and is subject to significant changes over time. +Breach and Attack Simulation is a set of incubating features being developed by the Incubation Engineering Department and is subject to significant changes over time. Breach and Attack Simulation (BAS) uses additional security testing techniques to assess the risk of detected vulnerabilities and prioritize the remediation of exploitable vulnerabilities. @@ -25,23 +26,116 @@ You can simulate attacks with [DAST](../dast/index.md) to detect vulnerabilities By default, DAST active checks match an expected response, or determine by response time whether a vulnerability was exploited. -Enable the BAS feature flag in DAST to: +To enable BAS extended DAST scanning for your application, use the `dast_with_bas` job defined +in the GitLab BAS CI/CD template file. Updates to the template are provided with GitLab +upgrades, allowing you to benefit from any improvements and additions. -- Enable callback, match response, and timing attacks inside of active checks. -- Perform Out-of-Band Application Security Testing (OAST) through callback attacks in active checks. +1. Include the appropriate CI/CD template: -To enable BAS: + - [`BAS.latest.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/BAS.latest.gitlab-ci.yml): + Latest version of the BAS template. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119981) + in GitLab 16.0). -1. Create a CI/CD job using the [DAST browser-based analyzer](../dast/browser_based.md#create-a-dast-cicd-job). -1. Set the `DAST_FF_ENABLE_BAS` [CI/CD variable](../dast/browser_based.md#available-cicd-variables) to `true`. + WARNING: + The latest version of the template may include breaking changes. Use the + stable template unless you need a feature provided only in the latest template. + + For more information about template versioning, see the [CI/CD documentation](../../../development/cicd/templates.md#latest-version). + +1. Choose one of the following options for running BAS extended DAST scans: + + - [Enable a separate BAS extended DAST job](#enable-a-separate-bas-extended-dast-job) + + - You're not using the latest DAST template yet. + - Continue using a stable version of the DAST security analyzer image for DAST scans. + - Create a duplicate `dast_with_bas` job which extends your existing DAST job configuration. + + - [Extend an existing DAST job](#extend-an-existing-dast-job) + - You're already using the latest DAST template rather than the stable template. + - Extend your existing DAST job to include the latest DAST security analyzer image tag from the Breach and Attack Simulation SEG. + +1. Setup a callback server to [enable callback attacks](#enable-callback-attacks). + +### Enable a separate BAS extended DAST job + +To maintain a separate DAST job while testing the BAS extended DAST image: + +1. Add a `dast` stage to your GitLab CI/CD stages configuration. + + ```yaml + stages: + - build + - test + - deploy + - dast + ``` + +1. Set the `DAST_WEBSITE` [CI/CD variable](../../../ci/yaml/index.md#variables). + + ```yaml + dast_with_bas: + variables: + DAST_WEBSITE: http://yourapp + ``` + +### Extend an existing DAST job + +To enable Breach and Attack Simulation features inside of an existing DAST job: -```yaml -include: - - template: DAST.gitlab-ci.yml +1. Follow the steps in [Create a DAST CI/CD job](../dast/browser_based.md#create-a-dast-cicd-job). -dast: - variables: - DAST_BROWSER_SCAN: "true" - DAST_FF_ENABLE_BAS: "true" - DAST_WEBSITE: "https://my.site.com" -``` +1. Extend DAST to using the [extends](../../../ci/yaml/yaml_optimization.md#use-extends-to-reuse-configuration-sections) keyword to your DAST job's configuration: + + ```yaml + dast: + extends: .dast_with_bas + ``` + +1. Disable the `dast+job` job included in the BAS template by setting `DAST_BAS_DISABLED`: + + ```yaml + variables: + DAST_BAS_DISABLED: "true" + ``` + +### Enable callback attacks + +DISCLAIMER: +This page contains information related to upcoming products, features, and functionality. +It is important to note that the information presented is for informational purposes only. +Please do not rely on this information for purchasing or planning purposes. +As with all projects, the items mentioned on this page are subject to change or delay. +The development, release, and timing of any products, features, or functionality remain at the +sole discretion of GitLab Inc. + +Perform Out-of-Band Application Security Testing (OAST) for certain [active checks](../dast/checks/index.md#active-checks). + +1. Extend the `.dast_with_bas_using_services` job configuration using the [extends](../../../ci/yaml/yaml_optimization.md#use-extends-to-reuse-configuration-sections) keyword: + + ```yaml + dast: + extends: .dast_with_bas_using_services + + dast_with_bas: + extends: + # NOTE: extends overwrites rather than merges so dast must be included in this list. + - dast + - .dast_with_bas_using_services + ``` + +1. Use a [!reference tag](../../../ci/yaml/yaml_optimization.md#reference-tags) to pull in the default `callback` service container in your `services`. + + ```yaml + services: + # NOTE: services overwrites rather than merges so it must be referenced to merge. + - !reference [.dast_with_bas_using_services, services] + - name: $CI_REGISTRY_IMAGE + alias: yourapp + ``` + +You can also manually enable callback attacks by making sure to: + +1. Set the `DAST_FF_ENABLE_BAS` [CI/CD variable](../dast/browser_based.md#available-cicd-variables) to `true`. +1. Enable both the application being tested and callback service container using [services](../../../ci/services/index.md). +1. Enable container-to-container networking [making the callback service accessible](../../../ci/services/index.md#connecting-services) in the job. +1. Set `DAST_BROWSER_CALLBACK` to include `Address:$YOUR_CALLBACK_URL` key/value pair where the callback service is accessible to the Runner/DAST container. diff --git a/doc/user/application_security/vulnerability_report/img/project_security_dashboard_status_change_v14_2.png b/doc/user/application_security/vulnerability_report/img/project_security_dashboard_status_change_v14_2.png Binary files differdeleted file mode 100644 index a43340544ca..00000000000 --- a/doc/user/application_security/vulnerability_report/img/project_security_dashboard_status_change_v14_2.png +++ /dev/null diff --git a/doc/user/application_security/vulnerability_report/img/project_security_dashboard_status_change_v16_0.png b/doc/user/application_security/vulnerability_report/img/project_security_dashboard_status_change_v16_0.png Binary files differnew file mode 100644 index 00000000000..fd9626be2d9 --- /dev/null +++ b/doc/user/application_security/vulnerability_report/img/project_security_dashboard_status_change_v16_0.png diff --git a/doc/user/application_security/vulnerability_report/index.md b/doc/user/application_security/vulnerability_report/index.md index a4c4737f767..0826258de9e 100644 --- a/doc/user/application_security/vulnerability_report/index.md +++ b/doc/user/application_security/vulnerability_report/index.md @@ -161,7 +161,8 @@ If Jira issue support is enabled, the issue link found in the Activity entry lin ## Change status of vulnerabilities -> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292636) in GitLab 13.10, all statuses became selectable. +> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/292636) in GitLab 13.10, all statuses became selectable. +> - Providing a comment and dismissal reason [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/408366) in GitLab 16.0. From the Vulnerability Report you can change the status of one or more vulnerabilities. @@ -170,9 +171,11 @@ To change the status of vulnerabilities in the table: 1. Select the checkbox beside each vulnerability you want to update the status of. To select all, select the checkbox in the table header. 1. In the **Set status** dropdown list, select the desired status. +1. If the **Dismissed** status is chosen, select the desired reason in the **Set dismissal reason** dropdown list. +1. In the **Add a comment** input, you can provide a comment. For the **Dismissed** status, a comment is required. 1. Select **Change status**. - + ## Sort vulnerabilities by date detected diff --git a/doc/user/group/import/index.md b/doc/user/group/import/index.md index 25467f3a6f8..1ff71d50e2d 100644 --- a/doc/user/group/import/index.md +++ b/doc/user/group/import/index.md @@ -91,6 +91,8 @@ make sure to have a similar setup on the destination instance, or to import into ### Prerequisites +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. + To migrate groups by direct transfer: - The network connection between instances or GitLab.com must support HTTPS. diff --git a/doc/user/profile/personal_access_tokens.md b/doc/user/profile/personal_access_tokens.md index 0c733b8de30..68c9a5a4356 100644 --- a/doc/user/profile/personal_access_tokens.md +++ b/doc/user/profile/personal_access_tokens.md @@ -100,6 +100,8 @@ To view the last time a token was used: ## Personal access token scopes +> Personal access tokens no longer being able to access container or package registries [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/387721) in GitLab 16.0. + A personal access token can perform actions based on the assigned scopes. | Scope | Access | @@ -114,6 +116,9 @@ A personal access token can perform actions based on the assigned scopes. | `sudo` | Grants permission to perform API actions as any user in the system, when authenticated as an administrator. | | `admin_mode` | Grants permission to perform API actions as an administrator, when Admin Mode is enabled. ([Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107875) in GitLab 15.8.) | +WARNING: +If you enabled [external authorization](../admin_area/settings/external_authorization.md), personal access tokens cannot access container or package registries. If you use personal access tokens to access these registries, this measure breaks this use of these tokens. Disable external authorization to use personal access tokens with container or package registries. + ## When personal access tokens expire Personal access tokens expire on the date you define, at midnight UTC. diff --git a/doc/user/project/import/bitbucket.md b/doc/user/project/import/bitbucket.md index 4d84bc92c37..42eb690af64 100644 --- a/doc/user/project/import/bitbucket.md +++ b/doc/user/project/import/bitbucket.md @@ -32,6 +32,8 @@ When importing: ## Prerequisites +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. + - [Bitbucket Cloud integration](../../../integration/bitbucket.md) must be enabled. If that integration is not enabled, ask your GitLab administrator to enable it. The Bitbucket Cloud integration is enabled by default on GitLab.com. - [Bitbucket Cloud import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) must be enabled. If not enabled, ask your diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md index 22f81365755..451a15de92a 100644 --- a/doc/user/project/import/bitbucket_server.md +++ b/doc/user/project/import/bitbucket_server.md @@ -25,14 +25,20 @@ created as private in GitLab as well. > Ability to re-import projects [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/23905) in GitLab 15.9. -Prerequisites: +You can import Bitbucket repositories to GitLab. + +### Prerequisites + +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. - [Bitbucket Server import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) -must be enabled. If not enabled, ask your GitLab administrator to enable it. The Bitbucket Server import source is enabled -by default on GitLab.com. + must be enabled. If not enabled, ask your GitLab administrator to enable it. The Bitbucket Server import source is enabled + by default on GitLab.com. - At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. +### Import repositories + To import your Bitbucket repositories: 1. Sign in to GitLab. diff --git a/doc/user/project/import/fogbugz.md b/doc/user/project/import/fogbugz.md index 6e378ccbb44..6f5e8e446d6 100644 --- a/doc/user/project/import/fogbugz.md +++ b/doc/user/project/import/fogbugz.md @@ -15,14 +15,18 @@ The importer imports all of your cases and comments with the original case numbers and timestamps. You can also map FogBugz users to GitLab users. -Prerequisite: +## Prerequisites + +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. - [FogBugz import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) -must be enabled. If not enabled, ask your GitLab administrator to enable it. The FogBugz import source is enabled -by default on GitLab.com. + must be enabled. If not enabled, ask your GitLab administrator to enable it. The FogBugz import source is enabled + by default on GitLab.com. - At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. +## Import project from FogBugz + To import your project from FogBugz: 1. Sign in to GitLab. diff --git a/doc/user/project/import/gitea.md b/doc/user/project/import/gitea.md index 2eb798fab0f..d600c26276a 100644 --- a/doc/user/project/import/gitea.md +++ b/doc/user/project/import/gitea.md @@ -8,18 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/381902) in GitLab 15.8, GitLab no longer automatically creates namespaces or groups that don't exist. GitLab also no longer falls back to using the user's personal namespace if the namespace or group name is taken. -Import your projects from Gitea to GitLab with minimal effort. - -NOTE: -This requires Gitea `v1.0.0` or later. - -Prerequisite: - -- [Gitea import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) -must be enabled. If not enabled, ask your GitLab administrator to enable it. The Gitea import source is enabled -by default on GitLab.com. -- At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was - [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. +Import your projects from Gitea to GitLab. The Gitea importer can import: @@ -33,13 +22,22 @@ The Gitea importer can import: When importing, repository public access is retained. If a repository is private in Gitea, it's created as private in GitLab as well. -## How it works - Because Gitea isn't an OAuth provider, author/assignee can't be mapped to users in your GitLab instance. This means the project creator (usually the user that started the import process) is set as the author. A reference, however, is kept on the issue about the original Gitea author. +## Prerequisites + +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. + +- Gitea version 1.0.0 or later. +- [Gitea import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) + must be enabled. If not enabled, ask your GitLab administrator to enable it. The Gitea import source is enabled + by default on GitLab.com. +- At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was + [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. + ## Import your Gitea repositories The importer page is visible when you create a new project. diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md index 4bbb8cee534..ad951994f69 100644 --- a/doc/user/project/import/github.md +++ b/doc/user/project/import/github.md @@ -36,6 +36,8 @@ For an overview of the import process, see [Migrating from GitHub to GitLab](htt ## Prerequisites +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. + To import projects from GitHub: - [GitHub import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) diff --git a/doc/user/project/import/index.md b/doc/user/project/import/index.md index b71ac240113..1265b8534d0 100644 --- a/doc/user/project/import/index.md +++ b/doc/user/project/import/index.md @@ -14,11 +14,6 @@ If you want to bring existing projects to GitLab or copy GitLab projects to a di - Between a self-managed instance and GitLab.com in both directions. - In the same GitLab instance. -Prerequisite: - -- At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was - [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. - For any type of source and target, you can migrate GitLab projects: - When [migrating groups by direct transfer](../../group/import/index.md#migrate-groups-by-direct-transfer-recommended), diff --git a/doc/user/project/import/jira.md b/doc/user/project/import/jira.md index e9c016c5d2b..ede9eb244c6 100644 --- a/doc/user/project/import/jira.md +++ b/doc/user/project/import/jira.md @@ -37,16 +37,10 @@ iterations of the GitLab Jira importer. ## Prerequisites -### Permissions - -To be able to import issues from a Jira project you must have read access on Jira -issues and at least the Maintainer role in the GitLab project that you wish to import into. - -### Jira integration - -This feature uses the existing GitLab [Jira integration](../../../integration/jira/index.md). - -Make sure you have the integration set up before trying to import Jira issues. +- To be able to import issues from a Jira project you must have read access on Jira + issues and at least the Maintainer role in the GitLab project that you wish to import into. +- This feature uses the existing GitLab [Jira integration](../../../integration/jira/index.md). + Make sure you have the integration set up before trying to import Jira issues. ## Import Jira issues to GitLab @@ -63,7 +57,7 @@ To import Jira issues to a GitLab project:  - The **Import from Jira** option is only visible if you have the [correct permissions](#permissions). + The **Import from Jira** option is only visible if you have the [correct permissions](#prerequisites). The following form appears. If you've previously set up the [Jira integration](../../../integration/jira/index.md), you can now see diff --git a/doc/user/project/import/manifest.md b/doc/user/project/import/manifest.md index 545fd7810dc..6a8c40ec601 100644 --- a/doc/user/project/import/manifest.md +++ b/doc/user/project/import/manifest.md @@ -15,11 +15,13 @@ based on a manifest file like the one used by the Use the manifest to import a project with many repositories like the Android Open Source Project (AOSP). -## Requirements +## Prerequisites + +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. - [Manifest import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) -must be enabled. If not enabled, ask your GitLab administrator to enable it. The Manifest import source is enabled -by default on GitLab.com. + must be enabled. If not enabled, ask your GitLab administrator to enable it. The Manifest import source is enabled + by default on GitLab.com. - GitLab must use PostgreSQL for its database, because [subgroups](../../group/subgroups/index.md) are needed for the manifest import to work. Read more about the [database requirements](../../../install/requirements.md#database). - At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was diff --git a/doc/user/project/import/repo_by_url.md b/doc/user/project/import/repo_by_url.md index 9f6d16cc04a..a4868fed94f 100644 --- a/doc/user/project/import/repo_by_url.md +++ b/doc/user/project/import/repo_by_url.md @@ -6,15 +6,19 @@ info: To determine the technical writer assigned to the Stage/Group associated w # Import project from repository by URL **(FREE)** -Prerequisite: +You can import your existing repositories by providing the Git URL. + +## Prerequisites + +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. - [Repository by URL import source](../../admin_area/settings/visibility_and_access_controls.md#configure-allowed-import-sources) -must be enabled. If not enabled, ask your GitLab administrator to enable it. The Repository by URL import source is enabled -by default on GitLab.com. + must be enabled. If not enabled, ask your GitLab administrator to enable it. The Repository by URL import source is enabled + by default on GitLab.com. - At least the Maintainer role on the destination group to import to. Using the Developer role for this purpose was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. -You can import your existing repositories by providing the Git URL: +## Import project by URL 1. In GitLab, on the top bar, select **Main menu > Projects > View all projects**. 1. On the right of the page, select **New project**. diff --git a/doc/user/project/merge_requests/drafts.md b/doc/user/project/merge_requests/drafts.md index 839f3d17a43..88e5e4a6283 100644 --- a/doc/user/project/merge_requests/drafts.md +++ b/doc/user/project/merge_requests/drafts.md @@ -30,7 +30,7 @@ There are several ways to flag a merge request as a draft: below the **Title** field. - **Commenting in an existing merge request**: Add the `/draft` [quick action](../quick_actions.md#issues-merge-requests-and-epics) - in a comment. GitLab 15.4 [deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92654) the toggle behavior of `/draft`. To mark a merge request as ready, use `/ready`. + in a comment. To mark a merge request as ready, use `/ready`. - **Creating a commit**: Add `draft:`, `Draft:`, `fixup!`, or `Fixup!` to the beginning of a commit message targeting the merge request's source branch. This is not a toggle, and adding this text again in a later commit doesn't mark the diff --git a/doc/user/project/quick_actions.md b/doc/user/project/quick_actions.md index 777d7119ac6..5324606c1b8 100644 --- a/doc/user/project/quick_actions.md +++ b/doc/user/project/quick_actions.md @@ -71,7 +71,7 @@ threads. Some quick actions might not be available to all subscription tiers. | `/copy_metadata <#issue>` | **{check-circle}** Yes | **{check-circle}** Yes | **{dotted-circle}** No | Copy labels and milestone from another issue in the project. | `/create_merge_request <branch name>` | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Create a new merge request starting from the current issue. | `/done` | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Mark to-do item as done. -| `/draft` | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Set the [draft status](merge_requests/drafts.md). Use for toggling the draft status ([deprecated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92654) in GitLab 15.4.) | +| `/draft` | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Set the [draft status](merge_requests/drafts.md). | | `/due <date>` | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Set due date. Examples of valid `<date>` include `in 2 days`, `this Friday` and `December 31st`. See [Chronic](https://gitlab.com/gitlab-org/ruby/gems/gitlab-chronic#examples) for more examples. | `/duplicate <#issue>` | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Close this issue. Mark as a duplicate of, and related to, issue `<#issue>`. | `/epic <epic>` | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Add to epic `<epic>`. The `<epic>` value should be in the format of `&epic`, `group&epic`, or a URL to an epic. diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md index acafdb2dd7a..baa7470b309 100644 --- a/doc/user/project/settings/import_export.md +++ b/doc/user/project/settings/import_export.md @@ -189,11 +189,15 @@ Migrating projects with file exports uses the same export and import mechanisms > Default maximum import file size [changed](https://gitlab.com/gitlab-org/gitlab/-/issues/251106) from 50 MB to unlimited in GitLab 13.8. Administrators of self-managed instances can [set maximum import file size](#set-maximum-import-file-size). On GitLab.com, the value is [set to 5 GB](../../gitlab_com/index.md#account-and-limit-settings). +You can import a project and its data. + WARNING: Only import projects from sources you trust. If you import a project from an untrusted source, it may be possible for an attacker to steal your sensitive data. -Prerequisites: +### Prerequisites + +> Requirement for Maintainer role instead of Developer role introduced in GitLab 16.0 and backported to GitLab 15.11.1 and GitLab 15.10.5. - You must have [exported the project and its data](#export-a-project-and-its-data). - Compare GitLab versions and ensure you are importing to a GitLab version that is the same or later @@ -202,6 +206,8 @@ Prerequisites: - At least the Maintainer role on the destination group to migrate to. Using the Developer role for this purpose was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387891) in GitLab 15.8 and will be removed in GitLab 16.0. +### Import a project + To import a project: 1. When [creating a new project](../index.md#create-a-project), |
