Skip to content
Snippets Groups Projects
Commit 74a8d300 authored by Marcel Amirault's avatar Marcel Amirault Committed by Evan Read
Browse files

Fix whitespace in user, and misc, docs 

Many code blocks are 4spaced, and they render in GitLab
without coloring as a result, even though they are
fenced with a language label. If in a list, other items
woll render as being in a code block too, even if not
meant to. This fixes all these issues, and cleans up
minor whitespace issues in /user, /security, /ssh
and /migrate_ci_to_ce docs.
parent 5f8a6730
No related branches found
No related tags found
No related merge requests found
Expand all Hide whitespace changes
Inline Side-by-side
Showing
with 930 additions and 920 deletions
doc/migrate_ci_to_ce/README.md
+ 10
− 4
View file @ 74a8d300
@@ -181,7 +181,7 @@ sudo -u gitlab_ci -H bundle exec rake backup:show_secrets RAILS_ENV=production
### 2. SQL data and build traces
 
Create your final CI data export. If you are converting from MySQL to
PostgreSQL, add ` MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
PostgreSQL, add `MYSQL_TO_POSTGRESQL=1` to the end of the rake command. When
the command finishes it will print the path to your data export archive; you
will need this file later.
 
@@ -323,11 +323,15 @@ You should also make sure that you can:
 
### 2. Check Nginx configuration
 
sudo nginx -t
```sh
sudo nginx -t
```
 
### 3. Restart Nginx
 
sudo /etc/init.d/nginx restart
```sh
sudo /etc/init.d/nginx restart
```
 
### Restore from backup
 
@@ -352,11 +356,13 @@ 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
```
 
Then before executing `ci:migrate` you need to fix builds folder permission:
```
sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
```
@@ -365,7 +371,7 @@ sudo chown git:git /var/opt/gitlab/gitlab-ci/builds
 
If you were migrating CI database from MySQL to PostgreSQL manually you can see errors during import about missing sequences:
 
```sql
```sql
ALTER SEQUENCE
ERROR: relation "ci_builds_id_seq" does not exist
ERROR: relation "ci_commits_id_seq" does not exist
doc/security/rack_attack.md
+ 38
− 38
View file @ 74a8d300
@@ -34,34 +34,34 @@ For more information on how to use these options check out
1. Open `/etc/gitlab/gitlab.rb` with your editor
1. Add the following:
 
```ruby
gitlab_rails['rack_attack_git_basic_auth'] = {
'enabled' => true,
'ip_whitelist' => ["127.0.0.1"],
'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
}
```
```ruby
gitlab_rails['rack_attack_git_basic_auth'] = {
'enabled' => true,
'ip_whitelist' => ["127.0.0.1"],
'maxretry' => 10, # Limit the number of Git HTTP authentication attempts per IP
'findtime' => 60, # Reset the auth attempt counter per IP after 60 seconds
'bantime' => 3600 # Ban an IP for one hour (3600s) after too many auth attempts
}
```
 
1. Reconfigure GitLab:
 
```
sudo gitlab-ctl reconfigure
```
```
sudo gitlab-ctl reconfigure
```
 
The following settings can be configured:
 
- `enabled`: By default this is set to `false`. Set this to `true` to enable Rack Attack.
- `ip_whitelist`: Whitelist any IPs from being blocked. They must be formatted as strings within a Ruby array.
CIDR notation is supported in GitLab v12.1 and up.
For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"]`.
CIDR notation is supported in GitLab v12.1 and up.
For example, `["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"]`.
- `maxretry`: The maximum amount of times a request can be made in the
specified time.
specified time.
- `findtime`: The maximum amount of time that failed requests can count against an IP
before it's blacklisted (in seconds).
before it's blacklisted (in seconds).
- `bantime`: The total amount of time that a blacklisted IP will be blocked (in
seconds).
seconds).
 
**Installations from source**
 
@@ -71,18 +71,18 @@ taken in order to enable protection for your GitLab instance:
 
1. In `config/application.rb` find and uncomment the following line:
 
```ruby
config.middleware.use Rack::Attack
```
```ruby
config.middleware.use Rack::Attack
```
 
1. Copy `config/initializers/rack_attack.rb.example` to `config/initializers/rack_attack.rb`
1. Open `config/initializers/rack_attack.rb`, review the
`paths_to_be_protected`, and add any other path you need protecting
1. Restart GitLab:
 
```sh
sudo service gitlab restart
```
```sh
sudo service gitlab restart
```
 
If you want more restrictive/relaxed throttle rules, edit
`config/initializers/rack_attack.rb` and change the `limit` or `period` values.
@@ -98,28 +98,28 @@ In case you want to remove a blocked IP, follow these steps:
 
1. Find the IPs that have been blocked in the production log:
 
```sh
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
```
```sh
grep "Rack_Attack" /var/log/gitlab/gitlab-rails/auth.log
```
 
1. Since the blacklist is stored in Redis, you need to open up `redis-cli`:
 
```sh
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
```
```sh
/opt/gitlab/embedded/bin/redis-cli -s /var/opt/gitlab/redis/redis.socket
```
 
1. You can remove the block using the following syntax, replacing `<ip>` with
the actual IP that is blacklisted:
 
```
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
```
```
del cache:gitlab:rack::attack:allow2ban:ban:<ip>
```
 
1. Confirm that the key with the IP no longer shows up:
 
```
keys *rack::attack*
```
```
keys *rack::attack*
```
 
