diff options
Diffstat (limited to 'doc')
30 files changed, 716 insertions, 77 deletions
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index e59ab5a72e1..1bb018e368b 100644 --- a/doc/administration/job_artifacts.md +++ b/doc/administration/job_artifacts.md @@ -123,6 +123,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a | `provider` | Always `AWS` for compatible hosts | AWS | | `aws_access_key_id` | AWS credentials, or compatible | | | `aws_secret_access_key` | AWS credentials, or compatible | | +| `aws_signature_version` | AWS signature version to use. 2 or 4 are valid options. Digital Ocean Spaces and other providers may need 2. | 4 | | `region` | AWS region | us-east-1 | | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com | | `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) | diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md index 39bd19ac851..087fe729b28 100644 --- a/doc/administration/repository_storage_types.md +++ b/doc/administration/repository_storage_types.md @@ -82,6 +82,46 @@ To migrate your existing projects to the new storage type, check the specific [rake tasks]: raketasks/storage.md#migrate-existing-projects-to-hashed-storage [storage-paths]: repository_storage_types.md +#### Rollback + +There is no automated rollback implemented. Below are the steps required to rollback +from each storage migration. + +The rollback has to be performed in the reverse order. To get into "Legacy" state, +you need to rollback Attachments first, then Project. + +Also note that if Geo is enabled, after the migration was triggered, an event is generated +to replicate the operation on any Secondary node. That means the on disk changes will also +need to be performed on these nodes as well. Database changes will propagate without issues. + +You must make sure the migration event was already processed or otherwise it may migrate +the files back to Hashed state again. + +##### Attachments + +To rollback single Attachment migration, rename `aa/bb/abcdef1234567890...` folder back to `namespace/project`. + +Both folder names can be generated by the `FileUploader.absolute_base_dir(project)`, you +just need to switch the version from the `project` back to the previous one. + +```ruby +project.storage_version +# => 2 + +FileUploader.absolute_base_dir(project) +# => "/opt/gitlab/embedded/service/gitlab-rails/public/uploads/@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35" + +project.storage_version = 1 + +FileUploader.absolute_base_dir(project) +# => "/opt/gitlab/embedded/service/gitlab-rails/public/uploads/gitlab/gitlab-shell-renamed" +``` + +##### Project + +To rollback single Project migration, move `@hashed/aa/bb/aabbcdef1234567890abcdef.git` and `@hashed/aa/bb/aabbcdef1234567890abcdef.wiki.git` +back to `namespace/project.git` and `namespace/project.wiki.git` respectively and switch the version from the `project` back to `null`. + ### Hashed Storage coverage We are incrementally moving every storable object in GitLab to the Hashed @@ -100,6 +140,30 @@ which is true for CI Cache and LFS Objects. | Pages | Yes | No | - | - | | Docker Registry | Yes | No | - | - | | CI Build Logs | No | No | - | - | -| CI Artifacts | No | No | Yes (Premium) | - | +| CI Artifacts | No | No | Yes | 9.4 / 10.6 | | CI Cache | No | No | Yes | - | -| LFS Objects | Yes | No | Yes (Premium) | - | +| LFS Objects | Yes | Similar | Yes | 10.0 / 10.7 | + +#### Implementation Details + +##### Avatars + +Each file is stored in a folder with its `id` from the database. The filename is always `avatar.png` for user avatars. +When avatar is replaced, `Upload` model is destroyed and a new one takes place with different `id`. + +##### CI Artifacts + +CI Artifacts are S3 compatible since **9.4** (GitLab Premium), and available in GitLab Core since **10.6**. + +##### LFS Objects + +LFS Objects implements a similar storage pattern using 2 chars, 2 level folders, following git own implementation: + +```ruby +"shared/lfs-objects/#{oid[0..1}/#{oid[2..3]}/#{oid[4..-1]}" + +# Based on object `oid`: `8909029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c`, path will be: +"shared/lfs-objects/89/09/029eb962194cfb326259411b22ae3f4a814b5be4f80651735aeef9f3229c" +``` + +They are also S3 compatible since **10.0** (GitLab Premium), and available in GitLab Core since **10.7**. diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md index 7f0bd8f04e3..6688181c5a8 100644 --- a/doc/administration/uploads.md +++ b/doc/administration/uploads.md @@ -79,6 +79,7 @@ The connection settings match those provided by [Fog](https://github.com/fog), a | `provider` | Always `AWS` for compatible hosts | AWS | | `aws_access_key_id` | AWS credentials, or compatible | | | `aws_secret_access_key` | AWS credentials, or compatible | | +| `aws_signature_version` | AWS signature version to use. 2 or 4 are valid options. Digital Ocean Spaces and other providers may need 2. | 4 | | `region` | AWS region | us-east-1 | | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com | | `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) | diff --git a/doc/api/graphql/index.md b/doc/api/graphql/index.md index 59e27922f64..71922318227 100644 --- a/doc/api/graphql/index.md +++ b/doc/api/graphql/index.md @@ -1,4 +1,4 @@ -# GraphQL API (Beta) +# GraphQL API (Alpha) > [Introduced][ce-19008] in GitLab 11.0. diff --git a/doc/api/groups.md b/doc/api/groups.md index a48905f2f15..53d72509423 100644 --- a/doc/api/groups.md +++ b/doc/api/groups.md @@ -147,6 +147,8 @@ Parameters: | `simple` | boolean | no | Return only the ID, URL, name, and path of each project | | `owned` | boolean | no | Limit by projects owned by the current user | | `starred` | boolean | no | Limit by projects starred by the current user | +| `with_issues_enabled` | boolean | no | Limit by enabled issues feature | +| `with_merge_requests_enabled` | boolean | no | Limit by enabled merge requests feature | | `with_custom_attributes` | boolean | no | Include [custom attributes](custom_attributes.md) in response (admins only) | Example response: diff --git a/doc/api/merge_requests.md b/doc/api/merge_requests.md index da74045b702..2057ed3588a 100644 --- a/doc/api/merge_requests.md +++ b/doc/api/merge_requests.md @@ -11,7 +11,7 @@ default it returns only merge requests created by the current user. To get all merge requests, use parameter `scope=all`. The `state` parameter can be used to get only merge requests with a -given state (`opened`, `closed`, or `merged`) or all of them (`all`). +given state (`opened`, `closed`, `locked`, or `merged`) or all of them (`all`). It should be noted that when searching by `locked` it will mostly return no results as it is a short-lived, transitional state. The pagination parameters `page` and `per_page` can be used to restrict the list of merge requests. @@ -35,7 +35,7 @@ Parameters: | Attribute | Type | Required | Description | | ------------------- | -------- | -------- | ---------------------------------------------------------------------------------------------------------------------- | -| `state` | string | no | Return all merge requests or just those that are `opened`, `closed`, or `merged` | +| `state` | string | no | Return all merge requests or just those that are `opened`, `closed`, `locked`, or `merged` | | `order_by` | string | no | Return requests ordered by `created_at` or `updated_at` fields. Default is `created_at` | | `sort` | string | no | Return requests sorted in `asc` or `desc` order. Default is `desc` | | `milestone` | string | no | Return merge requests for a specific milestone | @@ -122,7 +122,7 @@ Parameters: ## List project merge requests Get all merge requests for this project. -The `state` parameter can be used to get only merge requests with a given state (`opened`, `closed`, or `merged`) or all of them (`all`). +The `state` parameter can be used to get only merge requests with a given state (`opened`, `closed`, `locked`, or `merged`) or all of them (`all`). The pagination parameters `page` and `per_page` can be used to restrict the list of merge requests. ``` @@ -155,7 +155,7 @@ Parameters: | ------------------- | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------ | | `id` | integer | yes | The ID of a project | | `iids[]` | Array[integer] | no | Return the request having the given `iid` | -| `state` | string | no | Return all merge requests or just those that are `opened`, `closed`, or `merged` | +| `state` | string | no | Return all merge requests or just those that are `opened`, `closed`, `locked`, or `merged` | | `order_by` | string | no | Return requests ordered by `created_at` or `updated_at` fields. Default is `created_at` | | `sort` | string | no | Return requests sorted in `asc` or `desc` order. Default is `desc` | | `milestone` | string | no | Return merge requests for a specific milestone | @@ -243,7 +243,7 @@ Parameters: ## List group merge requests Get all merge requests for this group and its subgroups. -The `state` parameter can be used to get only merge requests with a given state (`opened`, `closed`, or `merged`) or all of them (`all`). +The `state` parameter can be used to get only merge requests with a given state (`opened`, `closed`, `locked`, or `merged`) or all of them (`all`). The pagination parameters `page` and `per_page` can be used to restrict the list of merge requests. ``` @@ -262,7 +262,7 @@ Parameters: | Attribute | Type | Required | Description | | ------------------- | -------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------ | | `id` | integer | yes | The ID of a group | -| `state` | string | no | Return all merge requests or just those that are `opened`, `closed`, or `merged` | +| `state` | string | no | Return all merge requests or just those that are `opened`, `closed`, `locked`, or `merged` | | `order_by` | string | no | Return merge requests ordered by `created_at` or `updated_at` fields. Default is `created_at` | | `sort` | string | no | Return merge requests sorted in `asc` or `desc` order. Default is `desc` | | `milestone` | string | no | Return merge requests for a specific milestone | diff --git a/doc/api/projects.md b/doc/api/projects.md index 30a41839f28..b4599fdc97e 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -1390,6 +1390,16 @@ POST /projects/:id/housekeeping | --------- | ---- | -------- | ----------- | | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) | +### Transfer a project to a new namespace + +``` +PUT /projects/:id/transfer +``` + +| Attribute | Type | Required | Description | +| --------- | ---- | -------- | ----------- | +| `namespace` | integer/string | yes | The ID or path of the namespace to transfer to project to | + ## Branches Read more in the [Branches](branches.md) documentation. diff --git a/doc/api/repositories.md b/doc/api/repositories.md index 5aff255c20a..cb816bbd712 100644 --- a/doc/api/repositories.md +++ b/doc/api/repositories.md @@ -130,6 +130,7 @@ Parameters: - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user - `from` (required) - the commit SHA or branch name - `to` (required) - the commit SHA or branch name +- `straight` (optional) - comparison method, `true` for direct comparison between `from` and `to` (`from`..`to`), `false` to compare using merge base (`from`...`to`)'. Default is `false`. ``` GET /projects/:id/repository/compare?from=master&to=feature diff --git a/doc/api/repository_files.md b/doc/api/repository_files.md index c29dc22e12d..49fb9bc141d 100644 --- a/doc/api/repository_files.md +++ b/doc/api/repository_files.md @@ -27,6 +27,7 @@ Example response: "size": 1476, "encoding": "base64", "content": "IyA9PSBTY2hlbWEgSW5mb3...", + "content_sha256": "4c294617b60715c1d218e61164a3abd4808a4284cbc30e6728a01ad9aada4481", "ref": "master", "blob_id": "79f7bbd25901e8334750839545a9bd021f0e4c83", "commit_id": "d5a3ff139356ce33e37e73add446f16869741b50", @@ -39,6 +40,36 @@ Parameters: - `file_path` (required) - Url encoded full path to new file. Ex. lib%2Fclass%2Erb - `ref` (required) - The name of branch, tag or commit +NOTE: **Note:** +`blob_id` is the blob sha, see [repositories - Get a blob from repository](repositories.md#get-a-blob-from-repository) + +In addition to the `GET` method, you can also use `HEAD` to get just file metadata. + +``` +HEAD /projects/:id/repository/files/:file_path +``` + +```bash +curl --head --header 'PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK' 'https://gitlab.example.com/api/v4/projects/13083/repository/files/app%2Fmodels%2Fkey%2Erb?ref=master' +``` + +Example response: + +```text +HTTP/1.1 200 OK +... +X-Gitlab-Blob-Id: 79f7bbd25901e8334750839545a9bd021f0e4c83 +X-Gitlab-Commit-Id: d5a3ff139356ce33e37e73add446f16869741b50 +X-Gitlab-Content-Sha256: 4c294617b60715c1d218e61164a3abd4808a4284cbc30e6728a01ad9aada4481 +X-Gitlab-Encoding: base64 +X-Gitlab-File-Name: key.rb +X-Gitlab-File-Path: app/models/key.rb +X-Gitlab-Last-Commit-Id: 570e7b2abdd848b95f2f578043fc23bd6f6fd24d +X-Gitlab-Ref: master +X-Gitlab-Size: 1476 +... +``` + ## Get raw file from repository ``` @@ -54,6 +85,9 @@ Parameters: - `file_path` (required) - Url encoded full path to new file. Ex. lib%2Fclass%2Erb - `ref` (required) - The name of branch, tag or commit +NOTE: **Note:** +Like [Get file from repository](repository_files.md#get-file-from-repository) you can use `HEAD` to get just file metadata. + ## Create new file in repository ``` diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md index 07b144f6ddd..fbac37e688e 100644 --- a/doc/ci/docker/using_docker_build.md +++ b/doc/ci/docker/using_docker_build.md @@ -134,9 +134,20 @@ In order to do that, follow the steps: ```yaml image: docker:stable - # When using dind, it's wise to use the overlayfs driver for - # improved performance. variables: + # When using dind service we need to instruct docker, to talk with the + # daemon started inside of the service. The daemon is available with + # a network connection instead of the default /var/run/docker.sock socket. + # + # The 'docker' hostname is the alias of the service container as described at + # https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#accessing-the-services + # + # Note that if you're using Kubernetes executor, the variable should be set to + # tcp://localhost:2375 because of how Kubernetes executor connects services + # to the job container + DOCKER_HOST: tcp://docker:2375/ + # When using dind, it's wise to use the overlayfs driver for + # improved performance. DOCKER_DRIVER: overlay2 services: @@ -293,6 +304,7 @@ services: variables: CONTAINER_IMAGE: registry.gitlab.com/$CI_PROJECT_PATH + DOCKER_HOST: tcp://docker:2375 DOCKER_DRIVER: overlay2 before_script: @@ -391,6 +403,9 @@ could look like: image: docker:stable services: - docker:dind + variables: + DOCKER_HOST: tcp://docker:2375 + DOCKER_DRIVER: overlay2 stage: build script: - docker login -u gitlab-ci-token -p $CI_JOB_TOKEN registry.example.com @@ -410,6 +425,8 @@ services: - docker:dind variables: + DOCKER_HOST: tcp://docker:2375 + DOCKER_DRIVER: overlay2 IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_NAME before_script: @@ -445,6 +462,8 @@ stages: - deploy variables: + DOCKER_HOST: tcp://docker:2375 + DOCKER_DRIVER: overlay2 CONTAINER_TEST_IMAGE: registry.example.com/my-group/my-project/my-image:$CI_COMMIT_REF_NAME CONTAINER_RELEASE_IMAGE: registry.example.com/my-group/my-project/my-image:latest diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 26dcf67fe23..096b64eb881 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -942,6 +942,11 @@ useful when you'd like to download the archive from GitLab. The `artifacts:name` variable can make use of any of the [predefined variables](../variables/README.md). The default name is `artifacts`, which becomes `artifacts.zip` when downloaded. +NOTE: **Note:** +If your branch-name contains forward slashes +(e.g. `feature/my-feature`) it is advised to use `$CI_COMMIT_REF_SLUG` +instead of `$CI_COMMIT_REF_NAME` for proper naming of the artifact. + To create an archive with a name of the current job: ```yaml diff --git a/doc/development/api_graphql_styleguide.md b/doc/development/api_graphql_styleguide.md index f74e4f0bd7e..33f078b0a63 100644 --- a/doc/development/api_graphql_styleguide.md +++ b/doc/development/api_graphql_styleguide.md @@ -54,6 +54,51 @@ a new presenter specifically for GraphQL. The presenter is initialized using the object resolved by a field, and the context. +### Exposing permissions for a type + +To expose permissions the current user has on a resource, you can call +the `expose_permissions` passing in a separate type representing the +permissions for the resource. + +For example: + +```ruby +module Types + class MergeRequestType < BaseObject + expose_permissions Types::MergeRequestPermissionsType + end +end +``` + +The permission type inherits from `BasePermissionType` which includes +some helper methods, that allow exposing permissions as non-nullable +booleans: + +```ruby +class MergeRequestPermissionsType < BasePermissionType + present_using MergeRequestPresenter + + graphql_name 'MergeRequestPermissions' + + abilities :admin_merge_request, :update_merge_request, :create_note + + ability_field :resolve_note, + description: 'Whether or not the user can resolve disussions on the merge request' + permission_field :push_to_source_branch, method: :can_push_to_source_branch? +end +``` + +- **`permission_field`**: Will act the same as `graphql-ruby`'s + `field` method but setting a default description and type and making + them non-nullable. These options can still be overridden by adding + them as arguments. +- **`ability_field`**: Expose an ability defined in our policies. This + takes behaves the same way as `permission_field` and the same + arguments can be overridden. +- **`abilities`**: Allows exposing several abilities defined in our + policies at once. The fields for these will all have be non-nullable + booleans with a default description. + ## Resolvers To find objects to display in a field, we can add resolvers to diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md index 48e1685082a..f5cdd310f6f 100644 --- a/doc/development/documentation/index.md +++ b/doc/development/documentation/index.md @@ -322,50 +322,49 @@ to EE only. ## Previewing the changes live -To preview your changes to documentation locally, please follow -this [development guide](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/README.md#development). +NOTE: **Note:** +To preview your changes to documentation locally, follow this +[development guide](https://gitlab.com/gitlab-com/gitlab-docs/blob/master/README.md#development). -If you want to preview the doc changes of your merge request live, you can use -the manual `review-docs-deploy` job in your merge request. You will need at -least Maintainer permissions to be able to run it and is currently enabled for the -following projects: +The live preview is currently enabled for the following projects: - https://gitlab.com/gitlab-org/gitlab-ce - https://gitlab.com/gitlab-org/gitlab-ee +- https://gitlab.com/gitlab-org/gitlab-runner -NOTE: **Note:** -You will need to push a branch to those repositories, it doesn't work for forks. - -TIP: **Tip:** If your branch contains only documentation changes, you can use [special branch names](#branch-naming) to avoid long running pipelines. -In the mini pipeline graph, you should see an `>>` icon. Clicking on it will -reveal the `review-docs-deploy` job. Hit the play button for the job to start. +For [docs-only changes](#branch-naming), the review app is run automatically. +For all other branches, you can use the manual `review-docs-deploy-manual` job +in your merge request. You will need at least Maintainer permissions to be able +to run it. In the mini pipeline graph, you should see an `>>` icon. Clicking on it will +reveal the `review-docs-deploy-manual` job. Hit the play button for the job to start.  -This job will: +NOTE: **Note:** +You will need to push a branch to those repositories, it doesn't work for forks. + +The `review-docs-deploy*` job will: 1. Create a new branch in the [gitlab-docs](https://gitlab.com/gitlab-com/gitlab-docs) - project named after the scheme: `preview-<branch-slug>` + project named after the scheme: `$DOCS_GITLAB_REPO_SUFFIX-$CI_ENVIRONMENT_SLUG`, + where `DOCS_GITLAB_REPO_SUFFIX` is the suffix for each product, e.g, `ce` for + CE, etc. 1. Trigger a cross project pipeline and build the docs site with your changes After a few minutes, the Review App will be deployed and you will be able to preview the changes. The docs URL can be found in two places: - In the merge request widget -- In the output of the `review-docs-deploy` job, which also includes the +- In the output of the `review-docs-deploy*` job, which also includes the triggered pipeline so that you can investigate whether something went wrong In case the Review App URL returns 404, follow these steps to debug: 1. **Did you follow the URL from the merge request widget?** If yes, then check if - the link is the same as the one in the job output. It can happen that if the - branch name slug is longer than 35 characters, it is automatically - truncated. That means that the merge request widget will not show the proper - URL due to a limitation of how `environment: url` works, but you can find the - real URL from the output of the `review-docs-deploy` job. + the link is the same as the one in the job output. 1. **Did you follow the URL from the job output?** If yes, then it means that either the site is not yet deployed or something went wrong with the remote pipeline. Give it a few minutes and it should appear online, otherwise you diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 7f061d06da8..32de741c9fe 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -5,7 +5,7 @@ - **Write documentation.**: Add documentation to the `doc/` directory. Describe the feature and include screenshots, if applicable. - **Submit a MR to the `www-gitlab-com` project.**: Add the new feature to the - [EE features list][ee-features-list]. + [EE features list](https://about.gitlab.com/features/). ## Act as CE when unlicensed diff --git a/doc/development/i18n/externalization.md b/doc/development/i18n/externalization.md index 4ba9958e2c6..f7d703b8f0b 100644 --- a/doc/development/i18n/externalization.md +++ b/doc/development/i18n/externalization.md @@ -174,6 +174,8 @@ For example use `%{created_at}` in Ruby but `%{createdAt}` in JavaScript. # => When size == 2: 'There are 2 mice.' ``` + Avoid using `%d` or count variables in sigular strings. This allows more natural translation in some languages. + - In JavaScript: ```js diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md index 9a677bf09b2..9d0d7348df9 100644 --- a/doc/development/i18n/proofreader.md +++ b/doc/development/i18n/proofreader.md @@ -24,6 +24,7 @@ are very appreciative of the work done by translators and proofreaders! - Paolo Falomo - [GitLab](https://gitlab.com/paolofalomo), [Crowdin](https://crowdin.com/profile/paolo.falomo) - Japanese - Yamana Tokiuji - [GitLab](https://gitlab.com/tokiuji), [Crowdin](https://crowdin.com/profile/yamana) + - Hiroyuki Sato - [GitLab](https://gitlab.com/hiroponz), [Crowdin](https://crowdin.com/profile/hiroponz) - Korean - Chang-Ho Cha - [GitLab](https://gitlab.com/changho-cha), [Crowdin](https://crowdin.com/profile/zzazang) - Huang Tao - [GitLab](https://gitlab.com/htve), [Crowdin](https://crowdin.com/profile/htve) @@ -31,6 +32,7 @@ are very appreciative of the work done by translators and proofreaders! - Filip Mech - [GitLab](https://gitlab.com/mehenz), [Crowdin](https://crowdin.com/profile/mehenz) - Portuguese, Brazilian - Paulo George Gomes Bezerra - [GitLab](https://gitlab.com/paulobezerra), [Crowdin](https://crowdin.com/profile/paulogomes.rep) + - André Gama - [GitLab](https://gitlab.com/andregamma), [Crowdin](https://crowdin.com/profile/ToeOficial) - Russian - Nikita Grylov - [GitLab](https://gitlab.com/nixel2007), [Crowdin](https://crowdin.com/profile/nixel2007) - Alexy Lustin - [GitLab](https://gitlab.com/allustin), [Crowdin](https://crowdin.com/profile/lustin) diff --git a/doc/development/what_requires_downtime.md b/doc/development/what_requires_downtime.md index f502866333e..47396666879 100644 --- a/doc/development/what_requires_downtime.md +++ b/doc/development/what_requires_downtime.md @@ -195,22 +195,22 @@ end And that's it, we're done! -## Changing Column Types For Large Tables +## Changing The Schema For Large Tables -While `change_column_type_concurrently` can be used for changing the type of a -column without downtime it doesn't work very well for large tables. Because all -of the work happens in sequence the migration can take a very long time to -complete, preventing a deployment from proceeding. -`change_column_type_concurrently` can also produce a lot of pressure on the -database due to it rapidly updating many rows in sequence. +While `change_column_type_concurrently` and `rename_column_concurrently` can be +used for changing the schema of a table without downtime it doesn't work very +well for large tables. Because all of the work happens in sequence the migration +can take a very long time to complete, preventing a deployment from proceeding. +They can also produce a lot of pressure on the database due to it rapidly +updating many rows in sequence. To reduce database pressure you should instead use -`change_column_type_using_background_migration` when migrating a column in a -large table (e.g. `issues`). This method works similar to -`change_column_type_concurrently` but uses background migration to spread the -work / load over a longer time period, without slowing down deployments. +`change_column_type_using_background_migration` or `rename_column_concurrently` +when migrating a column in a large table (e.g. `issues`). These methods work +similarly to the concurrent counterparts but uses background migration to spread +the work / load over a longer time period, without slowing down deployments. -Usage of this method is fairly simple: +For example, to change the column type using a background migration: ```ruby class ExampleMigration < ActiveRecord::Migration @@ -296,6 +296,15 @@ class MigrateRemainingIssuesClosedAt < ActiveRecord::Migration end ``` +The same applies to `rename_column_using_background_migration`: + +1. Create a migration using the helper, which will schedule background + migrations to spread the writes over a longer period of time. +2. In the next monthly release, create a clean-up migration to steal from the + Sidekiq queues, migrate any missing rows, and cleanup the rename. This + migration should skip the steps after stealing from the Sidekiq queues if the + column has already been renamed. + For more information, see [the documentation on cleaning up background migrations](background_migrations.md#cleaning-up). diff --git a/doc/install/installation.md b/doc/install/installation.md index ef415246583..259d8f73a22 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -12,9 +12,8 @@ Since installations from source don't have Runit, Sidekiq can't be terminated an ## Select Version to Install -Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md) from the tag (version) of GitLab you would like to install. -In most cases this should be the highest numbered production tag (without rc in it). -You can select the tag in the version dropdown in the top left corner of GitLab (below the menu bar). +Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/install/installation.md) from the branch (version) of GitLab you would like to install (e.g., `11-1-stable`). +You can select the branch in the version dropdown in the top left corner of GitLab (below the menu bar). If the highest number stable branch is unclear please check the [GitLab Blog](https://about.gitlab.com/blog/) for installation guide links by version. @@ -301,9 +300,9 @@ sudo usermod -aG redis git ### Clone the Source # Clone GitLab repository - sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 11-0-stable gitlab + sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-ce.git -b 11-1-stable gitlab -**Note:** You can change `11-0-stable` to `master` if you want the *bleeding edge* version, but never install master on a production server! +**Note:** You can change `11-1-stable` to `master` if you want the *bleeding edge* version, but never install master on a production server! ### Configure It diff --git a/doc/install/requirements.md b/doc/install/requirements.md index 1f399a8a3f7..5531dcde4e9 100644 --- a/doc/install/requirements.md +++ b/doc/install/requirements.md @@ -64,16 +64,14 @@ If you have enough RAM memory and a recent CPU the speed of GitLab is mainly lim ### Memory -You need at least 4GB of addressable memory (RAM + swap) to install and use GitLab! +You need at least 8GB of addressable memory (RAM + swap) to install and use GitLab! The operating system and any other running applications will also be using memory so keep in mind that you need at least 4GB available before running GitLab. With less memory GitLab will give strange errors during the reconfigure run and 500 errors during usage. -- 1GB RAM + 3GB of swap is the absolute minimum but we strongly **advise against** this amount of memory. See the [unicorn worker section below](#unicorn-workers) for more advice. -- 2GB RAM + 2GB swap supports up to 100 users but it will be very slow -- **4GB RAM** is the **recommended** memory size for all installations and supports up to 100 users -- 8GB RAM supports up to 1,000 users +- 4GB RAM + 4GB swap supports up to 100 users but it will be very slow +- **8GB RAM** is the **recommended** memory size for all installations and supports up to 100 users - 16GB RAM supports up to 2,000 users - 32GB RAM supports up to 4,000 users - 64GB RAM supports up to 8,000 users diff --git a/doc/integration/openid_connect_provider.md b/doc/integration/openid_connect_provider.md index ad41be52045..a7f907254a1 100644 --- a/doc/integration/openid_connect_provider.md +++ b/doc/integration/openid_connect_provider.md @@ -5,11 +5,11 @@ to sign in to other services. ## Introduction to OpenID Connect -[OpenID Connect] \(OIC) is a simple identity layer on top of the +[OpenID Connect] \(OIDC) is a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by GitLab, as well as to obtain basic profile information about the end-user in an interoperable and -REST-like manner. OIC performs many of the same tasks as OpenID 2.0, +REST-like manner. OIDC performs many of the same tasks as OpenID 2.0, but does so in a way that is API-friendly, and usable by native and mobile applications. @@ -23,14 +23,17 @@ are supported. ## Enabling OpenID Connect for OAuth applications Refer to the [OAuth guide] for basic information on how to set up OAuth -applications in GitLab. To enable OIC for an application, all you have to do +applications in GitLab. To enable OIDC for an application, all you have to do is select the `openid` scope in the application settings. +## Shared information + Currently the following user information is shared with clients: | Claim | Type | Description | |:-----------------|:----------|:------------| -| `sub` | `string` | An opaque token that uniquely identifies the user +| `sub` | `string` | The ID of the user +| `sub_legacy` | `string` | An opaque token that uniquely identifies the user<br><br>**Deprecation notice:** this token isn't stable because it's tied to the Rails secret key base, and is provided only for migration to the new stable `sub` value available from GitLab 11.1 | `auth_time` | `integer` | The timestamp for the user's last authentication | `name` | `string` | The user's full name | `nickname` | `string` | The user's GitLab username @@ -41,6 +44,8 @@ Currently the following user information is shared with clients: | `picture` | `string` | URL for the user's GitLab avatar | `groups` | `array` | Names of the groups the user is a member of +Only the `sub` and `sub_legacy` claims are included in the ID token, all other claims are available from the `/oauth/userinfo` endpoint used by OIDC clients. + [OpenID Connect]: http://openid.net/connect/ "OpenID Connect website" [doorkeeper-openid_connect]: https://github.com/doorkeeper-gem/doorkeeper-openid_connect "Doorkeeper::OpenidConnect website" [OAuth guide]: oauth_provider.md "GitLab as OAuth2 authentication service provider" diff --git a/doc/integration/saml.md b/doc/integration/saml.md index 3f49432ce93..db06efdae53 100644 --- a/doc/integration/saml.md +++ b/doc/integration/saml.md @@ -179,6 +179,81 @@ tell GitLab which groups are external via the `external_groups:` element: } } ``` +## Bypass two factor authentication + +If you want some SAML authentication methods to count as 2FA on a per session basis, you can register them in the +`upstream_two_factor_authn_contexts` list: + +**For Omnibus installations:** + +1. Edit `/etc/gitlab/gitlab.rb`: + + ```ruby + gitlab_rails['omniauth_providers'] = [ + { + name: 'saml', + args: { + assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback', + idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8', + idp_sso_target_url: 'https://login.example.com/idp', + issuer: 'https://gitlab.example.com', + name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', + upstream_two_factor_authn_contexts: + %w( + urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport + urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS + urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN + ) + + }, + label: 'Company Login' # optional label for SAML login button, defaults to "Saml" + } + ] + ``` + +1. Save the file and [reconfigure][] GitLab for the changes to take effect. + +--- + +**For installations from source:** + +1. Edit `config/gitlab.yml`: + + ```yaml + - { + name: 'saml', + args: { + assertion_consumer_service_url: 'https://gitlab.example.com/users/auth/saml/callback', + idp_cert_fingerprint: '43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8', + idp_sso_target_url: 'https://login.example.com/idp', + issuer: 'https://gitlab.example.com', + name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', + upstream_two_factor_authn_contexts: + [ + 'urn:oasis:names:tc:SAML:2.0:ac:classes:CertificateProtectedTransport', + 'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorOTPSMS', + 'urn:oasis:names:tc:SAML:2.0:ac:classes:SecondFactorIGTOKEN' + ] + + }, + label: 'Company Login' # optional label for SAML login button, defaults to "Saml" + } + ``` + +1. Save the file and [restart GitLab][] for the changes ot take effect + + +In addition to the changes in GitLab, make sure that your Idp is returning the +`AuthnContext`. For example: + +```xml + <saml:AuthnStatement> + <saml:AuthnContext> + <saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:MediumStrongCertificateProtectedTransport</saml:AuthnContextClassRef> + </saml:AuthnContext> + </saml:AuthnStatement> +``` + ## Customization ### `auto_sign_in_with_provider` diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index 95221d8b6b1..f1881e0f767 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -195,6 +195,12 @@ This example can be used for a bucket in Amsterdam (AMS3). 1. [Reconfigure GitLab] for the changes to take effect +CAUTION: **Warning:** +If you see `400 Bad Request` by using Digital Ocean Spaces, the cause may be the +usage of backup encryption. Remove or comment the line that +contains `gitlab_rails['backup_encryption']` since Digital Ocean Spaces +doesn't support encryption. + #### Other S3 Providers Not all S3 providers are fully-compatible with the Fog library. For example, @@ -326,6 +332,16 @@ For installations from source: 1. [Restart GitLab] for the changes to take effect +#### Specifying a custom directory for backups + +Note: This option only works for remote storage. If you want to group your backups +you can pass a `DIRECTORY` environment variable: + +``` +sudo gitlab-rake gitlab:backup:create DIRECTORY=daily +sudo gitlab-rake gitlab:backup:create DIRECTORY=weekly +``` + ### Uploading to locally mounted shares You may also send backups to a mounted share (`NFS` / `CIFS` / `SMB` / etc.) by @@ -369,15 +385,6 @@ For installations from source: remote_directory: 'gitlab_backups' ``` -### Specifying a custom directory for backups - -If you want to group your backups you can pass a `DIRECTORY` environment variable: - -``` -sudo gitlab-rake gitlab:backup:create DIRECTORY=daily -sudo gitlab-rake gitlab:backup:create DIRECTORY=weekly -``` - ### Backup archive permissions The backup archives created by GitLab (`1393513186_2014_02_27_gitlab_backup.tar`) diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 1d26a743500..de26d0f7a3f 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -91,7 +91,7 @@ To make full use of Auto DevOps, you will need: for the entire GitLab instance, or [specific Runners](../../ci/runners/README.md#registering-a-specific-runner) that are assigned to specific projects. 1. **Base domain** (needed for Auto Review Apps and Auto Deploy) - You will need - a domain configured with wildcard DNS which is gonna be used by all of your + a domain configured with wildcard DNS which is going to be used by all of your Auto DevOps applications. [Read the specifics](#auto-devops-base-domain). 1. **Kubernetes** (needed for Auto Review Apps, Auto Deploy, and Auto Monitoring) - To enable deployments, you will need Kubernetes 1.5+. You need a [Kubernetes cluster][kubernetes-clusters] diff --git a/doc/update/10.8-to-11.0.md b/doc/update/10.8-to-11.0.md index f9b6044bd2f..22a0c9f950c 100644 --- a/doc/update/10.8-to-11.0.md +++ b/doc/update/10.8-to-11.0.md @@ -4,10 +4,9 @@ comments: false # From 10.8 to 11.0 -Make sure you view this update guide from the tag (version) of GitLab you would -like to install. In most cases this should be the highest numbered production -tag (without rc in it). You can select the tag in the version dropdown at the -top left corner of GitLab (below the menu bar). +Make sure you view this update guide from the branch (version) of GitLab you would +like to install (e.g., `11-0-stable`. You can select the branch in the version +dropdown at the top left corner of GitLab (below the menu bar). If the highest number stable branch is unclear please check the [GitLab Blog](https://about.gitlab.com/blog/archives.html) for installation diff --git a/doc/update/11.0-to-11.1.md b/doc/update/11.0-to-11.1.md new file mode 100644 index 00000000000..306bd417ebf --- /dev/null +++ b/doc/update/11.0-to-11.1.md @@ -0,0 +1,361 @@ +--- +comments: false +--- + +# From 11.0 to 11.1 + +Make sure you view this update guide from the branch (version) of GitLab you would +like to install (e.g., `11-1-stable`. You can select the branch in the version +dropdown at the top left corner of GitLab (below the menu bar). + +If the highest number stable branch is unclear please check the +[GitLab Blog](https://about.gitlab.com/blog/archives.html) for installation +guide links by version. + +### 1. Stop server + +```bash +sudo service gitlab stop +``` + +### 2. Backup + +NOTE: If you installed GitLab from source, make sure `rsync` is installed. + +```bash +cd /home/git/gitlab + +sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production +``` + +### 3. Update Ruby + +NOTE: GitLab 11.0 and higher only support Ruby 2.4.x and dropped support for Ruby 2.3.x. Be +sure to upgrade your interpreter if necessary. + +You can check which version you are running with `ruby -v`. + +Download Ruby and compile it: + +```bash +mkdir /tmp/ruby && cd /tmp/ruby +curl --remote-name --progress https://cache.ruby-lang.org/pub/ruby/2.4/ruby-2.4.4.tar.gz +echo 'ec82b0d53bd0adad9b19e6b45e44d54e9ec3f10c ruby-2.4.4.tar.gz' | shasum -c - && tar xzf ruby-2.4.4.tar.gz +cd ruby-2.4.4 + +./configure --disable-install-rdoc +make +sudo make install +``` + +Install Bundler: + +```bash +sudo gem install bundler --no-ri --no-rdoc +``` + +### 4. Update Node + +GitLab utilizes [webpack](http://webpack.js.org) to compile frontend assets. +This requires a minimum version of node v6.0.0. + +You can check which version you are running with `node -v`. If you are running +a version older than `v6.0.0` you will need to update to a newer version. You +can find instructions to install from community maintained packages or compile +from source at the nodejs.org website. + +<https://nodejs.org/en/download/> + +GitLab also requires the use of yarn `>= v1.2.0` to manage JavaScript +dependencies. + +```bash +curl --silent --show-error https://dl.yarnpkg.com/debian/pubkey.gpg | sudo apt-key add - +echo "deb https://dl.yarnpkg.com/debian/ stable main" | sudo tee /etc/apt/sources.list.d/yarn.list +sudo apt-get update +sudo apt-get install yarn +``` + +More information can be found on the [yarn website](https://yarnpkg.com/en/docs/install). + +### 5. Update Go + +NOTE: GitLab 11.0 and higher only supports Go 1.9.x and newer, and dropped support for Go +1.5.x through 1.8.x. Be sure to upgrade your installation if necessary. + +You can check which version you are running with `go version`. + +Download and install Go: + +```bash +# Remove former Go installation folder +sudo rm -rf /usr/local/go + +curl --remote-name --progress https://dl.google.com/go/go1.10.3.linux-amd64.tar.gz +echo 'fa1b0e45d3b647c252f51f5e1204aba049cde4af177ef9f2181f43004f901035 go1.10.3.linux-amd64.tar.gz' | shasum -a256 -c - && \ + sudo tar -C /usr/local -xzf go1.10.3.linux-amd64.tar.gz +sudo ln -sf /usr/local/go/bin/{go,godoc,gofmt} /usr/local/bin/ +rm go1.10.3.linux-amd64.tar.gz +``` + +### 6. Get latest code + +```bash +cd /home/git/gitlab + +sudo -u git -H git fetch --all --prune +sudo -u git -H git checkout -- db/schema.rb # local changes will be restored automatically +sudo -u git -H git checkout -- locale +``` + +For GitLab Community Edition: + +```bash +cd /home/git/gitlab + +sudo -u git -H git checkout 11-1-stable +``` + +OR + +For GitLab Enterprise Edition: + +```bash +cd /home/git/gitlab + +sudo -u git -H git checkout 11-1-stable-ee +``` + +### 7. Update gitlab-shell + +```bash +cd /home/git/gitlab-shell + +sudo -u git -H git fetch --all --tags --prune +sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_SHELL_VERSION) +sudo -u git -H bin/compile +``` + +### 8. Update gitlab-workhorse + +Install and compile gitlab-workhorse. GitLab-Workhorse uses +[GNU Make](https://www.gnu.org/software/make/). +If you are not using Linux you may have to run `gmake` instead of +`make` below. + +```bash +cd /home/git/gitlab-workhorse + +sudo -u git -H git fetch --all --tags --prune +sudo -u git -H git checkout v$(</home/git/gitlab/GITLAB_WORKHORSE_VERSION) +sudo -u git -H make +``` + +### 9. Update Gitaly + +#### New Gitaly configuration options required + +In order to function Gitaly needs some additional configuration information. Below we assume you installed Gitaly in `/home/git/gitaly` and GitLab Shell in `/home/git/gitlab-shell`. + +```shell +echo ' +[gitaly-ruby] +dir = "/home/git/gitaly/ruby" + +[gitlab-shell] +dir = "/home/git/gitlab-shell" +' | sudo -u git tee -a /home/git/gitaly/config.toml +``` + +#### Check Gitaly configuration + +Due to a bug in the `rake gitlab:gitaly:install` script your Gitaly +configuration file may contain syntax errors. The block name +`[[storages]]`, which may occur more than once in your `config.toml` +file, should be `[[storage]]` instead. + +```shell +sudo -u git -H sed -i.pre-10.1 's/\[\[storages\]\]/[[storage]]/' /home/git/gitaly/config.toml +``` + +#### Compile Gitaly + +```shell +cd /home/git/gitaly +sudo -u git -H git fetch --all --tags --prune +sudo -u git -H git checkout v$(</home/git/gitlab/GITALY_SERVER_VERSION) +sudo -u git -H make +``` + +### 10. Update MySQL permissions + +If you are using MySQL you need to grant the GitLab user the necessary +permissions on the database: + +```bash +mysql -u root -p -e "GRANT TRIGGER ON \`gitlabhq_production\`.* TO 'git'@'localhost';" +``` + +If you use MySQL with replication, or just have MySQL configured with binary logging, +you will need to also run the following on all of your MySQL servers: + +```bash +mysql -u root -p -e "SET GLOBAL log_bin_trust_function_creators = 1;" +``` + +You can make this setting permanent by adding it to your `my.cnf`: + +``` +log_bin_trust_function_creators=1 +``` + +### 11. Update configuration files + +#### New configuration options for `gitlab.yml` + +There might be configuration options available for [`gitlab.yml`][yaml]. View them with the command below and apply them manually to your current `gitlab.yml`: + +```sh +cd /home/git/gitlab + +git diff origin/11-0-stable:config/gitlab.yml.example origin/11-1-stable:config/gitlab.yml.example +``` + +#### Nginx configuration + +Ensure you're still up-to-date with the latest NGINX configuration changes: + +```sh +cd /home/git/gitlab + +# For HTTPS configurations +git diff origin/11-0-stable:lib/support/nginx/gitlab-ssl origin/11-1-stable:lib/support/nginx/gitlab-ssl + +# For HTTP configurations +git diff origin/11-0-stable:lib/support/nginx/gitlab origin/11-1-stable:lib/support/nginx/gitlab +``` + +If you are using Strict-Transport-Security in your installation to continue using it you must enable it in your Nginx +configuration as GitLab application no longer handles setting it. + +If you are using Apache instead of NGINX please see the updated [Apache templates]. +Also note that because Apache does not support upstreams behind Unix sockets you +will need to let gitlab-workhorse listen on a TCP port. You can do this +via [/etc/default/gitlab]. + +[Apache templates]: https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/web-server/apache +[/etc/default/gitlab]: https://gitlab.com/gitlab-org/gitlab-ce/blob/11-1-stable/lib/support/init.d/gitlab.default.example#L38 + +#### SMTP configuration + +If you're installing from source and use SMTP to deliver mail, you will need to add the following line +to config/initializers/smtp_settings.rb: + +```ruby +ActionMailer::Base.delivery_method = :smtp +``` + +See [smtp_settings.rb.sample] as an example. + +[smtp_settings.rb.sample]: https://gitlab.com/gitlab-org/gitlab-ce/blob/11-1-stable/config/initializers/smtp_settings.rb.sample#L13 + +#### Init script + +There might be new configuration options available for [`gitlab.default.example`][gl-example]. View them with the command below and apply them manually to your current `/etc/default/gitlab`: + +```sh +cd /home/git/gitlab + +git diff origin/11-0-stable:lib/support/init.d/gitlab.default.example origin/11-1-stable:lib/support/init.d/gitlab.default.example +``` + +Ensure you're still up-to-date with the latest init script changes: + +```bash +cd /home/git/gitlab + +sudo cp lib/support/init.d/gitlab /etc/init.d/gitlab +``` + +For Ubuntu 16.04.1 LTS: + +```bash +sudo systemctl daemon-reload +``` + +### 12. Install libs, migrations, etc. + +```bash +cd /home/git/gitlab + +# MySQL installations (note: the line below states '--without postgres') +sudo -u git -H bundle install --without postgres development test --deployment + +# PostgreSQL installations (note: the line below states '--without mysql') +sudo -u git -H bundle install --without mysql development test --deployment + +# Optional: clean up old gems +sudo -u git -H bundle clean + +# Run database migrations +sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production + +# Compile GetText PO files + +sudo -u git -H bundle exec rake gettext:compile RAILS_ENV=production + +# Update node dependencies and recompile assets +sudo -u git -H bundle exec rake yarn:install gitlab:assets:clean gitlab:assets:compile RAILS_ENV=production NODE_ENV=production + +# Clean up cache +sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production +``` + +**MySQL installations**: Run through the `MySQL strings limits` and `Tables and data conversion to utf8mb4` [tasks](../install/database_mysql.md). + +### 13. Start application + +```bash +sudo service gitlab start +sudo service nginx restart +``` + +### 14. Check application status + +Check if GitLab and its environment are configured correctly: + +```bash +cd /home/git/gitlab + +sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production +``` + +To make sure you didn't miss anything run a more thorough check: + +```bash +cd /home/git/gitlab + +sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production +``` + +If all items are green, then congratulations, the upgrade is complete! + +## Things went south? Revert to previous version (11.0) + +### 1. Revert the code to the previous version + +Follow the [upgrade guide from 10.8 to 11.0](10.8-to-11.0.md), except for the +database migration (the backup is already migrated to the previous version). + +### 2. Restore from the backup + +```bash +cd /home/git/gitlab + +sudo -u git -H bundle exec rake gitlab:backup:restore RAILS_ENV=production +``` + +If you have more than one backup `*.tar` file(s) please add `BACKUP=timestamp_of_backup` to the command above. + +[yaml]: https://gitlab.com/gitlab-org/gitlab-ce/blob/11-1-stable/config/gitlab.yml.example +[gl-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/11-1-stable/lib/support/init.d/gitlab.default.example diff --git a/doc/user/project/integrations/bamboo.md b/doc/user/project/integrations/bamboo.md index 1e28646bc97..cffe456cbc2 100644 --- a/doc/user/project/integrations/bamboo.md +++ b/doc/user/project/integrations/bamboo.md @@ -41,8 +41,7 @@ service in GitLab. 1. Click 'Atlassian Bamboo CI' 1. Select the 'Active' checkbox. 1. Enter the base URL of your Bamboo server. 'https://bamboo.example.com' -1. Enter the build key from your Bamboo build plan. Build keys are a short, - all capital letter, identifier that is unique. It will be something like PR-BLD +1. Enter the build key from your Bamboo build plan. Build keys are typically made up from the Project Key and Plan Key that are set on project/plan creation and seperated with a '-' for example **PROJ-PLAN**. This is a short, all capital letter, identifier that is unique. When viewing a plan within Bamboo, the build key is also shown in the browser URL for example https://bamboo.example.com/browse/PROJ-PLAN 1. If necessary, enter username and password for a Bamboo user that has access to trigger the build plan. Leave these fields blank if you do not require authentication. diff --git a/doc/user/project/settings/import_export.md b/doc/user/project/settings/import_export.md index 9034a9b5179..f94671fcf87 100644 --- a/doc/user/project/settings/import_export.md +++ b/doc/user/project/settings/import_export.md @@ -32,7 +32,8 @@ with all their related data and be moved into a new GitLab instance. | GitLab version | Import/Export version | | ---------------- | --------------------- | -| 10.8 to current | 0.2.3 | +| 11.1 to current | 0.2.4 | +| 10.8 | 0.2.3 | | 10.4 | 0.2.2 | | 10.3 | 0.2.1 | | 10.0 | 0.2.0 | diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md index 8a2f230f505..b1afe2cee42 100644 --- a/doc/workflow/lfs/lfs_administration.md +++ b/doc/workflow/lfs/lfs_administration.md @@ -90,6 +90,7 @@ Here is a configuration example with S3. | `provider` | The provider name | AWS | | `aws_access_key_id` | AWS credentials, or compatible | `ABC123DEF456` | | `aws_secret_access_key` | AWS credentials, or compatible | `ABC123DEF456ABC123DEF456ABC123DEF456` | +| `aws_signature_version` | AWS signature version to use. 2 or 4 are valid options. Digital Ocean Spaces and other providers may need 2. | 4 | | `region` | AWS region | us-east-1 | | `host` | S3 compatible host for when not using AWS, e.g. `localhost` or `storage.example.com` | s3.amazonaws.com | | `endpoint` | Can be used when configuring an S3 compatible service such as [Minio](https://www.minio.io), by entering a URL such as `http://127.0.0.1:9000` | (optional) | diff --git a/doc/workflow/notifications.md b/doc/workflow/notifications.md index edb0c6bdc30..5dc62a30128 100644 --- a/doc/workflow/notifications.md +++ b/doc/workflow/notifications.md @@ -111,7 +111,7 @@ by yourself (except when an issue is due). You will only receive automatic notifications when somebody else comments or adds changes to the ones that you've created or mentions you. -If a merge request becomes unmergeable, its author will be notified about the cause. +If an open merge request becomes unmergeable due to conflict, its author will be notified about the cause. If a user has also set the merge request to automatically merge once pipeline succeeds, then that user will also be notified. diff --git a/doc/workflow/todos.md b/doc/workflow/todos.md index 762bf616268..760cd87d4cc 100644 --- a/doc/workflow/todos.md +++ b/doc/workflow/todos.md @@ -31,7 +31,7 @@ A Todo appears in your Todos dashboard when: - you are `@mentioned` in a comment on a commit, - a job in the CI pipeline running for your merge request failed, but this job is not allowed to fail. -- a merge request becomes unmergeable, and you are either: +- an open merge request becomes unmergeable due to conflict, and you are either: - the author, or - have set it to automatically merge once pipeline succeeds. |