Skip to content

G
gitlab-ce
Commit 20c66d6e authored by Marcel Amirault's avatar Marcel Amirault
Browse files
Options

SSOT edits to docs that are alone in root directories

parent 72611cbc
Show whitespace changes
Inline Side-by-side
Showing with 141 additions and 55 deletions
doc/migrate_ci_to_ce/README.md
View file @ 20c66d6e
---
type: howto
---
# Migrate GitLab CI to GitLab CE or EE
Beginning with version 8.0 of GitLab Community Edition (CE) and Enterprise
......@@ -333,7 +337,9 @@ restoration](../raketasks/backup_restore.md) guide.
## Troubleshooting
### show:secrets problem (Omnibus-only)
If you see errors like this:
```
Missing `secret_key_base` or `db_key_base` for 'production' environment. The secrets will be generated and stored in `config/secrets.yml`
rake aborted!
......@@ -344,6 +350,7 @@ This can happen if you are updating from versions prior to 7.13 straight to 8.0.
The fix for this is to update to Omnibus 7.14 first and then update it to 8.0.
### Permission denied when accessing /var/opt/gitlab/gitlab-ci/builds
To fix that issue you have to change builds/ folder permission before doing final backup:
```
sudo chown -R gitlab-ci:gitlab-ci /var/opt/gitlab/gitlab-ci/builds
......@@ -355,8 +362,10 @@ sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
```
### Problems when importing CI database to GitLab
If you were migrating CI database from MySQL to PostgreSQL manually you can see errors during import about missing sequences:
```
```sql
ALTER SEQUENCE
ERROR: relation "ci_builds_id_seq" does not exist
ERROR: relation "ci_commits_id_seq" does not exist
......@@ -373,9 +382,9 @@ CREATE TABLE
To fix that you need to apply this SQL statement before doing final backup:
```sql
## Omnibus GitLab
Omnibus GitLab installations:
```sql
gitlab-ci-rails dbconsole <<EOF
-- ALTER TABLES - DROP DEFAULTS
ALTER TABLE ONLY ci_application_settings ALTER COLUMN id DROP DEFAULT;
......@@ -428,9 +437,11 @@ ALTER TABLE ONLY ci_triggers ALTER COLUMN id SET DEFAULT nextval('ci_triggers_id
ALTER TABLE ONLY ci_variables ALTER COLUMN id SET DEFAULT nextval('ci_variables_id_seq'::regclass);
ALTER TABLE ONLY ci_web_hooks ALTER COLUMN id SET DEFAULT nextval('ci_web_hooks_id_seq'::regclass);
EOF
```
## Source installations
Source installations:
```
cd /home/gitlab_ci/gitlab-ci
sudo -u gitlab_ci -H bundle exec rails dbconsole production <<EOF
... COPY SQL STATEMENTS FROM ABOVE ...
......
doc/policy/maintenance.md
View file @ 20c66d6e
# GitLab Maintenance Policy
---
type: concepts
---
# GitLab Release and Maintenance Policy
GitLab has strict policies governing version naming, as well as release pace for major, minor,
patch and security releases. New releases are usually announced on the [GitLab blog](https://about.gitlab.com/blog/categories/releases/).
## Versioning
GitLab follows the [Semantic Versioning](http://semver.org/) for its releases:
GitLab uses [Semantic Versioning](http://semver.org/) for its releases:
`(Major).(Minor).(Patch)` in a [pragmatic way](https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e).
For example, for GitLab version 10.5.7:
......@@ -16,8 +23,8 @@ Any part of the version number can increment into multiple digits, for example,
The following table describes the version types and their release cadence:
| Version type | Description | Cadence |
|:-------------|:----------|:-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Major | For significant changes, or when any backward-incompatible changes are introduced to the public API. | Yearly. The next major release is GitLab 12.0 on June 22, 2019. Subsequent major releases will be scheduled for May 22 each year, by default. | |
|:-------------|:------------|:--------|
| Major | For significant changes, or when any backward-incompatible changes are introduced to the public API. | Yearly. The next major release is GitLab 12.0 on June 22, 2019. Subsequent major releases will be scheduled for May 22 each year, by default. |
| Minor | For when new backward-compatible functionality is introduced to the public API, a minor feature is introduced, or when a set of smaller features is rolled out. | Monthly on the 22nd. |
| Patch | For backward-compatible bug fixes that fix incorrect behavior. See [Patch releases](#patch-releases). | As needed. |
......@@ -75,7 +82,7 @@ that could change behavior in the next major release.
Please see the table below for some examples:
| Latest stable version | Your version | Recommended upgrade path | Note |
| -------------- | ------------ | ------------------------ | ---------------- |
| --------------------- | ------------ | ------------------------ | ---- |
| 9.4.5 | 8.13.4 | `8.13.4` -> `8.17.7` -> `9.4.5` | `8.17.7` is the last version in version `8` |
| 10.1.4 | 8.13.4 | `8.13.4 -> 8.17.7 -> 9.5.10 -> 10.1.4` | `8.17.7` is the last version in version `8`, `9.5.10` is the last version in version `9` |
| 11.3.4 | 8.13.4 | `8.13.4` -> `8.17.7` -> `9.5.10` -> `10.8.7` -> `11.3.4` | `8.17.7` is the last version in version `8`, `9.5.10` is the last version in version `9`, `10.8.7` is the last version in version `10` |
......
doc/public_access/public_access.md
View file @ 20c66d6e
# Public access
GitLab allows [Owners](../user/permissions.md) to change a projects' visibility in order to be accessed
**publicly** or **internally**.
---
type: reference
---
Projects with either of these visibility levels will be listed in the
public access directory (`/public` under your GitLab instance).
Here is the [GitLab.com example](https://gitlab.com/public).
# Public access
Internal projects will only be available to authenticated users.
GitLab allows [Owners](../user/permissions.md) to set a projects' visibility as **public**, **internal**
or **private**. These visibility levels will affect who will be able to see the project in in the
public access directory (`/public` under your GitLab instance), like at [https://gitlab.com/public]().
## Visibility of projects
......@@ -15,26 +14,26 @@ Internal projects will only be available to authenticated users.
Public projects can be cloned **without any** authentication.
They will also be listed on the public access directory (`/public`).
They will be listed in the public access directory (`/public`) for all users.
**Any logged in user** will have [Guest](../user/permissions.md)
permissions on the repository.
**Any logged in user** will have [Guest permissions](../user/permissions.md)
on the repository.
### Internal projects
Internal projects can be cloned by any logged in user.
They will also be listed on the public access directory (`/public`) for logged
They will also be listed in the public access directory (`/public`), but only for logged
in users.
Any logged in user will have [Guest](../user/permissions.md) permissions
Any logged in user will have [Guest permissions](../user/permissions.md)
on the repository.
### Private projects
Private projects can only be cloned and viewed by project members, and
they will only appear to project members on the public access directory
(`https://gitlab.example.com/public`).
Private projects can only be cloned and viewed by project members.
They will appear in the public access directory (`/public`) for project members only.
### How to change project visibility
......@@ -76,3 +75,15 @@ snippet:
This is useful to prevent people exposing their repositories to public
by accident. The restricted visibility settings do not apply to admin users.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
doc/push_rules/push_rules.md
View file @ 20c66d6e
---
type: reference, howto
---
# Push Rules **[STARTER]**
Gain additional control over pushes to your repository.
Gain additional control over what can and can't be pushed to your repository by using
regular expressions to reject pushes based on commit contents, branch names or file details.
## Overview
......@@ -33,7 +38,7 @@ will be accepted.
### Restrict branch names
Let's assume there's a strictly policy for branch names in your company, and
Let's assume there's a strict policy for branch names in your company, and
you want the branches to start with a certain name because you have different
GitLab CI jobs (`feature`, `hotfix`, `docker`, `android`, etc.) that rely on the
branch name.
......@@ -72,7 +77,7 @@ The following options are available.
| Maximum file size | **Starter** 7.12 | Pushes that contain added or updated files that exceed this file size (in MB) are rejected. Set to 0 to allow files of any size. |
>**Tip:**
GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions in push rules. You can check your regular expressions at <https://regex-golang.appspot.com>.
GitLab uses [RE2 syntax](https://github.com/google/re2/wiki/Syntax) for regular expressions in push rules, and you can test them at the [GoLang regex tester](https://regex-golang.appspot.com).
## Prevent pushing secrets to the repository
......@@ -148,6 +153,18 @@ pry.history
bash_history
```
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
[protected-branches]: ../user/project/protected_branches.md
[signing-commits]: ../user/project/repository/gpg_signed_commits/index.md
[ee-385]: https://gitlab.com/gitlab-org/gitlab-ee/issues/385
......
doc/ssh/README.md
View file @ 20c66d6e
---
type: howto, reference
---
# GitLab and SSH keys
Git is a distributed version control system, which means you can work locally
......@@ -50,8 +54,7 @@ more information, you can read this
We'll focus on ED25519 and RSA and here.
NOTE: **Note:**
As an admin, you can restrict
[which keys should be permitted and their minimum length](../security/ssh_keys_restrictions.md).
As an admin, you can [restrict which keys should be permitted and their minimum length](../security/ssh_keys_restrictions.md).
By default, all keys are permitted, which is also the case for
[GitLab.com](../user/gitlab_com/index.md#ssh-host-keys-fingerprints).
......@@ -91,9 +94,8 @@ ssh-keygen -o -f ~/.ssh/id_rsa
## Generating a new SSH key pair
Before creating an SSH key pair, make sure to read about the
[different types of keys](#types-of-ssh-keys-and-which-to-choose) to understand
their differences.
Before creating an SSH key pair, make sure to understand the
[different types of keys](#types-of-ssh-keys-and-which-to-choose).
To create a new SSH key pair:
......@@ -332,7 +334,7 @@ not implicitly give any access just by setting them up.
### Eclipse
How to add your SSH key to Eclipse: <https://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration>
If you are using [EGit](https://www.eclipse.org/egit/), you can [add your SSH key to Eclipse](https://wiki.eclipse.org/EGit/User_Guide#Eclipse_SSH_Configuration).
## SSH on the GitLab server
......
doc/subscriptions/index.md
View file @ 20c66d6e
---
type: index, reference
---
# Subscription setup and management
This page will help get you started with your new subscription or manage an existing one, whether you have subscribed to GitLab.com or self-managed GitLab.
......@@ -101,3 +105,15 @@ These issues are the best avenue for getting updates on specific product plans a
### Contacting Support
Learn more about the tiers of [GitLab Support](https://about.gitlab.com/support/) or [submit a request via the Support Portal](https://support.gitlab.com/hc/en-us/requests/new).
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
doc/system_hooks/system_hooks.md
View file @ 20c66d6e
---
type: reference
---
# System hooks
Your GitLab instance can perform HTTP POST requests on the following events:
......@@ -27,11 +31,7 @@ The triggers for most of these are self-explanatory, but `project_update` and `p
System hooks can be used, e.g. for logging or changing information in a LDAP server.
> **Note:**
>
> We follow the same structure from Webhooks for Push and Tag events, but we never display commits.
>
> Same deprecations from Webhooks are valid here.
NOTE: **Note:** We follow the same structure and deprecations as [Webhooks](../user/project/integrations/webhooks.md) for Push and Tag events, but we never display commits.
## Hooks request example
......@@ -640,3 +640,15 @@ X-Gitlab-Event: System Hook
"refs":["refs/heads/master"]
}
```
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
doc/tools/email.md
View file @ 20c66d6e
# Email from GitLab **[STARTER ONLY]**
As a GitLab administrator you can email GitLab users from within GitLab.
---
type: howto
---
## Overview
# Email from GitLab **[STARTER ONLY]**
GitLab provides a simple tool to email all users or users of a chosen group or
project right from the admin area. Users will receive the email to their primary
email address.
GitLab provides a simple tool to administrators for emailing all users, or users of
a chosen group or project, right from the admin area. Users will receive the email
at their primary email address.
## Use-cases
......@@ -28,11 +28,21 @@ email address.
## Unsubscribing from emails
User can choose to unsubscribe from receiving emails from GitLab by following
the unsubscribe link from the email. Unsubscribing is unauthenticated in order
to keep the simplicity of this feature.
Users can choose to unsubscribe from receiving emails from GitLab by following
the unsubscribe link in the email. Unsubscribing is unauthenticated in order
to keep this feature simple.
On unsubscribe, user will receive an email notifying that unsubscribe happened.
On unsubscribe, users will receive an email notification that unsubscribe happened.
The endpoint that provides the unsubscribe option is rate-limited.
[ee]: https://about.gitlab.com/pricing/
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
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
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7