1. Optionally, add the IP to the whitelist to prevent it from being blacklisted
again (see [settings](#settings)).
@@ -136,8 +136,8 @@ 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:
 
```
sudo gitlab-ctl reconfigure
```
```
sudo gitlab-ctl reconfigure
```
 
1. [Remove the block via Redis.](#remove-blocked-ips-from-rack-attack-via-redis)
doc/ssh/README.md
+ 40
− 41
View file @ 74a8d300
@@ -64,13 +64,13 @@ Following [best practices](https://linux-audit.com/using-ed25519-openssh-keys-in
you should always favor [ED25519](https://ed25519.cr.yp.to/) SSH keys, since they
are more secure and have better performance over the other types.
 
ED25519 SSH keys were introduced in OpenSSH 6.5,
so any modern OS should include the option to create them.
If for any reason your OS or the GitLab instance you interact with doesn't
ED25519 SSH keys were introduced in OpenSSH 6.5,
so any modern OS should include the option to create them.
If for any reason your OS or the GitLab instance you interact with doesn't
support ED25519, you can fallback to RSA.
 
NOTE: **Note:**
Omnibus does not ship with OpenSSH, so it uses the version on your GitLab server. If using
Omnibus does not ship with OpenSSH, so it uses the version on your GitLab server. If using
Omnibus, ensure the version of OpenSSH installed is version 6.5 or newer if you want to use ED25519 SSH keys.
 
### RSA SSH keys
@@ -107,18 +107,18 @@ To create a new SSH key pair:
1. Open a terminal on Linux or macOS, or Git Bash / WSL on Windows.
1. Generate a new ED25519 SSH key pair:
 
```bash
ssh-keygen -t ed25519 -C "email@example.com"
```
```bash
ssh-keygen -t ed25519 -C "email@example.com"
```
 
Or, if you want to use RSA:
Or, if you want to use RSA:
 
```bash
ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
```
```bash
ssh-keygen -o -t rsa -b 4096 -C "email@example.com"
```
 
The `-C` flag adds a comment in the key in case you have multiple of them
and want to tell which is which. It is optional.
The `-C` flag adds a comment in the key in case you have multiple of them
and want to tell which is which. It is optional.
 
1. Next, you will be prompted to input a file path to save your SSH key pair to.
If you don't already have an SSH key pair and aren't generating a [deploy key](#deploy-keys),
@@ -126,21 +126,21 @@ To create a new SSH key pair:
<kbd>Enter</kbd>. Using the suggested path will normally allow your SSH client
to automatically use the SSH key pair with no additional configuration.
 
If you already have an SSH key pair with the suggested file path, you will need
to input a new file path and [declare what host](#working-with-non-default-ssh-key-pair-paths)
this SSH key pair will be used for in your `~/.ssh/config` file.
If you already have an SSH key pair with the suggested file path, you will need
to input a new file path and [declare what host](#working-with-non-default-ssh-key-pair-paths)
this SSH key pair will be used for in your `~/.ssh/config` file.
 
1. Once the path is decided, you will be prompted to input a password to
secure your new SSH key pair. It's a best practice to use a password,
but it's not required and you can skip creating it by pressing
<kbd>Enter</kbd> twice.
 
If, in any case, you want to add or change the password of your SSH key pair,
you can use the `-p` flag:
If, in any case, you want to add or change the password of your SSH key pair,
you can use the `-p` flag:
 
```
ssh-keygen -p -o -f <keyname>
```
```
ssh-keygen -p -o -f <keyname>
```
 
Now, it's time to add the newly created public key to your GitLab account.
 
@@ -149,41 +149,40 @@ Now, it's time to add the newly created public key to your GitLab account.
1. Copy your **public** SSH key to the clipboard by using one of the commands below
depending on your Operating System:
 
**macOS:**
**macOS:**
 
```bash
pbcopy < ~/.ssh/id_ed25519.pub
```
```bash
pbcopy < ~/.ssh/id_ed25519.pub
```
 
**WSL / GNU/Linux (requires the xclip package):**
**WSL / GNU/Linux (requires the xclip package):**
 
```bash
xclip -sel clip < ~/.ssh/id_ed25519.pub
```
```bash
xclip -sel clip < ~/.ssh/id_ed25519.pub
```
 
**Git Bash on Windows:**
**Git Bash on Windows:**
 
```bash
cat ~/.ssh/id_ed25519.pub | clip
```
```bash
cat ~/.ssh/id_ed25519.pub | clip
```
 
You can also open the key in a graphical editor and copy it from there,
but be careful not to accidentally change anything.
You can also open the key in a graphical editor and copy it from there,
but be careful not to accidentally change anything.
 
NOTE: **Note:**
If you opted to create an RSA key, the name might differ.
NOTE: **Note:**
If you opted to create an RSA key, the name might differ.
 
1. Add your **public** SSH key to your GitLab account by:
1. Clicking your avatar in the upper right corner and selecting **Settings**.
1. Navigating to **SSH Keys** and pasting your **public** key in the **Key** field. If you:
- Created the key with a comment, this will appear in the **Title** field.
- Created the key without a comment, give your key an identifiable title like _Work Laptop_ or _Home Workstation_.
1. Click the **Add key** button.
 
NOTE: **Note:**
If you manually copied your public SSH key make sure you copied the entire
key starting with `ssh-ed25519` (or `ssh-rsa`) and ending with your email.
NOTE: **Note:**
If you manually copied your public SSH key make sure you copied the entire
key starting with `ssh-ed25519` (or `ssh-rsa`) and ending with your email.
 
## Testing that everything is set up correctly
 
doc/user/group/saml_sso/scim_setup.md
+ 23
− 23
View file @ 74a8d300
@@ -27,23 +27,23 @@ The following identity providers are supported:
- [Group SSO](index.md) needs to be configured.
- The `scim_group` feature flag must be enabled:
 
Run the following commands in a Rails console:
Run the following commands in a Rails console:
 
```sh
# Omnibus GitLab
gitlab-rails console
```sh
# Omnibus GitLab
gitlab-rails console
 
# Installation from source
cd /home/git/gitlab
sudo -u git -H bin/rails console RAILS_ENV=production
```
# Installation from source
cd /home/git/gitlab
sudo -u git -H bin/rails console RAILS_ENV=production
```
 
To enable SCIM for a group named `group_name`:
To enable SCIM for a group named `group_name`:
 
```ruby
group = Group.find_by_full_path('group_name')
Feature.enable(:group_scim, group)
```
```ruby
group = Group.find_by_full_path('group_name')
Feature.enable(:group_scim, group)
```
 
### GitLab configuration
 
@@ -85,26 +85,26 @@ You can then test the connection clicking on `Test Connection`.
1. Map the `userPricipalName` to `emails[type eq "work"].value` and `mailNickname` to
`userName`.
 
Example configuration:
Example configuration:
 
![Azure's attribute mapping configuration](img/scim_attribute_mapping.png)
![Azure's attribute mapping configuration](img/scim_attribute_mapping.png)
 
1. Click on **Show advanced options > Edit attribute list for AppName**.
1. Leave the `id` as the primary and only required field.
 
NOTE: **Note:**
`username` should neither be primary nor required as we don't support
that field on GitLab SCIM yet.
NOTE: **Note:**
`username` should neither be primary nor required as we don't support
that field on GitLab SCIM yet.
 
![Azure's attribute advanced configuration](img/scim_advanced.png)
![Azure's attribute advanced configuration](img/scim_advanced.png)
 
1. Save all the screens and, in the **Provisioning** step, set
the `Provisioning Status` to `ON`.
 
NOTE: **Note:**
You can control what is actually synced by selecting the `Scope`. For example,
`Sync only assigned users and groups` will only sync the users assigned to
the application (`Users and groups`), otherwise it will sync the whole Active Directory.
NOTE: **Note:**
You can control what is actually synced by selecting the `Scope`. For example,
`Sync only assigned users and groups` will only sync the users assigned to
the application (`Users and groups`), otherwise it will sync the whole Active Directory.
 
Once enabled, the synchronization details and any errors will appear on the
bottom of the **Provisioning** screen, together with a link to the audit logs.
doc/user/markdown.md
+ 5
− 3
View file @ 74a8d300
@@ -586,9 +586,11 @@ def function():
print s
```
 
Using 4 spaces
is like using
3-backtick fences.
```
Using 4 spaces
is like using
3-backtick fences.
```
 
~~~
Tildes are OK too.
doc/user/profile/account/two_factor_authentication.md
+ 23
− 23
View file @ 74a8d300
@@ -183,29 +183,29 @@ a new set of recovery codes with SSH:
1. You will then be prompted to confirm that you want to generate new codes.
Continuing this process invalidates previously saved codes:
 
```sh
Are you sure you want to generate new two-factor recovery codes?
Any existing recovery codes you saved will be invalidated. (yes/no)
yes
Your two-factor authentication recovery codes are:
119135e5a3ebce8e
11f6v2a498810dcd
3924c7ab2089c902
e79a3398bfe4f224
34bd7b74adbc8861
f061691d5107df1a
169bf32a18e63e7f
b510e7422e81c947
20dbed24c5e74663
df9d3b9403b9c9f0
During sign in, use one of the codes above when prompted for your
two-factor code. Then, visit your Profile Settings and add a new device
so you do not lose access to your account again.
```
```sh
Are you sure you want to generate new two-factor recovery codes?
Any existing recovery codes you saved will be invalidated. (yes/no)
yes
Your two-factor authentication recovery codes are:
119135e5a3ebce8e
11f6v2a498810dcd
3924c7ab2089c902
e79a3398bfe4f224
34bd7b74adbc8861
f061691d5107df1a
169bf32a18e63e7f
b510e7422e81c947
20dbed24c5e74663
df9d3b9403b9c9f0
During sign in, use one of the codes above when prompted for your
two-factor code. Then, visit your Profile Settings and add a new device
so you do not lose access to your account again.
```
 
1. Go to the GitLab sign-in page and enter your username/email and password.
When prompted for a two-factor code, enter one of the recovery codes obtained
doc/user/project/clusters/eks_and_gitlab/index.md
+ 87
− 87
View file @ 74a8d300
@@ -40,97 +40,97 @@ then click **Add an existing Kubernetes cluster**.
 
A few details from the EKS cluster will be required to connect it to GitLab:
 
1. **Retrieve the certificate**: A valid Kubernetes certificate is needed to
authenticate to the EKS cluster. We will use the certificate created by default.
Open a shell and use `kubectl` to retrieve it:
1. **Retrieve the certificate**: A valid Kubernetes certificate is needed to
authenticate to the EKS cluster. We will use the certificate created by default.
Open a shell and use `kubectl` to retrieve it:
 
- List the secrets with `kubectl get secrets`, and one should named similar to
`default-token-xxxxx`. Copy that token name for use below.
- Get the certificate with:
- List the secrets with `kubectl get secrets`, and one should named similar to
`default-token-xxxxx`. Copy that token name for use below.
- Get the certificate with:
 
```sh
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
```
1. **Create admin token**: A `cluster-admin` token is required to install and
manage Helm Tiller. GitLab establishes mutual SSL auth with Helm Tiller
and creates limited service accounts for each application. To create the
token we will create an admin service account as follows:
2.1. Create a file called `eks-admin-service-account.yaml` with contents:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-admin
namespace: kube-system
```
2.2. Apply the service account to your cluster:
```bash
kubectl apply -f eks-admin-service-account.yaml
```sh
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
```
 
Output:
```bash
serviceaccount "eks-admin" created
```
2.3. Create a file called `eks-admin-cluster-role-binding.yaml` with contents:
```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: eks-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: eks-admin
namespace: kube-system
```
2.4. Apply the cluster role binding to your cluster:
```bash
kubectl apply -f eks-admin-cluster-role-binding.yaml
```
Output:
```bash
clusterrolebinding "eks-admin" created
```
2.5. Retrieve the token for the `eks-admin` service account:
```bash
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
```
Copy the `<authentication_token>` value from the output:
```yaml
Name: eks-admin-token-b5zv4
Namespace: kube-system
Labels: <none>
Annotations: kubernetes.io/service-account.name=eks-admin
kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1025 bytes
namespace: 11 bytes
token: <authentication_token>
```
1. **Create admin token**: A `cluster-admin` token is required to install and
manage Helm Tiller. GitLab establishes mutual SSL auth with Helm Tiller
and creates limited service accounts for each application. To create the
token we will create an admin service account as follows:
2.1. Create a file called `eks-admin-service-account.yaml` with contents:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-admin
namespace: kube-system
```
2.2. Apply the service account to your cluster:
```bash
kubectl apply -f eks-admin-service-account.yaml
```
Output:
```bash
serviceaccount "eks-admin" created
```
2.3. Create a file called `eks-admin-cluster-role-binding.yaml` with contents:
```yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: eks-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: eks-admin
namespace: kube-system
```
2.4. Apply the cluster role binding to your cluster:
```bash
kubectl apply -f eks-admin-cluster-role-binding.yaml
```
Output:
```bash
clusterrolebinding "eks-admin" created
```
2.5. Retrieve the token for the `eks-admin` service account:
```bash
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
```
Copy the `<authentication_token>` value from the output:
```yaml
Name: eks-admin-token-b5zv4
Namespace: kube-system
Labels: <none>
Annotations: kubernetes.io/service-account.name=eks-admin
kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1025 bytes
namespace: 11 bytes
token: <authentication_token>
```
 
1. The API server endpoint is also required, so GitLab can connect to the cluster.
This is displayed on the AWS EKS console, when viewing the EKS cluster details.
doc/user/project/clusters/index.md
+ 112
− 110
View file @ 74a8d300
@@ -56,8 +56,8 @@ new Kubernetes cluster to your project:
 
1. Navigate to your project's **Operations > Kubernetes** page.
 
NOTE: **Note:**
You need Maintainer [permissions] and above to access the Kubernetes page.
NOTE: **Note:**
You need Maintainer [permissions] and above to access the Kubernetes page.
 
1. Click **Add Kubernetes cluster**.
1. Click **Create with Google Kubernetes Engine**.
@@ -97,117 +97,119 @@ To add an existing Kubernetes cluster to your project:
 
1. Navigate to your project's **Operations > Kubernetes** page.
 
NOTE: **Note:**
You need Maintainer [permissions] and above to access the Kubernetes page.
NOTE: **Note:**
You need Maintainer [permissions] and above to access the Kubernetes page.
 
1. Click **Add Kubernetes cluster**.
1. Click **Add an existing Kubernetes cluster** and fill in the details:
- **Kubernetes cluster name** (required) - The name you wish to give the cluster.
- **Environment scope** (required) - The
[associated environment](#setting-the-environment-scope-premium) to this cluster.
- **API URL** (required) -
It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
exposes several APIs, we want the "base" URL that is common to all of them,
e.g., `https://kubernetes.example.com` rather than `https://kubernetes.example.com/api/v1`.
Get the API URL by running this command:
```sh
kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'
```
- **CA certificate** (required) - A valid Kubernetes certificate is needed to authenticate to the EKS cluster. We will use the certificate created by default.
- List the secrets with `kubectl get secrets`, and one should named similar to
`default-token-xxxxx`. Copy that token name for use below.
- Get the certificate by running this command:
```sh
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
```
- **Token** -
GitLab authenticates against Kubernetes using service tokens, which are
scoped to a particular `namespace`.
**The token used should belong to a service account with
[`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
privileges.** To create this service account:
1. Create a file called `gitlab-admin-service-account.yaml` with contents:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab-admin
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: gitlab-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: gitlab-admin
namespace: kube-system
```
1. Apply the service account and cluster role binding to your cluster:
```bash
kubectl apply -f gitlab-admin-service-account.yaml
```
Output:
```bash
serviceaccount "gitlab-admin" created
clusterrolebinding "gitlab-admin" created
```
1. Retrieve the token for the `gitlab-admin` service account:
```bash
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
```
Copy the `<authentication_token>` value from the output:
```yaml
Name: gitlab-admin-token-b5zv4
Namespace: kube-system
Labels: <none>
Annotations: kubernetes.io/service-account.name=gitlab-admin
kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1025 bytes
namespace: 11 bytes
token: <authentication_token>
```
NOTE: **Note:**
For GKE clusters, you will need the
`container.clusterRoleBindings.create` permission to create a cluster
role binding. You can follow the [Google Cloud
documentation](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
to grant access.
- **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster. See the [Managed clusters section](#gitlab-managed-clusters) for more information.
- **Project namespace** (optional) - You don't have to fill it in; by leaving
it blank, GitLab will create one for you. Also:
- Each project should have a unique namespace.
- The project namespace is not necessarily the namespace of the secret, if
you're using a secret with broader permissions, like the secret from `default`.
- You should **not** use `default` as the project namespace.
- If you or someone created a secret specifically for the project, usually
with limited permissions, the secret's namespace and project namespace may
be the same.
- **Kubernetes cluster name** (required) - The name you wish to give the cluster.
- **Environment scope** (required) - The
[associated environment](#setting-the-environment-scope-premium) to this cluster.
- **API URL** (required) -
It's the URL that GitLab uses to access the Kubernetes API. Kubernetes
exposes several APIs, we want the "base" URL that is common to all of them,
e.g., `https://kubernetes.example.com` rather than `https://kubernetes.example.com/api/v1`.
Get the API URL by running this command:
```sh
kubectl cluster-info | grep 'Kubernetes master' | awk '/http/ {print $NF}'
```
- **CA certificate** (required) - A valid Kubernetes certificate is needed to authenticate to the EKS cluster. We will use the certificate created by default.
- List the secrets with `kubectl get secrets`, and one should named similar to
`default-token-xxxxx`. Copy that token name for use below.
- Get the certificate by running this command:
```sh
kubectl get secret <secret name> -o jsonpath="{['data']['ca\.crt']}" | base64 --decode
```
- **Token** -
GitLab authenticates against Kubernetes using service tokens, which are
scoped to a particular `namespace`.
**The token used should belong to a service account with
[`cluster-admin`](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles)
privileges.** To create this service account:
1. Create a file called `gitlab-admin-service-account.yaml` with contents:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: gitlab-admin
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: gitlab-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: gitlab-admin
namespace: kube-system
```
1. Apply the service account and cluster role binding to your cluster:
```bash
kubectl apply -f gitlab-admin-service-account.yaml
```
Output:
```bash
serviceaccount "gitlab-admin" created
clusterrolebinding "gitlab-admin" created
```
1. Retrieve the token for the `gitlab-admin` service account:
```bash
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep gitlab-admin | awk '{print $1}')
```
Copy the `<authentication_token>` value from the output:
```yaml
Name: gitlab-admin-token-b5zv4
Namespace: kube-system
Labels: <none>
Annotations: kubernetes.io/service-account.name=gitlab-admin
kubernetes.io/service-account.uid=bcfe66ac-39be-11e8-97e8-026dce96b6e8
Type: kubernetes.io/service-account-token
Data
====
ca.crt: 1025 bytes
namespace: 11 bytes
token: <authentication_token>
```
NOTE: **Note:**
For GKE clusters, you will need the
`container.clusterRoleBindings.create` permission to create a cluster
role binding. You can follow the [Google Cloud
documentation](https://cloud.google.com/iam/docs/granting-changing-revoking-access)
to grant access.
- **GitLab-managed cluster** - Leave this checked if you want GitLab to manage namespaces and service accounts for this cluster. See the [Managed clusters section](#gitlab-managed-clusters) for more information.
- **Project namespace** (optional) - You don't have to fill it in; by leaving
it blank, GitLab will create one for you. Also:
- Each project should have a unique namespace.
- The project namespace is not necessarily the namespace of the secret, if
you're using a secret with broader permissions, like the secret from `default`.
- You should **not** use `default` as the project namespace.
- If you or someone created a secret specifically for the project, usually
with limited permissions, the secret's namespace and project namespace may
be the same.
 
1. Finally, click the **Create Kubernetes cluster** button.
 
doc/user/project/clusters/serverless/index.md
+ 327
− 327
View file @ 74a8d300
This diff is collapsed.
doc/user/project/container_registry.md
+ 4
− 4
View file @ 74a8d300
@@ -241,10 +241,10 @@ The following installation instructions assume you are running Ubuntu:
Enter <kbd>CTRL</kbd>-<kbd>C</kbd> to quit.
1. Install the certificate from `~/.mitmproxy` to your system:
 
```sh
sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
sudo update-ca-certificates
```
```sh
sudo cp ~/.mitmproxy/mitmproxy-ca-cert.pem /usr/local/share/ca-certificates/mitmproxy-ca-cert.crt
sudo update-ca-certificates
```
 
If successful, the output should indicate that a certificate was added:
 
doc/user/project/deploy_boards.md
+ 7
− 7
View file @ 74a8d300
@@ -63,12 +63,12 @@ To display the Deploy Boards for a specific [environment] you should:
 
1. Have a Kubernetes cluster up and running.
 
NOTE: **Running on OpenShift:**
If you are using OpenShift, ensure that you're using the `Deployment` resource
instead of `DeploymentConfiguration`, otherwise the Deploy Boards won't render
correctly. For more information, read the
[OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab-ee/issues/4584).
NOTE: **Running on OpenShift:**
If you are using OpenShift, ensure that you're using the `Deployment` resource
instead of `DeploymentConfiguration`, otherwise the Deploy Boards won't render
correctly. For more information, read the
[OpenShift docs](https://docs.openshift.com/container-platform/3.7/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations)
and [GitLab issue #4584](https://gitlab.com/gitlab-org/gitlab-ee/issues/4584).
 
1. [Configure GitLab Runner][runners] with the [Docker][docker-exec] or
[Kubernetes][kube-exec] executor.
@@ -93,7 +93,7 @@ To display the Deploy Boards for a specific [environment] you should:
To migrate, please apply the required annotations (see above) and
re-deploy your application.
 
![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
![Deploy Boards Kubernetes Label](img/deploy_boards_kubernetes_label.png)
 
Once all of the above are set up and the pipeline has run at least once,
navigate to the environments page under **Operations > Environments**.
doc/user/project/deploy_tokens/index.md
+ 3
− 3
View file @ 74a8d300
@@ -56,9 +56,9 @@ To download a repository using a Deploy Token, you just need to:
1. Take note of your `username` and `token`.
1. `git clone` the project using the Deploy Token:
 
```sh
git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
```
```sh
git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
```
 
Replace `<username>` and `<deploy_token>` with the proper values.
 
doc/user/project/integrations/prometheus_library/kubernetes.md
+ 12
− 12
View file @ 74a8d300
@@ -13,15 +13,15 @@ integration services must be enabled.
 
- Average Memory Usage (MB):
 
```
avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
```
```
avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
```
 
- Average CPU Utilization (%):
 
```
avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
```
```
avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-([^c].*|c([^a]|a([^n]|n([^a]|a([^r]|r[^y])))).*|)-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
```
 
## Configuring Prometheus to monitor for Kubernetes metrics
 
@@ -48,12 +48,12 @@ These metrics expect the [Deployment](https://kubernetes.io/docs/concepts/worklo
 
- Average Memory Usage (MB)
 
```
avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
```
```
avg(sum(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) by (job)) without (job) / count(avg(container_memory_usage_bytes{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}) without (job)) /1024/1024
```
 
- Average CPU Utilization (%)
 
```
avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
```
```
avg(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (job)) without (job) / count(sum(rate(container_cpu_usage_seconds_total{container_name!="POD",pod_name=~"^%{ci_environment_slug}-canary-(.*)",namespace="%{kube_namespace}"}[15m])) by (pod_name))
```
doc/user/project/packages/maven_repository.md
+ 48
− 48
View file @ 74a8d300
@@ -198,7 +198,7 @@ domain name.
NOTE: **Note:**
For retrieving artifacts, you can use either the
[URL encoded](../../../api/README.md#namespaced-path-encoding) path of the group
(e.g., `group%2Fsubgroup`) or the group's ID (e.g., `12`).
(e.g., `group%2Fsubgroup`) or the group's ID (e.g., `12`).
 
### Instance level Maven endpoint
 
@@ -279,59 +279,59 @@ shows how to create a new package each time the `master` branch is updated:
Add the server section with the same id you defined in your `pom.xml` file.
For example, in our case it's `gitlab-maven`:
 
```xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
<servers>
<server>
<id>gitlab-maven</id>
<configuration>
<httpHeaders>
<property>
<name>Job-Token</name>
<value>${env.CI_JOB_TOKEN}</value>
</property>
</httpHeaders>
</configuration>
</server>
</servers>
</settings>
```
```xml
<settings xmlns="http://maven.apache.org/SETTINGS/1.1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd">
<servers>
<server>
<id>gitlab-maven</id>
<configuration>
<httpHeaders>
<property>
<name>Job-Token</name>
<value>${env.CI_JOB_TOKEN}</value>
</property>
</httpHeaders>
</configuration>
</server>
</servers>
</settings>
```
 
1. Make sure your `pom.xml` file includes the following:
 
```xml
<repositories>
<repository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
</repository>
</repositories>
<distributionManagement>
<repository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
</repository>
<snapshotRepository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
</snapshotRepository>
</distributionManagement>
```
TIP: **Tip:**
You can either let Maven utilize the CI environment variables or hardcode your project's ID.
```xml
<repositories>
<repository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
</repository>
</repositories>
<distributionManagement>
<repository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
</repository>
<snapshotRepository>
<id>gitlab-maven</id>
<url>https://gitlab.com/api/v4/projects/${env.CI_PROJECT_ID}/packages/maven</url>
</snapshotRepository>
</distributionManagement>
```
TIP: **Tip:**
You can either let Maven utilize the CI environment variables or hardcode your project's ID.
 
1. Add a `deploy` job to your `.gitlab-ci.yml` file:
 
```yaml
deploy:
image: maven:3.3.9-jdk-8
script:
- 'mvn deploy -s ci_settings.xml'
only:
- master
```
```yaml
deploy:
image: maven:3.3.9-jdk-8
script:
- 'mvn deploy -s ci_settings.xml'
only:
- master
```
 
1. Push those files to your repository.
 
doc/user/project/pages/lets_encrypt_for_gitlab_pages.md
+ 72
− 72
View file @ 74a8d300
@@ -36,111 +36,111 @@ operating systems the steps might be slightly different. Follow the
[CertBot instructions](https://certbot.eff.org/) according to your OS.
 
1. On your computer, open a terminal and navigate to your repository's
root directory:
root directory:
 
```bash
cd path/to/dir
```
```bash
cd path/to/dir
```
 
1. Install CertBot (the tool Let's Encrypt uses to issue certificates):
 
```bash
brew install certbot
```
```bash
brew install certbot
```
 
1. Request a certificate for your domain (`example.com`) and
provide an email account (`your@email.com`) to receive notifications:
provide an email account (`your@email.com`) to receive notifications:
 
```bash
sudo certbot certonly -a manual -d example.com --email your@email.com
```
```bash
sudo certbot certonly -a manual -d example.com --email your@email.com
```
 
Alternatively, you can register without adding an e-mail account,
but you won't be notified about the certificate expiration's date:
Alternatively, you can register without adding an e-mail account,
but you won't be notified about the certificate expiration's date:
 
```bash
sudo certbot certonly -a manual -d example.com --register-unsafely-without-email
```
```bash
sudo certbot certonly -a manual -d example.com --register-unsafely-without-email
```
 
TIP: **Tip:**
Read through CertBot's documentation on their
[command line options](https://certbot.eff.org/docs/using.html#certbot-command-line-options).
TIP: **Tip:**
Read through CertBot's documentation on their
[command line options](https://certbot.eff.org/docs/using.html#certbot-command-line-options).
 
1. You'll be prompted with a message to agree with their terms.
Press `A` to agree and `Y` to let they log your IP.
Press `A` to agree and `Y` to let they log your IP.
 
CertBot will then prompt you with the following message:
CertBot will then prompt you with the following message:
 
```bash
Create a file containing just this data:
```bash
Create a file containing just this data:
 
Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
 
And make it available on your web server at this URL:
And make it available on your web server at this URL:
 
http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP
http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP
 
Press Enter to Continue
```
Press Enter to Continue
```
 
1. **Do not press Enter yet.** Let's Encrypt will need to verify your
domain ownership before issuing the certificate. To do so, create 3
consecutive directories under your website's root:
`/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP/`
and add to the last folder an `index.html` file containing the content
referred on the previous prompt message:
```bash
Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
```
Note that this file needs to be accessed under
`http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP`
to allow Let's Encrypt to verify the ownership of your domain,
therefore, it needs to be part of the website content under the
repo's [`public`](index.md#how-it-works) folder.
domain ownership before issuing the certificate. To do so, create 3
consecutive directories under your website's root:
`/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP/`
and add to the last folder an `index.html` file containing the content
referred on the previous prompt message:
```bash
Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP.HUGNKk82jlsmOOfphlt8Jy69iuglsn095nxOMH9j3Yb
```
Note that this file needs to be accessed under
`http://example.com/.well-known/acme-challenge/Rxnv6WKo95hsuLVX3osmT6LgmzsJKSaK9htlPToohOP`
to allow Let's Encrypt to verify the ownership of your domain,
therefore, it needs to be part of the website content under the
repo's [`public`](index.md#how-it-works) folder.
 
1. Add, commit, and push the file into your repo in GitLab. Once the pipeline
passes, press **Enter** on your terminal to continue issuing your
certificate. CertBot will then prompt you with the following message:
```bash
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your cert will expire on 2019-03-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
```
passes, press **Enter** on your terminal to continue issuing your
certificate. CertBot will then prompt you with the following message:
```bash
Waiting for verification...
Cleaning up challenges
IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/example.com/privkey.pem
Your cert will expire on 2019-03-12. To obtain a new or tweaked
version of this certificate in the future, simply run certbot
again. To non-interactively renew *all* of your certificates, run
"certbot renew"
- If you like Certbot, please consider supporting our work by:
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
Donating to EFF: https://eff.org/donate-le
```
 
## Add your certificate to GitLab Pages
 
Now that your certificate has been issued, let's add it to your Pages site:
 
1. Back at GitLab, navigate to your project's **Settings > Pages**,
find your domain and click **Details** and **Edit** to add your certificate.
find your domain and click **Details** and **Edit** to add your certificate.
1. From your terminal, copy and paste the certificate into the first field
**Certificate (PEM)**:
**Certificate (PEM)**:
 
```bash
sudo cat /etc/letsencrypt/live/example.com/fullchain.pem | pbcopy
```
```bash
sudo cat /etc/letsencrypt/live/example.com/fullchain.pem | pbcopy
```
 
1. Copy and paste the private key into the second field **Key (PEM)**:
 
```bash
sudo cat /etc/letsencrypt/live/example.com/privkey.pem | pbcopy
```
```bash
sudo cat /etc/letsencrypt/live/example.com/privkey.pem | pbcopy
```
 
1. Click **Save changes** to apply them to your website.
1. Wait a few minutes for the configuration changes to take effect.
doc/user/project/repository/gpg_signed_commits/index.md
+ 78
− 77
View file @ 74a8d300
@@ -45,94 +45,95 @@ started:
1. Generate the private/public key pair with the following command, which will
spawn a series of questions:
 
```sh
gpg --full-gen-key
```
```sh
gpg --full-gen-key
```
 
NOTE: **Note:**
In some cases like Gpg4win on Windows and other macOS versions, the command
here may be `gpg --gen-key`.
NOTE: **Note:**
In some cases like Gpg4win on Windows and other macOS versions, the command
here may be `gpg --gen-key`.
 
1. The first question is which algorithm can be used. Select the kind you want
or press <kbd>Enter</kbd> to choose the default (RSA and RSA):
 
```
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
```
```
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
```
 
1. The next question is key length. We recommend to choose the highest value
which is `4096`:
 
```
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
```
```
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
```
1. Next, you need to specify the validity period of your key. This is something
subjective, and you can use the default value which is to never expire:
 
```
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
```
```
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Key does not expire at all
```
 
1. Confirm that the answers you gave were correct by typing `y`:
 
```
Is this correct? (y/N) y
```
```
Is this correct? (y/N) y
```
 
1. Enter you real name, the email address to be associated with this key (should
match a verified email address you use in GitLab) and an optional comment
(press <kbd>Enter</kbd> to skip):
 
```
GnuPG needs to construct a user ID to identify your key.
```
GnuPG needs to construct a user ID to identify your key.
 
Real name: Mr. Robot
Email address: <your_email>
Comment:
You selected this USER-ID:
"Mr. Robot <your_email>"
Real name: Mr. Robot
Email address: <your_email>
Comment:
You selected this USER-ID:
"Mr. Robot <your_email>"
 
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
```
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
```
 
1. Pick a strong password when asked and type it twice to confirm.
1. Use the following command to list the private GPG key you just created:
 
```
gpg --list-secret-keys --keyid-format LONG <your_email>
```
```
gpg --list-secret-keys --keyid-format LONG <your_email>
```
 
Replace `<your_email>` with the email address you entered above.
Replace `<your_email>` with the email address you entered above.
 
1. Copy the GPG key ID that starts with `sec`. In the following example, that's
`30F2B65B9246B6CA`:
 
```
sec rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
uid [ultimate] Mr. Robot <your_email>
ssb rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
```
```
sec rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
uid [ultimate] Mr. Robot <your_email>
ssb rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
```
 
1. Export the public key of that ID (replace your key ID from the previous step):
 
```
gpg --armor --export 30F2B65B9246B6CA
```
```
gpg --armor --export 30F2B65B9246B6CA
```
 
1. Finally, copy the public key and [add it in your profile settings](#adding-a-gpg-key-to-your-account)
 
@@ -146,17 +147,17 @@ You can add a GPG key in your profile's settings:
 
1. On the upper right corner, click on your avatar and go to your **Settings**.
 
![Settings dropdown](../../../profile/img/profile_settings_dropdown.png)
![Settings dropdown](../../../profile/img/profile_settings_dropdown.png)
 
1. Navigate to the **GPG keys** tab and paste your _public_ key in the 'Key'
box.
 
![Paste GPG public key](img/profile_settings_gpg_keys_paste_pub.png)
![Paste GPG public key](img/profile_settings_gpg_keys_paste_pub.png)
 
1. Finally, click on **Add key** to add it to GitLab. You will be able to see
its fingerprint, the corresponding email address and creation date.
 
![GPG key single page](img/profile_settings_gpg_keys_single_key.png)
![GPG key single page](img/profile_settings_gpg_keys_single_key.png)
 
## Associating your GPG key with Git
 
@@ -166,29 +167,29 @@ key to use.
 
1. Use the following command to list the private GPG key you just created:
 
```sh
gpg --list-secret-keys --keyid-format LONG <your_email>
```
```sh
gpg --list-secret-keys --keyid-format LONG <your_email>
```
 
Replace `<your_email>` with the email address you entered above.
Replace `<your_email>` with the email address you entered above.
 
1. Copy the GPG key ID that starts with `sec`. In the following example, that's
`30F2B65B9246B6CA`:
 
```
sec rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
uid [ultimate] Mr. Robot <your_email>
ssb rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
```
```
sec rsa4096/30F2B65B9246B6CA 2017-08-18 [SC]
D5E4F29F3275DC0CDA8FFC8730F2B65B9246B6CA
uid [ultimate] Mr. Robot <your_email>
ssb rsa4096/B7ABC0813E4028C0 2017-08-18 [E]
```
 
1. Tell Git to use that key to sign the commits:
 
```sh
git config --global user.signingkey 30F2B65B9246B6CA
```
```sh
git config --global user.signingkey 30F2B65B9246B6CA
```
 
Replace `30F2B65B9246B6CA` with your GPG key ID.
Replace `30F2B65B9246B6CA` with your GPG key ID.
 
1. (Optional) If Git is using `gpg` and you get errors like `secret key not available`
or `gpg: signing failed: secret key not available`, run the following command to
@@ -206,9 +207,9 @@ commits:
 
1. Commit like you used to, the only difference is the addition of the `-S` flag:
 
```
git commit -S -m "My commit msg"
```
```
git commit -S -m "My commit msg"
```
 
1. Enter the passphrase of your GPG key when asked.
1. Push to GitLab and check that your commits [are verified](#verifying-commits).
@@ -227,13 +228,13 @@ git config --global commit.gpgsign true
"Verified" or "Unverified", depending on the verification status of the GPG
signature.
 
![Signed and unsigned commits](img/project_signed_and_unsigned_commits.png)
![Signed and unsigned commits](img/project_signed_and_unsigned_commits.png)
 
1. By clicking on the GPG badge, details of the signature are displayed.
 
![Signed commit with verified signature](img/project_signed_commit_verified_signature.png)
![Signed commit with verified signature](img/project_signed_commit_verified_signature.png)
 
![Signed commit with verified signature](img/project_signed_commit_unverified_signature.png)
![Signed commit with verified signature](img/project_signed_commit_unverified_signature.png)
 
## Revoking a GPG key
 
doc/user/project/repository/reducing_the_repo_size_using_git.md
+ 41
− 41
View file @ 74a8d300
@@ -54,50 +54,50 @@ removed from the repository.
 
1. Navigate to your repository:
 
```
cd my_repository/
```
```
cd my_repository/
```
 
1. Change to the branch you want to remove the big file from:
 
```
git checkout master
```
```
git checkout master
```
 
1. Create a commit removing the large file from the branch, if it still exists:
 
```
git rm path/to/big_file.mpg
git commit -m 'Remove unneeded large file'
```
```
git rm path/to/big_file.mpg
git commit -m 'Remove unneeded large file'
```
 
1. Rewrite history:
 
```
bfg --delete-files path/to/big_file.mpg
```
```
bfg --delete-files path/to/big_file.mpg
```
 
An object map file will be written to `object-id-map.old-new.txt`. Keep it
around - you'll need it for the final step!
An object map file will be written to `object-id-map.old-new.txt`. Keep it
around - you'll need it for the final step!
 
1. Force-push the changes to GitLab:
 
```
git push --force-with-lease origin master
```
```
git push --force-with-lease origin master
```
 
If this step fails, someone has changed the `master` branch while you were
rewriting history. You could restore the branch and re-run BFG to preserve
their changes, or use `git push --force` to overwrite their changes.
If this step fails, someone has changed the `master` branch while you were
rewriting history. You could restore the branch and re-run BFG to preserve
their changes, or use `git push --force` to overwrite their changes.
 
1. Navigate to **Project > Settings > Repository > Repository Cleanup**:
 
![Repository settings cleanup form](img/repository_cleanup.png)
![Repository settings cleanup form](img/repository_cleanup.png)
 
Upload the `object-id-map.old-new.txt` file and press **Start cleanup**.
This will remove any internal git references to the old commits, and run
`git gc` against the repository. You will receive an email once it has
completed.
Upload the `object-id-map.old-new.txt` file and press **Start cleanup**.
This will remove any internal git references to the old commits, and run
`git gc` against the repository. You will receive an email once it has
completed.
 
NOTE: **Note:**
This process will remove some copies of the rewritten commits from GitLab's
@@ -110,32 +110,32 @@ purposes!
 
1. Navigate to your repository:
 
```
cd my_repository/
```
```
cd my_repository/
```
 
1. Change to the branch you want to remove the big file from:
 
```
git checkout master
```
```
git checkout master
```
 
1. Use `filter-branch` to remove the big file:
 
```
git filter-branch --force --tree-filter 'rm -f path/to/big_file.mpg' HEAD
```
```
git filter-branch --force --tree-filter 'rm -f path/to/big_file.mpg' HEAD
```
 
1. Instruct Git to purge the unwanted data:
 
```
git reflog expire --expire=now --all && git gc --prune=now --aggressive
```
```
git reflog expire --expire=now --all && git gc --prune=now --aggressive
```
 
1. Lastly, force push to the repository:
 
```
git push --force origin master
```
```
git push --force origin master
```
 
Your repository should now be below the size limit.
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