kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Merge branch 'docs-port-ee-community-contributions' into 'master'

Browse source 
Docs port ee community contributions

See merge request gitlab-org/gitlab-ce!21311
This commit is contained in:
Achilleas Pipinellis 2018-09-03 10:18:42 +00:00
commit 8cb39fa8da
25 changed files with 136 additions and 39 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/administration/gitaly/index.md
View file

@ -149,7 +149,7 @@ listen_addr = '0.0.0.0:8075'
[auth]
token = 'abc123secret'
[[storage]
[[storage]]
name = 'default'
path = '/mnt/gitlab/default/repositories'

2
doc/administration/high_availability/nfs.md
View file

@ -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

2
doc/administration/job_artifacts.md
View file

@ -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
```

5
doc/administration/pages/index.md
View file

@ -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

2
doc/api/groups.md
View file

@ -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.

2
doc/api/projects.md
View file

@ -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 |

22
doc/api/tags.md
View file

@ -174,8 +174,19 @@ 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",
@ -195,8 +206,19 @@ 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",

12
doc/ci/caching/index.md
View file

@ -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

22
doc/ci/yaml/README.md
View file

@ -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

4
doc/install/kubernetes/gitlab_omnibus.md
View file

@ -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

5
doc/raketasks/backup_restore.md
View file

@ -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

1
doc/security/README.md
View file

@ -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)

2
doc/security/reset_root_password.md
View file

@ -37,4 +37,4 @@ Don't forget to save the changes.
user.save!
```
Exit the console and try to login with your new password.
Exit the console and try to login with your new password.

31
doc/security/unlock_user.md Normal file
View file

@ -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.

2
doc/security/user_email_confirmation.md
View file

@ -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.

26
doc/ssh/README.md
View file

@ -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:**

6
doc/topics/autodevops/index.md
View file

@ -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 |

10
doc/topics/autodevops/quick_start_guide.md
View file

@ -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.
![Pipeline stages](img/guide_pipeline_stages.png)
@ -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**.
![Web IDE commit](img/guide_ide_commit.png)
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`.
![Merge request](img/guide_merge_request.png)
@ -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)

2
doc/update/README.md
View file

@ -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

2
doc/user/project/import/svn.md
View file

@ -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.

6
doc/user/project/issues/automatic_issue_closing.md
View file

@ -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`).
---

2
doc/user/project/repository/gpg_signed_commits/index.md
View file

@ -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.

2
doc/workflow/lfs/lfs_administration.md
View file

@ -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

1
doc/workflow/timezone.md
View file

@ -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

2
scripts/lint-doc.sh
View file

@ -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