Commit 612a849a authored by 🤖 GitLab Bot 🤖's avatar 🤖 GitLab Bot 🤖

Add latest changes from gitlab-org/[email protected]er

parent bd8fb566
......@@ -115,7 +115,7 @@ also running Unicorn/Puma and/or Sidekiq.
Example output:
```
```plaintext
Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
......@@ -465,7 +465,7 @@ For installations from source:
Note: This option only works for remote storage. If you want to group your backups
you can pass a `DIRECTORY` environment variable:
```
```shell
sudo gitlab-backup create DIRECTORY=daily
sudo gitlab-backup create DIRECTORY=weekly
```
......@@ -586,7 +586,7 @@ crontab -e
There, add the following line to schedule the backup for everyday at 2 AM:
```
```plaintext
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
```
......@@ -614,7 +614,7 @@ sudo -u git crontab -e # Edit the crontab for the git user
Add the following lines at the bottom:
```
```plaintext
# Create a full backup of the GitLab repositories and SQL database every day at 4am
0 4 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1
```
......@@ -674,7 +674,7 @@ Read more on [configuring NFS mounts](../administration/high_availability/nfs.md
### Restore for installation from source
```
```shell
# Stop processes that are connected to the database
sudo service gitlab stop
......@@ -683,7 +683,7 @@ bundle exec rake gitlab:backup:restore RAILS_ENV=production
Example output:
```
```plaintext
Unpacking backup... [DONE]
Restoring database tables:
-- create_table("events", {:force=>true})
......@@ -853,7 +853,7 @@ will have all your repositories, but not any other data.
If you are using backup restore procedures you might encounter the following warnings:
```
```plaintext
psql:/var/opt/gitlab/backups/db/database.sql:22: ERROR: must be owner of extension plpgsql
psql:/var/opt/gitlab/backups/db/database.sql:2931: WARNING: no privileges could be revoked for "public" (two occurrences)
psql:/var/opt/gitlab/backups/db/database.sql:2933: WARNING: no privileges were granted for "public" (two occurrences)
......@@ -1003,7 +1003,7 @@ GitLab instance after restoring the registry data.
These failures will mention permission issues in the registry logs, like:
```
```plaintext
level=error
msg="response completed with error"
err.code=unknown
......
......@@ -6,7 +6,7 @@ Clean up local project upload files if they don't exist in GitLab database. The
task attempts to fix the file if it can find its project, otherwise it moves the
file to a lost and found directory.
```
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:project_uploads
......@@ -16,8 +16,9 @@ bundle exec rake gitlab:cleanup:project_uploads RAILS_ENV=production
Example output:
```
```shell
$ sudo gitlab-rake gitlab:cleanup:project_uploads
I, [2018-07-27T12:08:27.671559 #89817] INFO -- : Looking for orphaned project uploads to clean up. Dry run...
D, [2018-07-27T12:08:28.293568 #89817] DEBUG -- : Processing batch of 500 project upload file paths, starting with /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out
I, [2018-07-27T12:08:28.689869 #89817] INFO -- : Can move to lost and found /opt/gitlab/embedded/service/gitlab-rails/public/uploads/test.out -> /opt/gitlab/embedded/service/gitlab-rails/public/uploads/-/project-lost-found/test.out
......@@ -35,7 +36,7 @@ I, [2018-07-27T12:08:33.760257 #89817] INFO -- : Did move to lost and found /op
Remove object store upload files if they don't exist in GitLab database.
```
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:remote_upload_files
......@@ -45,7 +46,7 @@ bundle exec rake gitlab:cleanup:remote_upload_files RAILS_ENV=production
Example output:
```
```shell
$ sudo gitlab-rake gitlab:cleanup:remote_upload_files
I, [2018-08-02T10:26:13.995978 #45011] INFO -- : Looking for orphaned remote uploads to remove. Dry run...
......@@ -54,7 +55,7 @@ I, [2018-08-02T10:26:14.120482 #45011] INFO -- : Can be moved to lost and found
I, [2018-08-02T10:26:14.120634 #45011] INFO -- : To cleanup these files run this command with DRY_RUN=false
```
```
```shell
$ sudo gitlab-rake gitlab:cleanup:remote_upload_files DRY_RUN=false
I, [2018-08-02T10:26:47.598424 #45087] INFO -- : Looking for orphaned remote uploads to remove...
......@@ -109,7 +110,7 @@ level with `NICENESS`. Below are the valid levels, but consult
## Remove expired ActiveSession lookup keys
```
```shell
# omnibus-gitlab
sudo gitlab-rake gitlab:cleanup:sessions:active_sessions_lookup_keys
......
......@@ -15,6 +15,6 @@ Old path: `[email protected]:myrepo.git`
New path: `[email protected]:username/myrepo.git` or `[email protected]:groupname/myrepo.git`
```
```shell
bundle exec rake gitlab:enable_namespaces RAILS_ENV=production
```
......@@ -11,6 +11,6 @@ which loads the appropriate data set if it is present within the `sample_metrics
**Example:**
```
```shell
bundle exec rake gitlab:generate_sample_prometheus_data[21]
```
......@@ -15,7 +15,7 @@
The new folder needs to have Git user ownership and read/write/execute access for Git user and its group:
```
```shell
sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
```
......@@ -27,7 +27,7 @@ sudo -u git mkdir -p /var/opt/gitlab/git-data/repository-import-<date>/new_group
If we copy the repos to `/var/opt/gitlab/git-data/repository-import-<date>`, and repo A needs to be under the groups G1 and G2, it will
have to be created under those folders: `/var/opt/gitlab/git-data/repository-import-<date>/G1/G2/A.git`.
```
```shell
sudo cp -r /old/git/foo.git /var/opt/gitlab/git-data/repository-import-<date>/new_group/
# Do this once when you are done copying git repositories
......@@ -57,7 +57,7 @@ sudo -u git -H bundle exec rake gitlab:import:repos['/var/opt/gitlab/git-data/re
#### Example output
```
```plaintext
Processing /var/opt/gitlab/git-data/repository-import-1/a/b/c/blah.git
* Using namespace: a/b/c
* Created blah (a/b/c/blah)
......
......@@ -3,7 +3,7 @@
You can print a list of all Git repositories on disk managed by
GitLab with the following command:
```
```shell
# Omnibus
sudo gitlab-rake gitlab:list_repos
......@@ -17,7 +17,7 @@ a date with the 'SINCE' environment variable. The time you specify
is parsed by the Rails [TimeZone#parse
function](https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html#method-i-parse).
```
```shell
# Omnibus
sudo gitlab-rake gitlab:list_repos SINCE='Sep 1 2015'
......
......@@ -91,7 +91,7 @@ production:
Next, generate a new secret:
```
```shell
# omnibus-gitlab
sudo gitlab-rake secret
......@@ -102,7 +102,7 @@ bundle exec rake secret RAILS_ENV=production
Now you need to stop the GitLab server, back up the existing secrets file and
update the database:
```
```shell
# omnibus-gitlab
sudo gitlab-ctl stop
sudo cp config/secrets.yml config/secrets.yml.bak
......@@ -122,7 +122,7 @@ error.
Finally, change `config/secrets.yml` to set `otp_key_base` to `<new key>` and
restart. Again, make sure you're operating in the **production** section.
```
```shell
# omnibus-gitlab
sudo gitlab-ctl start
......@@ -133,7 +133,7 @@ sudo /etc/init.d/gitlab start
If there are any problems (perhaps using the wrong value for `old_key`), you can
restore your backup of `config/secrets.yml` and rollback the changes:
```
```shell
# omnibus-gitlab
sudo gitlab-ctl stop
sudo gitlab-rake gitlab:two_factor:rotate_key:rollback filename=backup.csv
......
......@@ -33,7 +33,7 @@ Although SPDY is enabled in Omnibus installations, CRIME relies on compression
The Nessus scanner, [reports a possible CRIME vulnerability][nessus] in GitLab
similar to the following format:
```
```plaintext
Description
This remote service has one of two configurations that are known to be required for the CRIME attack:
......
......@@ -60,7 +60,7 @@ default['gitlab']['gitlab-rails']['rack_attack_protected_paths'] = [
This header is included in responses to blocked requests:
```
```plaintext
Retry-After: 60
```
......@@ -109,7 +109,7 @@ No response headers are provided.
1. Reconfigure GitLab:
```
```shell
sudo gitlab-ctl reconfigure
```
......@@ -202,7 +202,7 @@ the load balancer. In that case, you will need to:
1. Whitelist the load balancer's IP address(es) in the Rack Attack [settings](#settings).
1. Reconfigure GitLab:
```
```shell
sudo gitlab-ctl reconfigure
```
......
......@@ -124,7 +124,7 @@ To create a new SSH key pair:
If, in any case, you want to add or change the password of your SSH key pair,
you can use the `-p` flag:
```
```shell
ssh-keygen -p -f <keyname>
```
......@@ -206,7 +206,7 @@ authenticity of the GitLab host you are connecting to.
For example, when connecting to GitLab.com, answer `yes` to add GitLab.com to
the list of trusted hosts:
```
```plaintext
The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw.
Are you sure you want to continue connecting (yes/no)? yes
......@@ -423,8 +423,9 @@ security risks.
The GitLab check process includes a check for this condition, and will direct you
to this section if your server is configured like this, e.g.:
```
```shell
$ gitlab-rake gitlab:check
# ...
Git user has default SSH configuration? ... no
Try fixing it:
......
......@@ -41,7 +41,7 @@ for Push and Tag events, but we never display commits.
**Request header**:
```
```plaintext
X-Gitlab-Event: System Hook
```
......@@ -396,7 +396,7 @@ It generates one event per modified branch.
**Request header**:
```
```plaintext
X-Gitlab-Event: System Hook
```
......@@ -462,7 +462,7 @@ It generates one event per modified tag.
**Request header**:
```
```plaintext
X-Gitlab-Event: System Hook
```
......@@ -516,7 +516,7 @@ updated/merged/closed or a commit is added in the source branch.
**Request header**:
```
```plaintext
X-Gitlab-Event: System Hook
```
......@@ -643,7 +643,7 @@ Triggered only once when you push to the repository (including tags).
**Request header**:
```
```plaintext
X-Gitlab-Event: System Hook
```
......
......@@ -54,13 +54,13 @@ pgloader within the container as it is not included in the container image.
1. Start a shell session in the context of the running container:
``` bash
```shell
docker exec -it gitlab bash
```
1. Install pgloader:
``` bash
```shell
apt-get update
apt-get -y install pgloader
```
......@@ -78,7 +78,7 @@ need to enable the bundled PostgreSQL:
1. Edit `/etc/gitlab/gitlab.rb` to enable bundled PostgreSQL:
```
```ruby
postgresql['enable'] = true
```
......@@ -116,7 +116,7 @@ new PostgreSQL one:
1. Save the following snippet in a `commands.load` file, and edit with your
MySQL database `username`, `password` and `host`:
```
```sql
LOAD DATABASE
FROM mysql://username:password@host/gitlabhq_production
INTO postgresql://gitlab-psql@unix://var/opt/gitlab/postgresql:/gitlabhq_production
......@@ -143,7 +143,7 @@ new PostgreSQL one:
1. Once the migration finishes, you should see a summary table that looks like
the following:
```
```plaintext
table name read imported errors total time
----------------------------------------------- --------- --------- --------- --------------
fetch meta data 119 119 0 0.388s
......@@ -217,7 +217,7 @@ new PostgreSQL one:
1. Save the following snippet in a `commands.load` file, and edit with your
MySQL `username`, `password` and `host`:
```
```sql
LOAD DATABASE
FROM mysql://username:password@host/gitlabhq_production
INTO postgresql://postgres@unix://var/run/postgresql:/gitlabhq_production
......@@ -244,7 +244,7 @@ new PostgreSQL one:
1. Once the migration finishes, you should see a summary table that looks like
the following:
```
```plaintext
table name read imported errors total time
----------------------------------------------- --------- --------- --------- --------------
fetch meta data 119 119 0 0.388s
......@@ -284,7 +284,7 @@ Sometimes, you might encounter some errors during or after the migration.
The PostgreSQL user that you use for the migration MUST have **superuser** privileges.
Otherwise, you may see a similar message to the following:
```
```plaintext
debugger invoked on a CL-POSTGRES-ERROR:INSUFFICIENT-PRIVILEGE in thread
#<THREAD "lparallel" RUNNING {10078A3513}>:
Database error 42501: permission denied: "RI_ConstraintTrigger_a_20937" is a system trigger
......
......@@ -28,7 +28,7 @@ may need to manually correct the problem next time you upgrade.
Example error:
```
```plaintext
== 20151103134857 CreateLfsObjects: migrating =================================
-- create_table(:lfs_objects)
rake aborted!
......@@ -48,7 +48,7 @@ need to do.
Pass the version to a database rake task to manually mark the migration as
complete.
```
```shell
# Source install
sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
......@@ -62,7 +62,7 @@ migrations are marked complete.
### GitLab < 8.6
```
```shell
# Source install
sudo -u git -H bundle exec rails console -e production
......@@ -72,7 +72,7 @@ sudo gitlab-rails console
At the Rails console, type the following commands:
```
```ruby
ActiveRecord::Base.connection.execute("INSERT INTO schema_migrations (version) VALUES('20151103134857')")
exit
```
......
......@@ -78,8 +78,8 @@ Each stage of Value Stream Analytics is further described in the table below.
| Plan | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
| Code | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
| Test | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |
| Review | Measures the median time taken to review the merge request that has closing issue pattern, between its creation and until it's merged. |
| Staging | Measures the median time between merging the merge request with closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
| Review | Measures the median time taken to review the merge request that has a closing issue pattern, between its creation and until it's merged. |
| Staging | Measures the median time between merging the merge request with a closing issue pattern until the very first deployment to production. It's tracked by the environment set to `production` or matching `production/*` (case-sensitive, `Production` won't work) in your GitLab CI configuration. If there isn't a production environment, this is not tracked. |
| Total | The sum of all time (medians) taken to run the entire process, from issue creation to deploying the code to production. [Previously known](https://gitlab.com/gitlab-org/gitlab/issues/38317) as **Production**. |
How this works, behind the scenes:
......
......@@ -39,7 +39,7 @@ To enable 2FA:
1. **In GitLab:**
1. Log in to your GitLab account.
1. Go to your **Profile Settings**.
1. Go to your [**Profile settings**](../index.md#profile-settings).
1. Go to **Account**.
1. Click **Enable Two-factor Authentication**.
1. **On your device (usually your phone):**
......@@ -84,7 +84,7 @@ Search for `security.webauth.u2f` and double click on it to toggle to `true`.
To set up 2FA with a U2F device:
1. Log in to your GitLab account.
1. Go to your **Profile Settings**.
1. Go to your [**Profile settings**](../index.md#profile-settings).
1. Go to **Account**.
1. Click **Enable Two-Factor Authentication**.
1. Plug in your U2F device.
......@@ -139,7 +139,7 @@ request and you will be automatically logged in.
If you ever need to disable 2FA:
1. Log in to your GitLab account.
1. Go to your **Profile Settings**.
1. Go to your [**Profile settings**](../index.md#profile-settings).
1. Go to **Account**.
1. Click **Disable**, under **Two-Factor Authentication**.
......@@ -226,7 +226,7 @@ To regenerate 2FA recovery codes, you need access to a desktop browser:
1. Navigate to GitLab.
1. Sign in to your GitLab account.
1. Go to your [Profile settings](../index.md#profile-settings).
1. Go to your [**Profile settings**](../index.md#profile-settings).
1. Select **{account}** **Account > Two-Factor Authentication (2FA)**.
1. If you've already configured 2FA, click **Manage two-factor authentication**.
1. In the **Register Two-Factor Authenticator** pane, click **Regenerate recovery codes**.
......
......@@ -6,9 +6,14 @@ Issues are the fundamental medium for collaborating on ideas and planning work i
The GitLab issue tracker is an advanced tool for collaboratively developing ideas, solving problems, and planning work.
Issues can allow you and your team to share and discuss proposals
before, and during, their implementation. However, they can be used for a variety of
other purposes, customized to your needs and workflow.
Issues can allow sharing and discussion of proposals before, and during,
their implementation between:
- You and your team.
- Outside collaborators.
They can also be used for a variety of other purposes, customized to your
needs and workflow.
Issues are always associated with a specific project, but if you have multiple projects in a group,
you can also view all the issues collectively at the group level.
......
......@@ -116,12 +116,17 @@ The next time a pipeline is scheduled, your credentials will be used.
![Schedules list](img/pipeline_schedules_ownership.png)
NOTE: **Note:**
If the owner of a pipeline schedule doesn't have the ability to create pipelines
on the target branch, the schedule will stop creating new pipelines. This can
happen if the owner is blocked or removed from the project, or
the target branch or tag is protected. In this case, someone with sufficient
privileges must take ownership of the schedule.
If the owner of a pipeline schedule doesn't have the ability to create
pipelines on the target branch, the schedule will stop creating new
pipelines.
This can happen if, for example:
- The owner is blocked or removed from the project.
- The target branch or tag is protected.
In this case, someone with sufficient privileges must take ownership of the
schedule.
<!-- ## Troubleshooting
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment