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

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-04-26 00:09:41 +00:00
parent 8b12578ec6
commit d29c19034b
20 changed files with 171 additions and 172 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
doc/administration/auth/ldap/ldap-troubleshooting.md
View File

@ -27,7 +27,7 @@ Could not authenticate you from Ldapmain because "Connection timed out - user sp
```
If your configured LDAP provider and/or endpoint is offline or otherwise
unreachable by GitLab, no LDAP user will be able to authenticate and sign-in.
unreachable by GitLab, no LDAP user is able to authenticate and sign-in.
GitLab does not cache or store credentials for LDAP users to provide authentication
during an LDAP outage.
@ -181,14 +181,13 @@ user = User.find_by_any_email('email@example.com')
user.username
```
This will show you which user has this email address. One of two steps will
have to be taken here:
This shows you which user has this email address. One of two steps must be taken here:
- To create a new GitLab user/username for this user when signing in with LDAP,
remove the secondary email to remove the conflict.
- To use an existing GitLab user/username for this user to use with LDAP,
remove this email as a secondary email and make it a primary one so GitLab
will associate this profile to the LDAP identity.
associates this profile to the LDAP identity.
The user can do either of these steps [in their
profile](../../../user/profile/index.md#access-your-user-profile) or an administrator can do it.
@ -227,7 +226,7 @@ output](#example-console-output-after-a-user-sync).
##### Example console output after a user sync **(PREMIUM SELF)**
The output from a [manual user sync](#sync-all-users) will be very verbose, and a
The output from a [manual user sync](#sync-all-users) is very verbose, and a
single user's successful sync can look like this:
```shell
@ -255,8 +254,8 @@ uid: John
There's a lot here, so let's go over what could be helpful when debugging.
First, GitLab will look for all users that have previously
signed in with LDAP and iterate on them. Each user's sync will start with
First, GitLab looks for all users that have previously
signed in with LDAP and iterate on them. Each user's sync starts with
the following line that contains the user's username and email, as they
exist in GitLab now:
@ -274,7 +273,7 @@ link between this user and the configured LDAP provider(s):
Identity Load (0.9ms) SELECT "identities".* FROM "identities" WHERE "identities"."user_id" = 20 AND (provider LIKE 'ldap%') LIMIT 1
```
The identity object will have the DN that GitLab will use to look for the user
The identity object has the DN that GitLab uses to look for the user
in LDAP. If the DN isn't found, the email is used instead. We can see that
this user is found in LDAP:
@ -294,18 +293,18 @@ following message instead:
LDAP search error: No Such Object
```
...in which case the user will be blocked:
...in which case the user is blocked:
```shell
User Update (0.4ms) UPDATE "users" SET "state" = $1, "updated_at" = $2 WHERE "users"."id" = $3 [["state", "ldap_blocked"], ["updated_at", "2019-10-18 15:46:22.902177"], ["id", 20]]
```
Once the user is found in LDAP the rest of the output will update the GitLab
Once the user is found in LDAP, the rest of the output updates the GitLab
database with any changes.
#### Query a user in LDAP
This will test that GitLab can reach out to LDAP and read a particular user.
This tests that GitLab can reach out to LDAP and read a particular user.
It can expose potential errors connecting to and/or querying LDAP
that may seem to fail silently in the GitLab UI.

18
doc/administration/auth/oidc.md
View File

@ -10,7 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
GitLab can use [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html) as an OmniAuth provider.
To enable the OpenID Connect OmniAuth provider, you must register your application with an OpenID Connect provider.
The OpenID Connect will provide you with a client details and secret for you to use.
The OpenID Connect provides you with a client's details and secret for you to use.
1. On your GitLab server, open the configuration file.
@ -86,21 +86,21 @@ The OpenID Connect will provide you with a client details and secret for you to
and the [OpenID Connect Core 1.0 specification](https://openid.net/specs/openid-connect-core-1_0.html).
1. For the configuration above, change the values for the provider to match your OpenID Connect client setup. Use the following as a guide:
- `<your_oidc_label>` is the label that will be displayed on the login page.
- `<custom_provider_icon>` (optional) is the icon that will be displayed on the login page. Icons for the major social login platforms are built-in into GitLab,
- `<your_oidc_label>` is the label that appears on the login page.
- `<custom_provider_icon>` (optional) is the icon that appears on the login page. Icons for the major social login platforms are built-in into GitLab,
but can be overridden by specifying this parameter. Both local paths and absolute URLs are accepted.
- `<your_oidc_url>` (optional) is the URL that points to the OpenID Connect provider. For example, `https://example.com/auth/realms/your-realm`.
If this value is not provided, the URL is constructed from the `client_options` in the following format: `<client_options.scheme>://<client_options.host>:<client_options.port>`.
- If `discovery` is set to `true`, the OpenID Connect provider will try to auto discover the client options using `<your_oidc_url>/.well-known/openid-configuration`. Defaults to `false`.
- If `discovery` is set to `true`, the OpenID Connect provider attempts to auto discover the client options using `<your_oidc_url>/.well-known/openid-configuration`. Defaults to `false`.
- `client_auth_method` (optional) specifies the method used for authenticating the client with the OpenID Connect provider.
- Supported values are:
- `basic` - HTTP Basic Authentication
- `jwt_bearer` - JWT based authentication (private key and client secret signing)
- `mtls` - Mutual TLS or X.509 certificate validation
- Any other value will POST the client ID and secret in the request body
- Any other value POSTs the client ID and secret in the request body
- If not specified, defaults to `basic`.
- `<uid_field>` (optional) is the field name from the `user_info.raw_attributes` details that will be used as `uid` value. For example, `preferred_username`.
If this value is not provided or the field with the configured value is missing from the `user_info.raw_attributes` details, the `uid` will use the `sub` field.
- `<uid_field>` (optional) is the field name from the `user_info.raw_attributes` that defines the value for `uid`. For example, `preferred_username`.
If this value is not provided or the field with the configured value is missing from the `user_info.raw_attributes` details, the `uid` uses the `sub` field.
- `send_scope_to_token_endpoint` is `true` by default. In other words, the `scope` parameter is normally included in requests to the token endpoint.
However, if your OpenID Connect provider does not accept the `scope` parameter in such requests, set this to `false`.
- `client_options` are the OpenID Connect client-specific options. Specifically:
@ -119,9 +119,9 @@ The OpenID Connect will provide you with a client details and secret for you to
for the changes to take effect if you installed GitLab via Omnibus or from source respectively.
On the sign in page, there should now be an OpenID Connect icon below the regular sign in form.
Click the icon to begin the authentication process. The OpenID Connect provider will ask the user to
Click the icon to begin the authentication process. The OpenID Connect provider asks the user to
sign in and authorize the GitLab application (if confirmation required by the client). If everything goes well, the user
will be redirected to GitLab and will be signed in.
is redirected to GitLab and signed in.
## Example configurations

10
doc/administration/geo/replication/docker_registry.md
View File

@ -24,7 +24,7 @@ integrated [Container Registry](../../packages/container_registry.md#use-object-
You can enable a storage-agnostic replication so it
can be used for cloud or local storage. Whenever a new image is pushed to the
**primary** site, each **secondary** site will pull it to its own container
**primary** site, each **secondary** site pulls it to its own container
repository.
To configure Docker Registry replication:
@ -70,12 +70,12 @@ We need to make Docker Registry send notification events to the
NOTE:
If you use an external Registry (not the one integrated with GitLab), you must add
these settings to its configuration yourself. In this case, you will also have to specify
these settings to its configuration yourself. In this case, you also have to specify
notification secret in `registry.notification_secret` section of
`/etc/gitlab/gitlab.rb` file.
NOTE:
If you use GitLab HA, you will also have to specify
If you use GitLab HA, you also have to specify
the notification secret in `registry.notification_secret` section of
`/etc/gitlab/gitlab.rb` file for every web node.
@ -95,7 +95,7 @@ expecting to see the Docker images replicated.
Because we need to allow the **secondary** site to communicate securely with
the **primary** site Container Registry, we need to have a single key
pair for all the sites. The **secondary** site will use this key to
pair for all the sites. The **secondary** site uses this key to
generate a short-lived JWT that is pull-only-capable to access the
**primary** site Container Registry.
@ -126,5 +126,5 @@ For each application and Sidekiq node on the **secondary** site:
To verify Container Registry replication is working, go to **Admin Area > Geo**
(`/admin/geo/nodes`) on the **secondary** site.
The initial replication, or "backfill", will probably still be in progress.
The initial replication, or "backfill", is probably still in progress.
You can monitor the synchronization process on each Geo site from the **primary** site's **Geo Nodes** dashboard in your browser.

8
doc/administration/housekeeping.md
View File

@ -25,8 +25,8 @@ For example in the following scenario a `git repack -d` will be executed:
- Git GC period = `200`
- Full repack period = `50`
When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will run, similarly when
the `pushes_since_gc` value is 200 a `git gc` will be run.
When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` runs, similarly when
the `pushes_since_gc` value is 200 a `git gc` runs.
- `git gc` ([man page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-gc.html)) runs a number of housekeeping tasks,
such as compressing file revisions (to reduce disk space and increase performance)
@ -34,7 +34,7 @@ the `pushes_since_gc` value is 200 a `git gc` will be run.
`git add`.
- `git repack` ([man page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-repack.html)) re-organize existing packs into a single, more efficient pack.
Housekeeping will also [remove unreferenced LFS files](../raketasks/cleanup.md#remove-unreferenced-lfs-files)
Housekeeping also [removes unreferenced LFS files](../raketasks/cleanup.md#remove-unreferenced-lfs-files)
from your project on the same schedule as the `git gc` operation, freeing up storage space for your project.
You can find this option under your project's **Settings > General > Advanced**.
@ -56,4 +56,4 @@ This is the current call stack by which it is invoked:
1. `Gitaly::FetchIntoObjectPoolRequest`
To manually invoke it from a Rails console, if needed, you can call `project.pool_repository.object_pool.fetch`.
This is a potentially long-running task, though Gitaly will timeout in about 8 hours.
This is a potentially long-running task, though Gitaly times out in about 8 hours.

16
doc/administration/operations/fast_ssh_key_lookup.md
View File

@ -16,7 +16,7 @@ Regular SSH operations become slow as the number of users grows because OpenSSH
searches for a key to authorize a user via a linear search. In the worst case,
such as when the user is not authorized to access GitLab, OpenSSH will scan the
entire file to search for a key. This can take significant time and disk I/O,
which will delay users attempting to push or pull to a repository. Making
which delays users attempting to push or pull to a repository. Making
matters worse, if users add or remove keys frequently, the operating system may
not be able to cache the `authorized_keys` file, which causes the disk to be
accessed repeatedly.
@ -28,7 +28,7 @@ lookup of authorized SSH keys.
WARNING:
OpenSSH version 6.9+ is required because
`AuthorizedKeysCommand` must be able to accept a fingerprint. These
instructions will break installations using older versions of OpenSSH, such as
instructions break installations that use older versions of OpenSSH, such as
those included with CentOS 6 as of September 2017. If you want to use this
feature for CentOS 6, follow [the instructions on how to build and install a custom OpenSSH package](#compiling-a-custom-version-of-openssh-for-centos-6) before continuing.
@ -40,9 +40,9 @@ single source of truth, [Geo](../geo/index.md) needs to be configured to perform
lookups via database lookup.
As part of [setting up Geo](../geo/index.md#setup-instructions),
you will be required to follow the steps outlined below for both the primary and
you are required to follow the steps outlined below for both the primary and
secondary nodes, but note that the `Write to "authorized keys" file` checkbox
only needs to be unchecked on the primary node since it will be reflected
only needs to be unchecked on the primary node since it is reflected
automatically on the secondary if database replication is working.
## Setting up fast lookup via GitLab Shell
@ -91,10 +91,10 @@ as required, but that might require temporary ownership changes during `gitlab-s
WARNING:
Do not disable writes until SSH is confirmed to be working
perfectly, because the file will quickly become out-of-date.
perfectly; otherwise, the file quickly becomes out-of-date.
In the case of lookup failures (which are common), the `authorized_keys`
file will still be scanned. So Git SSH performance will still be slow for many
file is still scanned. So Git SSH performance would still be slow for many
users as long as a large file exists.
You can disable any more writes to the `authorized_keys` file by unchecking
@ -183,8 +183,8 @@ the database. The following instructions can be used to build OpenSSH 7.5:
-rw-r--r--. 1 root root 367516 Jun 20 19:37 openssh-server-7.5p1-1.x86_64.rpm
```
1. Install the packages. OpenSSH packages will replace `/etc/pam.d/sshd`
with its own version, which may prevent users from logging in, so be sure
1. Install the packages. OpenSSH packages replace `/etc/pam.d/sshd`
with their own versions, which may prevent users from logging in, so be sure
that the file is backed up and restored after installation:
```shell

12
doc/administration/operations/filesystem_benchmarking.md
View File

@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
File system performance has a big impact on overall GitLab performance,
especially for actions that read or write to Git repositories. This information
will help benchmark file system performance against known good and bad real-world
helps benchmark file system performance against known good and bad real-world
systems.
Normally when talking about file system performance the biggest concern is
@ -35,12 +35,12 @@ Then run the following:
fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --bs=4k --iodepth=64 --readwrite=randrw --rwmixread=75 --size=4G --filename=/path/to/git-data/testfile
```
This will create a 4GB file in `/path/to/git-data/testfile`. It performs
This creates a 4GB file in `/path/to/git-data/testfile`. It performs
4KB reads and writes using a 75%/25% split within the file, with 64
operations running at a time. Be sure to delete the file after the test
completes.
The output will vary depending on what version of `fio` installed. The following
The output varies depending on what version of `fio` installed. The following
is an example output from `fio` v2.2.10 on a networked solid-state drive (SSD):
```plaintext
@ -78,8 +78,8 @@ test but still have poor performance due to read speed and various other
factors.
The following one-line commands provide a quick benchmark for file system write and read
performance. This will write 1,000 small files to the directory in which it is
executed, and then read the same 1,000 files.
performance. This writes 1,000 small files to the directory in which it is
executed, and then reads the same 1,000 files.
1. Change into the root of the appropriate
[repository storage path](../repository_storage_paths.md).
@ -107,7 +107,7 @@ executed, and then read the same 1,000 files.
cd ../; rm -rf test
```
The output of the `time for ...` commands will look similar to the following. The
The output of the `time for ...` commands resemble the following. The
important metric is the `real` time.
```shell

26
doc/administration/operations/ssh_certificates.md
View File

@ -110,10 +110,10 @@ Where `{KEY_ID}` is the `%i` argument passed to the script
(e.g. `aeanfjord`), and `{PRINCIPAL}` is the principal passed to it
(e.g. `sshUsers`).
You will need to customize the `sshUsers` part of that. It should be
You need to customize the `sshUsers` part of that. It should be
some principal that's guaranteed to be part of the key for all users
who can log in to GitLab, or you must provide a list of principals,
one of which is going to be present for the user, e.g.:
one of which is present for the user, e.g.:
```plaintext
[...]
@ -122,7 +122,7 @@ one of which is going to be present for the user, e.g.:
## Principals and security
You can supply as many principals as you want, these will be turned
You can supply as many principals as you want, these are turned
into multiple lines of `authorized_keys` output, as described in the
`AuthorizedPrincipalsFile` documentation in `sshd_config(5)`.
@ -130,32 +130,32 @@ Normally when using the `AuthorizedKeysCommand` with OpenSSH the
principal is some "group" that's allowed to log into that
server. However with GitLab it's only used to appease OpenSSH's
requirement for it, we effectively only care about the "key ID" being
correct. Once that's extracted GitLab will enforce its own ACLs for
correct. Once that's extracted GitLab enforces its own ACLs for
that user (e.g. what projects the user can access).
So it's OK to e.g. be overly generous in what you accept, since if the
user e.g. has no access to GitLab at all it'll just error out with a
user e.g. has no access to GitLab at all it just errors out with a
message about this being an invalid user.
## Interaction with the `authorized_keys` file
SSH certificates can be used in conjunction with the `authorized_keys`
file, and if set up as configured above the `authorized_keys` file will
still serve as a fallback.
file, and if set up as configured above the `authorized_keys` file
still serves as a fallback.
This is because if the `AuthorizedPrincipalsCommand` can't
authenticate the user, OpenSSH will fall back on
authenticate the user, OpenSSH falls back on
`~/.ssh/authorized_keys` (or the `AuthorizedKeysCommand`).
Therefore there may still be a reason to use the ["Fast lookup of
authorized SSH keys in the database"](fast_ssh_key_lookup.html) method
in conjunction with this. Since you'll be using SSH certificates for
in conjunction with this. Since you are using SSH certificates for
all your normal users, and relying on the `~/.ssh/authorized_keys`
fallback for deploy keys, if you make use of those.
But you may find that there's no reason to do that, since all your
normal users will use the fast `AuthorizedPrincipalsCommand` path, and
only automated deployment key access will fall back on
normal users use the fast `AuthorizedPrincipalsCommand` path, and
only automated deployment key access falls back on
`~/.ssh/authorized_keys`, or that you have a lot more keys for normal
users (especially if they're renewed) than you have deploy keys.
@ -167,14 +167,14 @@ uploading an SSH public key to their profile, relying on the
currently no feature to prevent this, [but there's an open request for
adding it](https://gitlab.com/gitlab-org/gitlab/-/issues/23260).
Such a restriction can currently be hacked in by e.g. providing a
Such a restriction can currently be hacked in by, for example, providing a
custom `AuthorizedKeysCommand` which checks if the discovered key-ID
returned from `gitlab-shell-authorized-keys-check` is a deploy key or
not (all non-deploy keys should be refused).
## Disabling the global warning about users lacking SSH keys
By default GitLab will show a "You won't be able to pull or push
By default GitLab shows a "You won't be able to pull or push
project code via SSH" warning to users who have not uploaded an SSH
key to their profile.

8
doc/administration/polling.md
View File

@ -18,14 +18,14 @@ seconds; these are _not_ the actual values.
- 1 is the default, and recommended for most installations. (Issue notes poll
every 2 seconds, and issue titles poll every 5 seconds.)
- 0 will disable UI polling completely. (On the next poll, clients will stop
- 0 disables UI polling completely. (On the next poll, clients stop
polling for updates.)
- A value greater than 1 will slow polling down. If you see issues with
- A value greater than 1 slows polling down. If you see issues with
database load from lots of clients polling for updates, increasing the
multiplier from 1 can be a good compromise, rather than disabling polling
completely. (For example: If this is set to 2, then issue notes poll every 4
seconds, and issue titles poll every 10 seconds.)
- A value between 0 and 1 will make the UI poll more frequently (so updates
will show in other sessions faster), but is **not recommended**. 1 should be
- A value between 0 and 1 makes the UI poll more frequently (so updates
show in other sessions faster), but is **not recommended**. 1 should be
fast enough. (For example, if this is set to 0.5, then issue notes poll every
1 second, and issue titles poll every 2.5 seconds.)

6
doc/administration/postgresql/pgbouncer.md
View File

@ -23,7 +23,7 @@ This content has been moved to a [new location](replication_and_failover.md#conf
1. Generate PGBOUNCER_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 pgbouncer`
1. Generate SQL_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 gitlab`. We'll also need to enter the plaintext SQL_USER_PASSWORD later
1. Generate SQL_USER_PASSWORD_HASH with the command `gitlab-ctl pg-password-md5 gitlab`. Enter the plaintext SQL_USER_PASSWORD later.
1. On your database node, ensure the following is set in your `/etc/gitlab/gitlab.rb`
@ -37,7 +37,7 @@ This content has been moved to a [new location](replication_and_failover.md#conf
1. Run `gitlab-ctl reconfigure`
NOTE:
If the database was already running, it will need to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
If the database was already running, it needs to be restarted after reconfigure by running `gitlab-ctl restart postgresql`.
1. On the node you are running PgBouncer on, make sure the following is set in `/etc/gitlab/gitlab.rb`
@ -68,7 +68,7 @@ This content has been moved to a [new location](replication_and_failover.md#conf
## Backups
Do not backup or restore GitLab through a PgBouncer connection: this will cause a GitLab outage.
Do not backup or restore GitLab through a PgBouncer connection: it causes a GitLab outage.
[Read more about this and how to reconfigure backups](../../raketasks/backup_restore.md#backup-and-restore-for-installations-using-pgbouncer).

22
doc/administration/raketasks/ldap.md
View File

@ -10,8 +10,8 @@ The following are LDAP-related Rake tasks.
## Check
The LDAP check Rake task will test the `bind_dn` and `password` credentials
(if configured) and will list a sample of LDAP users. This task is also
The LDAP check Rake task tests the `bind_dn` and `password` credentials
(if configured) and lists a sample of LDAP users. This task is also
executed as part of the `gitlab:check` task, but can run independently
using the command below.
@ -27,7 +27,7 @@ sudo gitlab-rake gitlab:ldap:check
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
```
By default, the task will return a sample of 100 LDAP users. Change this
By default, the task returns a sample of 100 LDAP users. Change this
limit by passing a number to the check task:
```shell
@ -38,7 +38,7 @@ rake gitlab:ldap:check[50]
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/14735) in [GitLab Starter](https://about.gitlab.com/pricing/) 12.2.
The following task will run a [group sync](../auth/ldap/index.md#group-sync) immediately. This is valuable
The following task runs a [group sync](../auth/ldap/index.md#group-sync) immediately. This is valuable
when you'd like to update all configured group memberships against LDAP without
waiting for the next scheduled group sync to be run.
@ -61,9 +61,9 @@ bundle exec rake gitlab:ldap:group_sync
## Rename a provider
If you change the LDAP server ID in `gitlab.yml` or `gitlab.rb` you will need
to update all user identities or users will be unable to sign in. Input the
old and new provider and this task will update all matching identities in the
If you change the LDAP server ID in `gitlab.yml` or `gitlab.rb` you need
to update all user identities or users aren't able to sign in. Input the
old and new provider and this task updates all matching identities in the
database.
`old_provider` and `new_provider` are derived from the prefix `ldap` plus the
@ -81,8 +81,8 @@ main:
`main` is the LDAP server ID. Together, the unique provider is `ldapmain`.
> **Warning**: If you input an incorrect new provider users will be unable
to sign in. If this happens, run the task again with the incorrect provider
> **Warning**: If you input an incorrect new provider, users cannot sign in.
If this happens, run the task again with the incorrect provider
as the `old_provider` and the correct provider as the `new_provider`.
**Omnibus Installation**
@ -119,7 +119,7 @@ User identities were successfully updated
### Other options
If you do not specify an `old_provider` and `new_provider` you will be prompted
If you do not specify an `old_provider` and `new_provider` the task prompts you
for them:
**Omnibus Installation**
@ -141,7 +141,7 @@ What is the old provider? Ex. 'ldapmain': ldapmain
What is the new provider? Ex. 'ldapcustom': ldapmycompany
```
This tasks also accepts the `force` environment variable which will skip the
This task also accepts the `force` environment variable, which skips the
confirmation dialog:
```shell

26
doc/ci/unit_test_reports.md
View File

@ -11,12 +11,12 @@ type: reference
> - [Renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/39737) from JUnit test reports to Unit test reports in GitLab 13.4.
It is very common that a [CI/CD pipeline](pipelines/index.md) contains a
test job that will verify your code.
test job that verifies your code.
If the tests fail, the pipeline fails and users get notified. The person that
works on the merge request will have to check the job logs and see where the
works on the merge request has to check the job logs and see where the
tests failed so that they can fix them.
You can configure your job to use Unit test reports, and GitLab will display a
You can configure your job to use Unit test reports, and GitLab displays a
report on the merge request so that it's easier and faster to identify the
failure without having to check the entire log. Unit test reports currently
only support test reports in the JUnit report format.
@ -49,7 +49,7 @@ comparing the head and base branch's JUnit report format XML files, where:
The reports panel has a summary showing how many tests failed, how many had errors
and how many were fixed. If no comparison can be done because data for the base branch
is not available, the panel will just show the list of failed tests for head.
is not available, the panel just shows the list of failed tests for head.
There are four types of results:
@ -59,8 +59,8 @@ There are four types of results:
1. **Existing failures:** Test cases which failed on base branch and failed on head branch
1. **Resolved failures:** Test cases which failed on base branch and passed on head branch
Each entry in the panel will show the test name and its type from the list
above. Clicking on the test name will open a modal window with details of its
Each entry in the panel shows the test name and its type from the list
above. Clicking on the test name opens a modal window with details of its
execution time and the error output.
![Test Reports Widget](img/junit_test_report.png)
@ -115,7 +115,7 @@ ruby:
### Go example
Use the following job in `.gitlab-ci.yml`, and ensure you use `-set-exit-code`,
otherwise the pipeline will be marked successful, even if the tests fail:
otherwise the pipeline is marked successful, even if the tests fail:
```yaml
## Use https://github.com/jstemmer/go-junit-report to generate a JUnit report format XML file with go
@ -137,7 +137,7 @@ There are a few tools that can produce JUnit report format XML file in Java.
#### Gradle
In the following example, `gradle` is used to generate the test reports.
If there are multiple test tasks defined, `gradle` will generate multiple
If there are multiple test tasks defined, `gradle` generates multiple
directories under `build/test-results/`. In that case, you can leverage glob
matching by defining the following path: `build/test-results/test/**/TEST-*.xml`:
@ -198,8 +198,8 @@ There are a few tools that can produce JUnit report format XML files in C/C++.
In the following example, `gtest` is used to generate the test reports.
If there are multiple `gtest` executables created for different architectures (`x86`, `x64` or `arm`),
you will be required to run each test providing a unique filename. The results
will then be aggregated together.
you are required to run each test providing a unique filename. The results
are then be aggregated together.
```yaml
cpp:
@ -313,8 +313,8 @@ test:
> - The feature flag was removed and the feature was [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/216478) in GitLab 13.3.
If JUnit report format XML files are generated and uploaded as part of a pipeline, these reports
can be viewed inside the pipelines details page. The **Tests** tab on this page will
display a list of test suites and cases reported from the XML file.
can be viewed inside the pipelines details page. The **Tests** tab on this page
displays a list of test suites and cases reported from the XML file.
![Test Reports Widget](img/pipelines_junit_test_report_v13_10.png)
@ -340,7 +340,7 @@ If parsing JUnit report XML results in an error, an indicator is shown next to t
WARNING:
This feature might not be available to you. Check the **version history** note above for details.
When [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/6061) is complete, the attached file will be visible on the pipeline details page.
When [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/6061) is complete, the attached file is visible on the pipeline details page.
If JUnit report format XML files contain an `attachment` tag, GitLab parses the attachment.

18
doc/integration/elasticsearch.md
View File

@ -31,7 +31,7 @@ and the advantage of the [special searches](../user/search/advanced_search.md).
Elasticsearch requires additional resources in excess of those documented in the
[GitLab system requirements](../install/requirements.md).
The amount of resources (memory, CPU, storage) will vary greatly, based on the
The amount of resources (memory, CPU, storage) varies greatly, based on the
amount of data being indexed into the Elasticsearch cluster. According to
[Elasticsearch official guidelines](https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html#_memory),
each node should have:
@ -44,8 +44,8 @@ A few notes on CPU and storage:
- CPU requirements for Elasticsearch tend to be minimal. There are specific
scenarios where this isn't true, but GitLab.com isn't using Elasticsearch in
an exceptionally CPU-heavy way. More cores will be more performant than faster
CPUs. Extra concurrency from multiple cores will far outweigh a slightly
an exceptionally CPU-heavy way. More cores are more performant than faster
CPUs. Extra concurrency from multiple cores far outweighs a slightly
faster clock speed in Elasticsearch.
- Storage requirements for Elasticsearch are important, especially for
@ -60,7 +60,7 @@ A few notes on CPU and storage:
for the calculation. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/221177) in GitLab 13.10.
Keep in mind, these are **minimum requirements** for Elasticsearch.
Heavily-used Elasticsearch clusters will likely require considerably more
Heavily-used Elasticsearch clusters likely require considerably more
resources.
## Installing Elasticsearch
@ -77,26 +77,26 @@ service. Running Elasticsearch on the same server as GitLab is not recommended
and can cause a degradation in GitLab instance performance.
**For a single node Elasticsearch cluster the functional cluster health status
will be yellow** (will never be green) because the primary shard is allocated but
is yellow** (will never be green) because the primary shard is allocated but
replicas can not be as there is no other node to which Elasticsearch can assign a
replica.
After the data is added to the database or repository and [Elasticsearch is
enabled in the Admin Area](#enabling-advanced-search) the search index will be
enabled in the Admin Area](#enabling-advanced-search) the search index is
updated automatically.
## Upgrading to a new Elasticsearch major version
Since Elasticsearch can read and use indices created in the previous major version, you don't need to change anything in the GitLab configuration when upgrading Elasticsearch.
The only thing worth noting is that if you have created your current index before GitLab 13.0, you might want to reindex from scratch (which will implicitly create an alias) in order to use some features, for example [Zero downtime reindexing](#zero-downtime-reindexing). Once you do that, you'll be able to perform zero-downtime reindexing and will benefit from any future features that make use of the alias.
The only thing worth noting is that if you have created your current index before GitLab 13.0, you might want to reindex from scratch (which implicitly creates an alias) in order to use some features, for example [Zero downtime reindexing](#zero-downtime-reindexing). Once you do that, you are able to perform zero-downtime reindexing and will benefit from any future features that make use of the alias.
If you are unsure when your current index was created,
you can check whether it was created after GitLab 13.0 by using the
[Elasticsearch cat aliases API](https://www.elastic.co/guide/en/elasticsearch/reference/7.11/cat-alias.html).
If the list of aliases returned contains an entry for `gitlab-production` that points to an index
named `gitlab-production-<numerical timestamp>`, your index was created after GitLab 13.0.
If the `gitlab-production` alias is missing, you'll need to reindex from scratch to use
If the `gitlab-production` alias is missing, you need to reindex from scratch to use
features such as Zero-downtime reindexing.
## Elasticsearch repository indexer
@ -116,7 +116,7 @@ The former Ruby-based indexer was removed in [GitLab 12.3](https://gitlab.com/gi
### From source
First, we need to install some dependencies, then we'll build and install
First, we need to install some dependencies, then we build and install
the indexer itself.
This project relies on [ICU](http://site.icu-project.org/) for text encoding,

46
doc/integration/saml.md
View File

@ -86,7 +86,7 @@ in your SAML IdP:
```
1. Ensure that the SAML [`NameID`](../user/group/saml_sso/index.md#nameid) and email address are fixed for each user,
as described in the section on [Security](#security). Otherwise, your users will be able to sign in as other authorized users.
as described in the section on [Security](#security). Otherwise, your users are able to sign in as other authorized users.
1. Add the provider configuration:
@ -137,7 +137,7 @@ as described in the section on [Security](#security). Otherwise, your users will
for more details on these options.
See the [notes on configuring your identity provider](#notes-on-configuring-your-identity-provider) for more information.
1. Change the value of `issuer` to a unique name, which will identify the application
1. Change the value of `issuer` to a unique name, which identifies the application
to the IdP.
1. For the changes to take effect, you must [reconfigure](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) GitLab if you installed via Omnibus or [restart GitLab](../administration/restart_gitlab.md#installations-from-source) if you installed from source.
@ -158,7 +158,7 @@ See [the assertions list](#assertions) for other available claims.
On the sign in page there should now be a SAML button below the regular sign in form.
Click the icon to begin the authentication process. If everything goes well the user
will be returned to GitLab and will be signed in.
is returned to GitLab and signed in.
### Notes on configuring your identity provider
@ -250,7 +250,7 @@ Your IdP passes Group Information to the SP (GitLab) in the SAML Response. You n
- Which group membership is requisite to sign in via the `required_groups` setting
When `required_groups` is not set or it is empty, anyone with proper authentication
will be able to use the service.
is able to use the service.
Example:
@ -424,8 +424,8 @@ omniauth:
auto_sign_in_with_provider: saml
```
Keep in mind that every sign in attempt will be redirected to the SAML server;
you won't be able to sign in using local credentials. Ensure at least one of the
Keep in mind that every sign in attempt redirects to the SAML server;
you cannot sign in using local credentials. Ensure at least one of the
SAML users has admin permissions.
You may also bypass the auto sign-in feature by browsing to
@ -442,7 +442,7 @@ in the OmniAuth [`info` hash](https://github.com/omniauth/omniauth/wiki/Auth-Has
For example, if your SAMLResponse contains an Attribute called `EmailAddress`,
specify `{ email: ['EmailAddress'] }` to map the Attribute to the
corresponding key in the `info` hash. URI-named Attributes are also supported, e.g.
corresponding key in the `info` hash. URI-named Attributes are also supported, for example,
`{ email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }`.
This setting allows you tell GitLab where to look for certain attributes required
@ -463,7 +463,7 @@ args: {
#### Setting a username
By default, the email in the SAML response will be used to automatically generate the user's GitLab username. If you'd like to set another attribute as the username, assign it to the `nickname` OmniAuth `info` hash attribute. For example, if you wanted to set the `username` attribute in your SAML Response to the username in GitLab, use the following setting:
By default, the email in the SAML response is used to automatically generate the user's GitLab username. If you'd like to set another attribute as the username, assign it to the `nickname` OmniAuth `info` hash attribute. For example, if you wanted to set the `username` attribute in your SAML Response to the username in GitLab, use the following setting:
```yaml
args: {
@ -587,7 +587,7 @@ args: {
}
```
Your Identity Provider will encrypt the assertion with the public certificate of GitLab. GitLab will decrypt the EncryptedAssertion with its private key.
Your Identity Provider encrypts the assertion with the public certificate of GitLab. GitLab decrypts the EncryptedAssertion with its private key.
NOTE:
This integration uses the `certificate` and `private_key` settings for both assertion encryption and request signing.
@ -629,7 +629,7 @@ args: {
}
```
GitLab will sign the request with the provided private key. GitLab will include the configured public x500 certificate in the metadata for your Identity Provider to validate the signature of the received request with. For more information on this option, see the [Ruby SAML gem documentation](https://github.com/onelogin/ruby-saml/tree/v1.7.0). The Ruby SAML gem is used by the [OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml) to implement the client side of the SAML authentication.
GitLab signs the request with the provided private key. GitLab includes the configured public x500 certificate in the metadata for your Identity Provider to validate the signature of the received request with. For more information on this option, see the [Ruby SAML gem documentation](https://github.com/onelogin/ruby-saml/tree/v1.7.0). The Ruby SAML gem is used by the [OmniAuth SAML gem](https://github.com/omniauth/omniauth-saml) to implement the client side of the SAML authentication.
## Security
@ -652,7 +652,7 @@ For information on the GitLab.com implementation, please see the [SAML SSO for G
Group SAML SSO helps if you need to allow access via multiple SAML identity providers, but as a multi-tenant solution is less suited to cases where you administer your own GitLab instance.
To proceed with configuring Group SAML SSO instead, you'll need to enable the `group_saml` OmniAuth provider. This can be done from:
To proceed with configuring Group SAML SSO instead, enable the `group_saml` OmniAuth provider. This can be done from:
- `gitlab.rb` for [Omnibus GitLab installations](#omnibus-installations).
- `gitlab/config/gitlab.yml` for [source installations](#source-installations).
@ -715,17 +715,17 @@ The following guidance is based on this Okta article, on adding a [SAML Applicat
1. When the app screen comes up you see another button to **Create an App** and
choose SAML 2.0 on the next screen.
1. Optionally, you can add a logo
(you can choose it from <https://about.gitlab.com/press/>). You'll have to
(you can choose it from <https://about.gitlab.com/press/>). You must
crop and resize it.
1. Next, you'll need the to fill in the SAML general configuration with
1. Next, fill in the SAML general configuration with
the assertion consumer service URL as "Single sign-on URL" and
the issuer as "Audience URI" along with the [NameID](../user/group/saml_sso/index.md#nameid) and [assertions](#assertions).
1. The last part of the configuration is the feedback section where you can
just say you're a customer and creating an app for internal use.
1. When you have your app you'll have a few tabs on the top of the app's
1. When you have your app you can see a few tabs on the top of the app's
profile. Click on the SAML 2.0 configuration instructions button.
1. On the screen that comes up take note of the
**Identity Provider Single Sign-On URL** which you'll use for the
**Identity Provider Single Sign-On URL** which you can use for the
`idp_sso_target_url` on your GitLab configuration file.
1. **Before you leave Okta, make sure you add your user and groups if any.**
@ -734,14 +734,14 @@ The following guidance is based on this Okta article, on adding a [SAML Applicat
The following guidance is based on this Google Workspace article, on how to [Set up your own custom SAML application](https://support.google.com/a/answer/6087519?hl=en):
Make sure you have access to a Google Workspace [Super Admin](https://support.google.com/a/answer/2405986#super_admin) account.
Follow the instructions in the linked Google Workspace article, where you'll need the following information:
Use the information below and follow the instructions in the linked Google Workspace article.
| | Typical value | Description |
|------------------|--------------------------------------------------|----------------------------------------------------------|
| Name of SAML App | GitLab | Other names OK. |
| ACS URL | `https://<GITLAB_DOMAIN>/users/auth/saml/callback` | ACS is short for Assertion Consumer Service. |
| GITLAB_DOMAIN | `gitlab.example.com` | Set to the domain of your GitLab instance. |
| Entity ID | `https://gitlab.example.com` | A value unique to your SAML app, you'll set it to the `issuer` in your GitLab configuration. |
| Entity ID | `https://gitlab.example.com` | A value unique to your SAML app, set it to the `issuer` in your GitLab configuration. |
| Name ID format | EMAIL | Required value. Also known as `name_identifier_format` |
| Name ID | Primary email address | Make sure someone receives content sent to that address |
| First name | `first_name` | Required value to communicate with GitLab. |
@ -806,7 +806,7 @@ section for further troubleshooting steps.
### Redirect back to the login screen with no evident error
If after signing in into your SAML server you are redirected back to the sign in page and
no error is displayed, check your `production.log` file. It will most likely contain the
no error is displayed, check your `production.log` file. It most likely contains the
message `Can't verify CSRF token authenticity`. This means that there is an error during
the SAML request, but in GitLab 11.7 and earlier this error never reaches GitLab due to
the CSRF check.
@ -814,7 +814,7 @@ the CSRF check.
To bypass this you can add `skip_before_action :verify_authenticity_token` to the
`omniauth_callbacks_controller.rb` file immediately after the `class` line and
comment out the `protect_from_forgery` line using a `#`. Restart Unicorn for this
change to take effect. This will allow the error to hit GitLab, where it can then
change to take effect. This allows the error to hit GitLab, where it can then
be seen in the usual logs, or as a flash message on the login screen.
That file is located in `/opt/gitlab/embedded/service/gitlab-rails/app/controllers`
@ -838,11 +838,11 @@ audiences of the IdP server.
The IdP server needs to pass certain information in order for GitLab to either
create an account, or match the login information to an existing account. `email`
is the minimum amount of information that needs to be passed. If the IdP server
is not providing this information, all SAML requests will fail.
is not providing this information, all SAML requests fail.
Make sure this information is provided.
Another issue that can result in this error is when the correct information is being sent by the IdP, but the attributes don't match the names in the OmniAuth `info` hash. In this case, you'll need to set `attribute_statements` in the SAML configuration to [map the attribute names in your SAML Response to the corresponding OmniAuth `info` hash names](#attribute_statements).
Another issue that can result in this error is when the correct information is being sent by the IdP, but the attributes don't match the names in the OmniAuth `info` hash. In this case, you need to set `attribute_statements` in the SAML configuration to [map the attribute names in your SAML Response to the corresponding OmniAuth `info` hash names](#attribute_statements).
### Key validation error, Digest mismatch or Fingerprint mismatch
@ -859,8 +859,8 @@ For this you need take the following into account:
the request to contain one. In this case the fingerprint or fingerprint
validators are optional
Make sure that one of the above described scenarios is valid, or the requests will
fail with one of the mentioned errors.
If none of the above described scenarios is valid, the request
fails with one of the mentioned errors.
### User is blocked when signing in through SAML

8
doc/policy/maintenance.md
View File

@ -103,12 +103,12 @@ have to adhere to various internal requirements (for example, org. compliance, v
1. Requirements consisting of extensive testing for not only stable GitLab release, but every patch version.
In cases where a strategic user has a requirement to test a feature before it is
officially released, we can offer to create a Release Candidate (RC) version that will
include the specific feature. This should be needed only in extreme cases and can be requested for
officially released, we can offer to create a Release Candidate (RC) version that
includes the specific feature. This should be needed only in extreme cases and can be requested for
consideration by raising an issue in the [release/tasks](https://gitlab.com/gitlab-org/release/tasks/-/issues/new?issuable_template=Backporting-request) issue tracker.
It is important to note that the Release Candidate will also contain other features and changes as
It is important to note that the Release Candidate contains other features and changes as
it is not possible to easily isolate a specific feature (similar reasons as noted above). The
Release Candidate will be no different than any code that is deployed to GitLab.com or is publicly
Release Candidate is no different than any code that is deployed to GitLab.com or is publicly
accessible.
### Backporting to older releases

12
doc/user/group/saml_sso/scim_setup.md
View File

@ -71,7 +71,7 @@ your SAML configuration differs from [the recommended SAML settings](index.md#az
modify the corresponding `customappsso` settings accordingly. If a mapping is not listed in the
table, use the Azure defaults.
| Azure Active Directory Attribute | customappsso Attribute | Matching precedence |
| Azure Active Directory Attribute | `customappsso` Attribute | Matching precedence |
| -------------------------------- | ---------------------- | -------------------- |
| `objectId` | `externalId` | 1 |
| `userPrincipalName` | `emails[type eq "work"].value` | |
@ -129,11 +129,11 @@ configuration. Otherwise, the Okta SCIM app may not work properly.
- For **API Token** enter the SCIM token obtained from the GitLab SCIM configuration page
1. Click 'Test API Credentials' to verify configuration.
1. Click **Save** to apply the settings.
1. After saving the API integration details, new settings tabs will appear on the left. Choose **To App**.
1. After saving the API integration details, new settings tabs appear on the left. Choose **To App**.
1. Click **Edit**.
1. Check the box to **Enable** for both **Create Users** and **Deactivate Users**.
1. Click **Save**.
1. Assign users in the **Assignments** tab. Assigned users will be created and
1. Assign users in the **Assignments** tab. Assigned users are created and
managed in your GitLab group.
#### Okta Known Issues
@ -212,7 +212,7 @@ Ensure that the user has been added to the SCIM app.
If you receive "User is not linked to a SAML account", then most likely the user already exists in GitLab. Have the user follow the [User access and linking setup](#user-access-and-linking-setup) instructions.
The **Identity** (`extern_uid`) value stored by GitLab is updated by SCIM whenever `id` or `externalId` changes. Users won't be able to sign in unless the GitLab Identity (`extern_uid`) value matches the `NameId` sent by SAML.
The **Identity** (`extern_uid`) value stored by GitLab is updated by SCIM whenever `id` or `externalId` changes. Users cannot sign in unless the GitLab Identity (`extern_uid`) value matches the `NameId` sent by SAML.
This value is also used by SCIM to match users on the `id`, and is updated by SCIM whenever the `id` or `externalId` values change.
@ -242,9 +242,9 @@ you can address the problem in the following ways:
- You can have users unlink and relink themselves, based on the ["SAML authentication failed: User has already been taken"](index.md#message-saml-authentication-failed-user-has-already-been-taken) section.
- You can unlink all users simultaneously, by removing all users from the SAML app while provisioning is turned on.
- It may be possible to use the [SCIM API](../../../api/scim.md#update-a-single-scim-provisioned-user) to manually correct the `externalId` stored for users to match the SAML `NameId`.
To look up a user, you'll need to know the desired value that matches the `NameId` as well as the current `externalId`.
To look up a user, you need to know the desired value that matches the `NameId` as well as the current `externalId`.
It is important not to update these to incorrect values, since this will cause users to be unable to sign in. It is also important not to assign a value to the wrong user, as this would cause users to get signed into the wrong account.
It is important not to update these to incorrect values, since this causes users to be unable to sign in. It is also important not to assign a value to the wrong user, as this causes users to get signed into the wrong account.
### I need to change my SCIM app

14
doc/user/project/import/gemnasium.md
View File

@ -33,7 +33,7 @@ subscription at that time, your card will be refunded on a
<!-- vale gitlab.Spelling = NO --> pro rata temporis <!-- vale gitlab.Spelling = YES --> basis.
You may contact `gemnasium@gitlab.com` regarding your closed account.
## Will my account/data be transferred to GitLab Inc.?
## Are my account/data transferred to GitLab Inc.?
All accounts and data have been deleted on May 15th, 2018. GitLab Inc.
doesn't know anything about your private data, nor your projects, and therefore
@ -41,7 +41,7 @@ if they were vulnerable or not. GitLab Inc. takes personal information very seri
## What happened to my badge?
To avoid broken 404 images, all badges pointing to Gemnasium.com will be a
To avoid broken 404 images, all badges pointing to Gemnasium.com are a
placeholder, inviting you to migrate to GitLab (and pointing to this page).
## Migrating to GitLab
@ -69,7 +69,7 @@ back to both GitLab and GitHub when completed.
<!-- vale gitlab.Spelling = NO -->
1. Create a new project, and select **CI/CD for external repo**:
1. Create a new project, and select **CI/CD for external repository**:
![Create new Project](img/gemnasium/create_project_v13_5.png)
<!-- vale gitlab.Spelling = YES -->
@ -87,7 +87,7 @@ back to both GitLab and GitHub when completed.
![click on connected project](img/gemnasium/project_connected.png)
Your project is now mirrored on GitLab, where the runners will be able to access
Your project is now mirrored on GitLab, where the runners are able to access
your source code and run your tests.
Optional step: If you set this up on GitLab.com, make sure the project is
@ -102,12 +102,12 @@ back to both GitLab and GitHub when completed.
![Edit YAML file](img/gemnasium/edit_gitlab-ci.png)
1. Once your file has been committed, a new pipeline will be automatically
triggered if your file is valid:
1. Once your file has been committed, a new pipeline automatically
triggers if your file is valid:
![pipeline](img/gemnasium/pipeline.png)
1. The result of the job will be visible directly from the pipeline view:
1. The result of the job is visible directly from the pipeline view:
![Security Dashboard](../../application_security/security_dashboard/img/pipeline_security_dashboard_v13_3.png)

20
doc/user/project/import/gitea.md
View File

@ -31,8 +31,8 @@ to users in your GitLab instance. This means that the project creator (most of
the times the current user that started the import process) is set as the author,
but a reference on the issue about the original Gitea author is kept.
The importer will create any new namespaces (groups) if they don't exist or in
the case the namespace is taken, the repository will be imported under the user's
The importer creates any new namespaces (groups) if they don't exist or in
the case the namespace is taken, the repository is imported under the user's
namespace that started the import process.
## Importing your Gitea repositories
@ -41,13 +41,13 @@ The importer page is visible when you create a new project.
![New project page on GitLab](img/import_projects_from_new_project_page.png)
Click on the **Gitea** link and the import authorization process will start.
Click on the **Gitea** link and the import authorization process starts.
![New Gitea project import](img/import_projects_from_gitea_new_import.png)
### Authorize access to your repositories using a personal access token
With this method, you will perform a one-off authorization with Gitea to grant
With this method, you perform a one-off authorization with Gitea to grant
GitLab access your repositories:
1. Go to `https://your-gitea-instance/user/settings/applications` (replace
@ -58,19 +58,19 @@ GitLab access your repositories:
1. Copy the token hash.
1. Go back to GitLab and provide the token to the Gitea importer.
1. Hit the **List Your Gitea Repositories** button and wait while GitLab reads
your repositories' information. Once done, you'll be taken to the importer
your repositories' information. Once done, you are taken to the importer
page to select the repositories to import.
### Select which repositories to import
After you've authorized access to your Gitea repositories, you will be
After you've authorized access to your Gitea repositories, you are
redirected to the Gitea importer page.
From there, you can see the import statuses of your Gitea repositories.
- Those that are being imported will show a _started_ status,
- those already successfully imported will be green with a _done_ status,
- whereas those that are not yet imported will have an **Import** button on the
- Those that are being imported show a _started_ status,
- those already successfully imported are green with a _done_ status,
- whereas those that are not yet imported have an **Import** button on the
right side of the table.
You also can:
@ -78,7 +78,7 @@ You also can:
- Import all your Gitea projects in one go by hitting **Import all projects** in
the upper left corner
- Filter projects by name. If filter is applied, hitting **Import all projects**
will only import matched projects
only imports matched projects
![Gitea importer page](img/import_projects_from_gitea_importer_v12_3.png)

8
doc/user/project/import/gitlab_com.md
View File

@ -19,10 +19,10 @@ you'll need to follow the instructions for [exporting a project](../settings/imp
![New project page](img/gitlab_new_project_page_v12_2.png)
Go to the **Import Projects** tab, then click on **GitLab.com**, and you will be redirected to GitLab.com
for permission to access your projects. After accepting, you'll be automatically redirected to the importer.
Go to the **Import Projects** tab, then click on **GitLab.com**, and you are redirected to GitLab.com
for permission to access your projects. After accepting, you are automatically redirected to the importer.
![Importer page](img/gitlab_importer.png)
To import a project, click "Import". The importer will import your repository and issues.
Once the importer is done, a new GitLab project will be created with your imported data.
To import a project, click "Import". The importer imports your repository and issues.
Once the importer is done, a new GitLab project is created with your imported data.

34
doc/user/project/import/svn.md
View File

@ -38,15 +38,15 @@ directly in a file system level.
follow [this article](http://www.webupd8.org/2012/09/install-oracle-java-8-in-ubuntu-via-ppa.html).
1. Download SubGit from <https://subgit.com/download>.
1. Unpack the downloaded SubGit zip archive to the `/opt` directory. The `subgit`
command will be available at `/opt/subgit-VERSION/bin/subgit`.
command is available at `/opt/subgit-VERSION/bin/subgit`.
### SubGit configuration
The first step to mirror you SVN repository in GitLab is to create a new empty
project which will be used as a mirror. For Omnibus installations the path to
the repository will be located at
project that is used as a mirror. For Omnibus installations the path to
the repository is
`/var/opt/gitlab/git-data/repositories/USER/REPO.git` by default. For
installations from source, the default repository directory will be
installations from source, the default repository directory is
`/home/git/repositories/USER/REPO.git`. For convenience, assign this path to a
variable:
@ -54,7 +54,7 @@ variable:
GIT_REPO_PATH=/var/opt/gitlab/git-data/repositories/USER/REPOS.git
```
SubGit will keep this repository in sync with a remote SVN project. For
SubGit keeps this repository in sync with a remote SVN project. For
convenience, assign your remote SVN project URL to a variable:
```shell
@ -89,9 +89,9 @@ initial translation of existing SVN revisions into the Git repository:
subgit install $GIT_REPO_PATH
```
After the initial translation is completed, the Git repository and the SVN
project will be kept in sync by `subgit` - new Git commits will be translated to
SVN revisions and new SVN revisions will be translated to Git commits. Mirror
After the initial translation is completed, `subgit` keeps the Git repository and the SVN
project sync - new Git commits are translated to
SVN revisions and new SVN revisions are translated to Git commits. Mirror
works transparently and does not require any special commands.
If you would prefer to perform one-time cut over migration with `subgit`, use
@ -134,12 +134,12 @@ sudo apt-get install git-core git-svn ruby
```
Optionally, prepare an authors file so `svn2git` can map SVN authors to Git authors.
If you choose not to create the authors file then commits will not be attributed
If you choose not to create the authors file then commits are not attributed
to the correct GitLab user. Some users may not consider this a big issue while
others will want to ensure they complete this step. If you choose to map authors
you will be required to map every author that is present on changes in the SVN
repository. If you don't, the conversion will fail and you will have to update
the author file accordingly. The following command will search through the
others want to ensure they complete this step. If you choose to map authors,
you must map every author present on changes in the SVN
repository. If you don't, the conversion fails and you have to update
the author file accordingly. The following command searches through the
repository and output a list of authors.
```shell
@ -159,7 +159,7 @@ not nested) the conversion is simple. For a non-standard repository see
[svn2git documentation](https://github.com/nirvdrum/svn2git). The following
command will checkout the repository and do the conversion in the current
working directory. Be sure to create a new directory for each repository before
running the `svn2git` command. The conversion process will take some time.
running the `svn2git` command. The conversion process takes some time.
```shell
svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
@ -167,13 +167,13 @@ svn2git https://svn.example.com/path/to/repo --authors /path/to/authors.txt
If your SVN repository requires a username and password add the
`--username <username>` and `--password <password>` flags to the above command.
`svn2git` also supports excluding certain file paths, branches, tags, etc. See
`svn2git` also supports excluding certain file paths, branches, tags, and so on. See
[svn2git documentation](https://github.com/nirvdrum/svn2git) or run
`svn2git --help` for full documentation on all of the available options.
Create a new GitLab project, where you will eventually push your converted code.
Create a new GitLab project, into which you push your converted code.
Copy the SSH or HTTP(S) repository URL from the project page. Add the GitLab
repository as a Git remote and push all the changes. This will push all commits,
repository as a Git remote and push all the changes. This pushes all commits,
branches and tags.
```shell

10
doc/user/project/merge_requests/fail_fast_testing.md
View File

@ -49,7 +49,7 @@ This template requires:
## Configuring Fast RSpec Failure
We'll use the following plain RSpec configuration as a starting point. It installs all the
We use the following plain RSpec configuration as a starting point. It installs all the
project gems and executes `rspec`, on merge request pipelines only.
```yaml
@ -86,13 +86,13 @@ For illustrative purposes, let's say our Rails app spec suite consists of 100 sp
If no Ruby files are changed:
- `rspec-rails-modified-paths-specs` will not run any tests.
- `rspec-complete` will run the full suite of 1000 tests.
- `rspec-rails-modified-paths-specs` does not run any tests.
- `rspec-complete` runs the full suite of 1000 tests.
If one Ruby model is changed, for example `app/models/example.rb`, then `rspec-rails-modified-paths-specs`
will run the 100 tests for `example.rb`:
runs the 100 tests for `example.rb`:
- If all of these 100 tests pass, then the full `rspec-complete` suite of 1000 tests is allowed to run.
- If any of these 100 tests fail, they will fail quickly, and `rspec-complete` will not run any tests.
- If any of these 100 tests fail, they fail quickly, and `rspec-complete` does not run any tests.
The final case saves resources and time as the full 1000 test suite does not run.