diff options
| author | Achilleas Pipinellis <axil@gitlab.com> | 2018-09-03 10:18:42 +0000 |
|---|---|---|
| committer | Achilleas Pipinellis <axil@gitlab.com> | 2018-09-03 10:18:42 +0000 |
| commit | 8cb39fa8da9d2b7c54d2167c69abd045d6d1f347 (patch) | |
| tree | 688a5ad4b05e4091b09e207d5561486bedde7b5e | |
| parent | 0c8b219d2bc7c307411c0c368353faaa9cdbd09b (diff) | |
| parent | 726407e8c0681123bbbe624c37ba857b28d8951b (diff) | |
| download | gitlab-ce-8cb39fa8da9d2b7c54d2167c69abd045d6d1f347.tar.gz | |
Merge branch 'docs-port-ee-community-contributions' into 'master'
Docs port ee community contributions
See merge request gitlab-org/gitlab-ce!21311
25 files changed, 136 insertions, 39 deletions
diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 6d7e408d41b..36567173125 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -149,7 +149,7 @@ listen_addr = '0.0.0.0:8075' [auth] token = 'abc123secret' -[[storage] +[[storage]] name = 'default' path = '/mnt/gitlab/default/repositories' diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index cd2284f5f2a..95e2caf0cad 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -47,7 +47,7 @@ there because this will also affect performance. We recommend that the log files stored on a local volume. For more details on another person's experience with EFS, see -[Amazon's Elastic File System: Burst Credits](https://www.rawkode.io/2017/04/amazons-elastic-file-system-burst-credits/) +[Amazon's Elastic File System: Burst Credits](https://rawkode.com/2017/04/16/amazons-elastic-file-system-burst-credits/) ## NFS Client mount options diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md index 8c55c8c4298..4b5be8699e9 100644 --- a/doc/administration/job_artifacts.md +++ b/doc/administration/job_artifacts.md @@ -190,7 +190,7 @@ _The artifacts are stored by default in remote_directory: "artifacts" # The bucket name connection: provider: AWS # Only AWS supported at the moment - aws_access_key_id: AWS_ACESS_KEY_ID + aws_access_key_id: AWS_ACCESS_KEY_ID aws_secret_access_key: AWS_SECRET_ACCESS_KEY region: eu-central-1 ``` diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index eefa86f8e42..f16ba0b297d 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -11,6 +11,7 @@ description: 'Learn how to administer GitLab Pages.' - This guide is for Omnibus GitLab installations. If you have installed GitLab from source, follow the [Pages source installation document](source.md). - To learn how to use GitLab Pages, read the [user documentation][pages-userguide]. +- Does NOT support subgroups. See [this issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) for more information and status. This document describes how to set up the _latest_ GitLab Pages feature. Make sure to read the [changelog](#changelog) if you are upgrading to a new GitLab @@ -73,8 +74,8 @@ among other things. Follow [these instructions](https://publicsuffix.org/submit/) to submit your GitLab Pages subdomain. For instance, if your domain is `example.io`, you should -request that `*.example.io` is added to the Public Suffix List. GitLab.com -added `*.gitlab.io` [in 2016](https://gitlab.com/gitlab-com/infrastructure/issues/230). +request that `example.io` is added to the Public Suffix List. GitLab.com +added `gitlab.io` [in 2016](https://gitlab.com/gitlab-com/infrastructure/issues/230). ### DNS configuration diff --git a/doc/api/groups.md b/doc/api/groups.md index 64e0d78788d..be75c363a40 100644 --- a/doc/api/groups.md +++ b/doc/api/groups.md @@ -82,7 +82,7 @@ You can filter by [custom attributes](custom_attributes.md) with: GET /groups?custom_attributes[key]=value&custom_attributes[other_key]=other_value ``` -## List a groups's subgroups +## List a group's subgroups > [Introduced][ce-15142] in GitLab 10.3. diff --git a/doc/api/projects.md b/doc/api/projects.md index 0936ff52dae..86acb96357d 100644 --- a/doc/api/projects.md +++ b/doc/api/projects.md @@ -710,7 +710,7 @@ PUT /projects/:id | Attribute | Type | Required | Description | | --------- | ---- | -------- | ----------- | | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) | -| `name` | string | yes | The name of the project | +| `name` | string | no | The name of the project | | `path` | string | no | Custom repository name for the project. By default generated based on name | | `default_branch` | string | no | `master` by default | | `description` | string | no | Short project description | diff --git a/doc/api/tags.md b/doc/api/tags.md index 4af096c3c0c..f2a3f9f28d2 100644 --- a/doc/api/tags.md +++ b/doc/api/tags.md @@ -174,10 +174,21 @@ Parameters: - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user - `tag_name` (required) - The name of a tag + +Request body: + - `description` (required) - Release notes with markdown support ```json { + "description": "Amazing release. Wow" +} +``` + +Response: + +```json +{ "tag_name": "1.0.0", "description": "Amazing release. Wow" } @@ -195,10 +206,21 @@ Parameters: - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user - `tag_name` (required) - The name of a tag + +Request body: + - `description` (required) - Release notes with markdown support ```json { + "description": "Amazing release. Wow" +} +``` + +Response: + +```json +{ "tag_name": "1.0.0", "description": "Amazing release. Wow" } diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md index c159198d16b..881db84e916 100644 --- a/doc/ci/caching/index.md +++ b/doc/ci/caching/index.md @@ -87,7 +87,7 @@ you can use the same key for all of them: ```yaml cache: - key: one-key-to-rull-them-all + key: one-key-to-rule-them-all ``` To share the same cache between branches, but separate them by job: @@ -489,7 +489,15 @@ needed to compile the project: Artifacts were designed to upload some compiled/generated bits of the build, and they can be fetched by any number of concurrent Runners. They are guaranteed to be available and are there to pass data between jobs. They are - also exposed to be downloaded from the UI. + also exposed to be downloaded from the UI. **Artifacts can only exist in + directories relative to the build directory** and specifying paths which don't + comply to this rule trigger an unintuitive and unlogical error message (an + enhancement is discussed at + https://gitlab.com/gitlab-org/gitlab-ce/issues/15530). Artifacts need to be + uploaded to the GitLab instance (not only the GitLab runner) before the next + stage job(s) can start, so you need to evaluate carefully whether your + bandwidth allows you to profit from parallelization with stages and shared + artifacts before investing time in changes to the setup. It's sometimes confusing because the name artifact sounds like something that is only useful outside of the job, like for downloading a final image. But diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index abba748db8b..e93060fec85 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -390,6 +390,28 @@ job: The specification above, will make sure that `job` is built by a Runner that has both `ruby` AND `postgres` tags defined. +Tags are also a great way to run different jobs on different platforms, for +example, given an OS X Runner with tag `osx` and Windows Runner with tag +`windows`, the following jobs run on respective platforms: + +```yaml +windows job: + stage: + - build + tags: + - windows + script: + - echo Hello, %USERNAME%! + +osx job: + stage: + - build + tags: + - osx + script: + - echo "Hello, $USER!" +``` + ## `allow_failure` `allow_failure` is used when you want to allow a job to fail without impacting diff --git a/doc/install/kubernetes/gitlab_omnibus.md b/doc/install/kubernetes/gitlab_omnibus.md index d80cb6ad374..498b702cab1 100644 --- a/doc/install/kubernetes/gitlab_omnibus.md +++ b/doc/install/kubernetes/gitlab_omnibus.md @@ -101,7 +101,7 @@ Other common configuration options: - `provider`: Optimizes the deployment for a cloud provider. The default is `gke` for [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), with `acs` also supported for the [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/). For additional configuration options, consult the -[`values.yaml`](https://gitlab.com/charts/charts.gitlab.io/blob/master/charts/gitlab-omnibus/values.yaml). +[`values.yaml`](https://gitlab.com/charts/gitlab-omnibus/blob/master/values.yaml). ### Choosing a different GitLab release version @@ -228,7 +228,7 @@ helm upgrade gitlab --set gitlab=ee,gitlabEEImage=gitlab/gitlab-ee:9.5.5-ee.0 gi To uninstall the GitLab Chart, run the following: ```bash -helm delete gitlab +helm delete --purge gitlab ``` ## Troubleshooting diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index f1881e0f767..c2cf0d54aeb 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -124,7 +124,7 @@ To use the `copy` strategy instead of the default streaming strategy, specify ### Excluding specific directories from the backup -You can choose what should be backed up by adding the environment variable `SKIP`. +You can choose what should be exempt from the backup up by adding the environment variable `SKIP`. The available options are: - `db` (database) @@ -138,6 +138,9 @@ The available options are: Use a comma to specify several options at the same time: +All wikis will be backed up as part of the `repositories` group. Non-existent wikis +will be skipped during a backup. + ``` # use this command if you've installed GitLab with the Omnibus package sudo gitlab-rake gitlab:backup:create SKIP=db,uploads diff --git a/doc/security/README.md b/doc/security/README.md index d397ff104ab..e22dc00759d 100644 --- a/doc/security/README.md +++ b/doc/security/README.md @@ -10,6 +10,7 @@ comments: false - [Webhooks and insecure internal web services](webhooks.md) - [Information exclusivity](information_exclusivity.md) - [Reset your root password](reset_root_password.md) +- [Unlock a locked user](unlock_user.md) - [User File Uploads](user_file_uploads.md) - [How we manage the CRIME vulnerability](crime_vulnerability.md) - [Enforce Two-factor authentication](two_factor_authentication.md) diff --git a/doc/security/reset_root_password.md b/doc/security/reset_root_password.md index 3c13f262677..6a882ed6fe5 100644 --- a/doc/security/reset_root_password.md +++ b/doc/security/reset_root_password.md @@ -37,4 +37,4 @@ Don't forget to save the changes. user.save! ``` -Exit the console and try to login with your new password.
\ No newline at end of file +Exit the console and try to login with your new password. diff --git a/doc/security/unlock_user.md b/doc/security/unlock_user.md new file mode 100644 index 00000000000..d5ecef7f605 --- /dev/null +++ b/doc/security/unlock_user.md @@ -0,0 +1,31 @@ +# How to unlock a locked user + +Log into your server with root privileges. Then start a Ruby on Rails console. + +Start the console with this command: + +```bash +gitlab-rails console production +``` + +Wait until the console has loaded. + +There are multiple ways to find your user. You can search for email or username. + +```bash +user = User.where(id: 1).first +``` + +or + +```bash +user = User.find_by(email: 'admin@local.host') +``` + +Unlock the user: + +```bash +user.unlock_access! +``` + +Exit the console, the user should now be able to log in again. diff --git a/doc/security/user_email_confirmation.md b/doc/security/user_email_confirmation.md index 4293944ae8b..48c79cd4769 100644 --- a/doc/security/user_email_confirmation.md +++ b/doc/security/user_email_confirmation.md @@ -4,4 +4,4 @@ Gitlab admin can enable email confirmation on sign-up, if you want to confirm al user emails before they are able to sign-in. In the Admin area under **Settings** (`/admin/application_settings`), go to section -**Sign-in Restrictions** and look for **Send confirmation email on sign-up** option. +**Sign-up Restrictions** and look for **Send confirmation email on sign-up** option. diff --git a/doc/ssh/README.md b/doc/ssh/README.md index 63f0a654fcf..5db042326f3 100644 --- a/doc/ssh/README.md +++ b/doc/ssh/README.md @@ -48,9 +48,11 @@ Note that Public SSH key may also be named as follows: **Git Bash on Windows / GNU/Linux / macOS:** ```bash - ssh-keygen -t rsa -C "your.email@example.com" -b 4096 + ssh-keygen -o -t rsa -C "your.email@example.com" -b 4096 ``` + (Note: the `-o` option was introduced in 2014; if this command does not work for you, simply remove the `-o` option and try again) + **Windows:** Alternatively on Windows you can download @@ -75,7 +77,9 @@ Note that Public SSH key may also be named as follows: NOTE: **Note:** If you want to change the password of your SSH key pair, you can use - `ssh-keygen -p <keyname>`. + `ssh-keygen -p -o -f <keyname>`. + The `-o` option was added in 2014, so if this command does not work for you, + simply remove the `-o` option and try again. ## Adding a SSH key to your GitLab account @@ -191,15 +195,15 @@ project. ### Global shared deploy keys -Global Shared Deploy keys allow read-only or read-write (if enabled) access to +Global Shared Deploy keys allow read-only or read-write (if enabled) access to be configured on any repository in the entire GitLab installation. This is really useful for integrating repositories to secured, shared Continuous -Integration (CI) services or other shared services. -GitLab administrators can set up the Global Shared Deploy key in GitLab and +Integration (CI) services or other shared services. +GitLab administrators can set up the Global Shared Deploy key in GitLab and add the private key to any shared systems. Individual repositories opt into exposing their repository using these keys when a project maintainers (or higher) -authorizes a Global Shared Deploy key to be used with their project. +authorizes a Global Shared Deploy key to be used with their project. Global Shared Keys can provide greater security compared to Per-Project Deploy Keys since an administrator of the target integrated system is the only one @@ -211,13 +215,13 @@ the primary way for project maintainers and owners to identify the correct Globa Deploy key to add. For instance, if the key gives access to a SaaS CI instance, use the name of that service in the key name if that is all it is used for. When creating Global Shared Deploy keys, give some thought to the granularity -of keys - they could be of very narrow usage such as just a specific service or -of broader usage for something like "Anywhere you need to give read access to +of keys - they could be of very narrow usage such as just a specific service or +of broader usage for something like "Anywhere you need to give read access to your repository". -Once a GitLab administrator adds the Global Deployment key, project maintainers -and owners can add it in project's **Settings > Repository** section by expanding the -**Deploy Key** section and clicking **Enable** next to the appropriate key listed +Once a GitLab administrator adds the Global Deployment key, project maintainers +and owners can add it in project's **Settings > Repository** section by expanding the +**Deploy Key** section and clicking **Enable** next to the appropriate key listed under **Public deploy keys available to any project**. NOTE: **Note:** diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index 0474182e324..c0268ce136c 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -450,7 +450,7 @@ executed somewhere else, it cannot be accessed again. > [Introduced][ce-19507] in GitLab 11.0. -For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md###gitlab-deploy-token) +For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md###gitlab-deploy-token) will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token can be used for permanent access to the registry. @@ -574,13 +574,13 @@ postgres://user:password@postgres-host:postgres-port/postgres-database ### Environment variables The following variables can be used for setting up the Auto DevOps domain, -providing a custom Helm chart, or scaling your application. PostgreSQL can be +providing a custom Helm chart, or scaling your application. PostgreSQL can also be customized, and you can easily use a [custom buildpack](#custom-buildpacks). | **Variable** | **Description** | | ------------ | --------------- | | `AUTO_DEVOPS_DOMAIN` | The [Auto DevOps domain](#auto-devops-domain); by default set automatically by the [Auto DevOps setting](#enabling-auto-devops). | -| `AUTO_DEVOPS_CHART` | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/charts/charts.gitlab.io/tree/master/charts/auto-deploy-app). | +| `AUTO_DEVOPS_CHART` | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/charts/auto-deploy-app). | | `REPLICAS` | The number of replicas to deploy; defaults to 1. | | `PRODUCTION_REPLICAS` | The number of replicas to deploy in the production environment. This takes precedence over `REPLICAS`; defaults to 1. | | `CANARY_REPLICAS` | The number of canary replicas to deploy for [Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html); defaults to 1 | diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 44b0cf758dc..7ca441a2f74 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -143,7 +143,7 @@ In the next section we'll break down the pipeline and explain what each job does By now you should see the pipeline running, but what is it running exactly? -To navigate inside the pipeline, click its status badge. (It's status should be "running"). +To navigate inside the pipeline, click its status badge. (Its status should be "running"). The pipeline is split into 4 stages, each running a couple of jobs.  @@ -194,7 +194,7 @@ applications. In the rightmost column for the production environment, you can ma - The first icon will open the URL of the application that is deployed in production. It's a very simple page, but the important part is that it works! -- The next icon with the small graph will take you to the metrics page where +- The next icon, with the small graph, will take you to the metrics page where Prometheus collects data about the Kubernetes cluster and how the application affects it (in terms of memory/CPU usage, latency, etc.). @@ -217,7 +217,7 @@ under **Settings > CI/CD > Variables**. ### Working with branches -Following the [GitLab flow](../../workflow/gitlab_flow.md#working-with-feature-branches) +Following the [GitLab flow](../../workflow/gitlab_flow.md#working-with-feature-branches), let's create a feature branch that will add some content to the application. Under your repository, navigate to the following file: `app/views/welcome/index.html.erb`. @@ -235,7 +235,7 @@ by clicking **Commit**.  Once you submit the merge request, you'll see the pipeline running. This will -run all the jobs as [described previously](#deploying-the-application), as well +run all the jobs as [described previously](#deploying-the-application), as well as a few more that run only on branches other than `master`.  @@ -278,7 +278,7 @@ and the application will be eventually deployed straight to production. After implementing this project, you should now have a solid understanding of the basics of Auto DevOps. We started from building and testing to deploying and monitoring an application -all within GitLab. Despite its automatic nature, Audo DevOps can also be configured +all within GitLab. Despite its automatic nature, Auto DevOps can also be configured and customized to fit your workflow. Here are some helpful resources for further reading: 1. [Auto DevOps](index.md) diff --git a/doc/update/README.md b/doc/update/README.md index c98e20686e0..2c1fbc15719 100644 --- a/doc/update/README.md +++ b/doc/update/README.md @@ -142,4 +142,4 @@ possible. [ee-ce]: ../downgrade_ee_to_ce/README.md [ce]: https://about.gitlab.com/features/#community [ee]: https://about.gitlab.com/features/#enterprise -[omni-ce-ee]: http://docs.gitlab.com/omnibus/update/README.html#from-community-edition-to-enterprise-edition +[omni-ce-ee]: https://docs.gitlab.com/omnibus/update/README.html#updating-community-edition-to-enterprise-edition diff --git a/doc/user/project/import/svn.md b/doc/user/project/import/svn.md index 7a3628a39d7..16bc5121027 100644 --- a/doc/user/project/import/svn.md +++ b/doc/user/project/import/svn.md @@ -8,7 +8,7 @@ between the two, for more information consult your favorite search engine. There are two approaches to SVN to Git migration: -1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which: +1. [Git/SVN Mirror](#smooth-migration-with-a-git-svn-mirror-using-subgit) which: - Makes the GitLab repository to mirror the SVN project. - Git and SVN repositories are kept in sync; you can use either one. - Smoothens the migration process and allows to manage migration risks. diff --git a/doc/user/project/issues/automatic_issue_closing.md b/doc/user/project/issues/automatic_issue_closing.md index b9607243c8a..b6570c777ae 100644 --- a/doc/user/project/issues/automatic_issue_closing.md +++ b/doc/user/project/issues/automatic_issue_closing.md @@ -26,8 +26,10 @@ used: ``` Note that `%{issue_ref}` is a complex regular expression defined inside GitLab's -source code that can match a reference to 1) a local issue (`#123`), -2) a cross-project issue (`group/project#123`) or 3) a link to an issue +source code that can match references to: +1. a local issue (`#123`), +2. a cross-project issue (`group/project#123`) +3. a link to an issue (`https://gitlab.example.com/group/project/issues/123`). --- diff --git a/doc/user/project/repository/gpg_signed_commits/index.md b/doc/user/project/repository/gpg_signed_commits/index.md index d41be0989d2..a17f911874b 100644 --- a/doc/user/project/repository/gpg_signed_commits/index.md +++ b/doc/user/project/repository/gpg_signed_commits/index.md @@ -55,6 +55,8 @@ started: ```sh gpg --full-gen-key ``` + +_NOTE: In some cases like Gpg4win on Windows and other Mac OS versions the command here may be ` gpg --gen-key`_ This will spawn a series of questions. diff --git a/doc/workflow/lfs/lfs_administration.md b/doc/workflow/lfs/lfs_administration.md index 6ac3bb8c0b4..3f9ffedd61a 100644 --- a/doc/workflow/lfs/lfs_administration.md +++ b/doc/workflow/lfs/lfs_administration.md @@ -24,7 +24,7 @@ There are various configuration options to help GitLab server administrators: In `/etc/gitlab/gitlab.rb`: ```ruby -# Change to true to enable lfs +# Change to true to enable lfs - enabled by default if not defined gitlab_rails['lfs_enabled'] = false # Optionally, change the storage path location. Defaults to diff --git a/doc/workflow/timezone.md b/doc/workflow/timezone.md index 7e08c0e51ac..338b3a32265 100644 --- a/doc/workflow/timezone.md +++ b/doc/workflow/timezone.md @@ -9,6 +9,7 @@ Uncomment and customize if you want to change the default time zone of GitLab ap To see all available time zones, run `bundle exec rake time:zones:all`. +With Omnibus installations, run `gitlab-rake time:zones:all`. ## Changing time zone in omnibus installations diff --git a/scripts/lint-doc.sh b/scripts/lint-doc.sh index 178b209aacf..848364b4a9b 100755 --- a/scripts/lint-doc.sh +++ b/scripts/lint-doc.sh @@ -5,7 +5,7 @@ cd "$(dirname "$0")/.." # Use long options (e.g. --header instead of -H) for curl examples in documentation. echo '=> Checking for cURL short options...' grep --extended-regexp --recursive --color=auto 'curl (.+ )?-[^- ].*' doc/ >/dev/null 2>&1 -if [ $? == 0 ] +if [ $? -eq 0 ] then echo '✖ ERROR: Short options for curl should not be used in documentation! Use long options (e.g., --header instead of -H):' >&2 |