SSOT edits to docs that are alone in root directories
This commit is contained in:
parent
72611cbc3a
commit
20c66d6e29
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
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 ...
|
||||
|
|
|
@ -1,8 +1,15 @@
|
|||
# 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` |
|
||||
|
|
|
@ -1,13 +1,12 @@
|
|||
---
|
||||
type: reference
|
||||
---
|
||||
|
||||
# Public access
|
||||
|
||||
GitLab allows [Owners](../user/permissions.md) to change a projects' visibility in order to be accessed
|
||||
**publicly** or **internally**.
|
||||
|
||||
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).
|
||||
|
||||
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. -->
|
||||
|
|
|
@ -1,6 +1,11 @@
|
|||
---
|
||||
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
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
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
|
||||
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
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. -->
|
||||
|
|
|
@ -1,3 +1,7 @@
|
|||
---
|
||||
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. -->
|
||||
|
|
|
@ -1,12 +1,12 @@
|
|||
---
|
||||
type: howto
|
||||
---
|
||||
|
||||
# Email from GitLab **[STARTER ONLY]**
|
||||
|
||||
As a GitLab administrator you can email GitLab users from within GitLab.
|
||||
|
||||
## Overview
|
||||
|
||||
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. -->
|
||||
|
|
Loading…
Reference in New Issue