Add latest changes from gitlab-org/gitlab@master
|
|
@ -65,7 +65,7 @@ module Clusters
|
|||
end
|
||||
|
||||
def retry_command(command)
|
||||
"for i in $(seq 1 30); do #{command} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
|
||||
"for i in $(seq 1 30); do #{command} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)"
|
||||
end
|
||||
|
||||
def post_delete_script
|
||||
|
|
|
|||
|
|
@ -165,10 +165,32 @@ keys must be manually replicated to the **secondary** node.
|
|||
|
||||
### Step 3. Add the **secondary** node
|
||||
|
||||
1. SSH into your GitLab **secondary** server and login as root:
|
||||
|
||||
```sh
|
||||
sudo -i
|
||||
```
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node. You will need this in the next steps:
|
||||
|
||||
```ruby
|
||||
# The unique identifier for the Geo node.
|
||||
gitlab_rails['geo_node_name'] = '<node_name_here>'
|
||||
```
|
||||
|
||||
1. Reconfigure the **secondary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Visit the **primary** node's **Admin Area > Geo**
|
||||
(`/admin/geo/nodes`) in your browser.
|
||||
1. Add the **secondary** node by providing its full URL. **Do NOT** check the
|
||||
1. Click the **New node** button.
|
||||
1. Add the **secondary** node. Use the **exact** name you inputed for `gitlab_rails['geo_node_name']` as the Name and the full URL as the URL. **Do NOT** check the
|
||||
**This is a primary node** checkbox.
|
||||
|
||||

|
||||
1. Optionally, choose which groups or storage shards should be replicated by the
|
||||
**secondary** node. Leave blank to replicate all. Read more in
|
||||
[selective synchronization](#selective-synchronization).
|
||||
|
|
|
|||
|
|
@ -53,6 +53,19 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
|
|||
sudo -i
|
||||
```
|
||||
|
||||
1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node:
|
||||
|
||||
```ruby
|
||||
# The unique identifier for the Geo node.
|
||||
gitlab_rails['geo_node_name'] = '<node_name_here>'
|
||||
```
|
||||
|
||||
1. Reconfigure the **primary** node for the change to take effect:
|
||||
|
||||
```sh
|
||||
gitlab-ctl reconfigure
|
||||
```
|
||||
|
||||
1. Execute the command below to define the node as **primary** node:
|
||||
|
||||
```sh
|
||||
|
|
|
|||
|
|
@ -56,6 +56,11 @@ The following steps enable a GitLab cluster to serve as the **primary** node.
|
|||
##
|
||||
roles ['geo_primary_role']
|
||||
|
||||
##
|
||||
## The unique identifier for the Geo node.
|
||||
##
|
||||
gitlab_rails['geo_node_name'] = '<node_name_here>'
|
||||
|
||||
##
|
||||
## Disable automatic migrations
|
||||
##
|
||||
|
|
@ -229,6 +234,11 @@ following modifications:
|
|||
##
|
||||
roles ['geo_secondary_role', 'application_role']
|
||||
|
||||
##
|
||||
## The unique identifier for the Geo node.
|
||||
##
|
||||
gitlab_rails['geo_node_name'] = '<node_name_here>'
|
||||
|
||||
##
|
||||
## Disable automatic migrations
|
||||
##
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 86 KiB |
|
|
@ -0,0 +1,101 @@
|
|||
---
|
||||
type: howto
|
||||
---
|
||||
|
||||
# Using the Libravatar service with GitLab
|
||||
|
||||
GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
|
||||
|
||||
Libravatar is another service that delivers your avatar (profile picture) to
|
||||
other websites. The Libravatar API is
|
||||
[heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
|
||||
easily switch to the Libravatar avatar service or even a self-hosted Libravatar
|
||||
server.
|
||||
|
||||
## Configuration
|
||||
|
||||
In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
|
||||
the configuration options as follows:
|
||||
|
||||
### For HTTP
|
||||
|
||||
```yml
|
||||
gravatar:
|
||||
enabled: true
|
||||
# gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
|
||||
plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
### For HTTPS
|
||||
|
||||
```yml
|
||||
gravatar:
|
||||
enabled: true
|
||||
# gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
|
||||
ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
### Self-hosted Libravatar server
|
||||
|
||||
If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
|
||||
the URL will be different in the configuration, but you must provide the same
|
||||
placeholders so GitLab can parse the URL correctly.
|
||||
|
||||
For example, you host a service on `http://libravatar.example.com` and the
|
||||
`plain_url` you need to supply in `gitlab.yml` is
|
||||
|
||||
`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
|
||||
|
||||
### Omnibus GitLab example
|
||||
|
||||
In `/etc/gitlab/gitlab.rb`:
|
||||
|
||||
#### For HTTP
|
||||
|
||||
```ruby
|
||||
gitlab_rails['gravatar_enabled'] = true
|
||||
gitlab_rails['gravatar_plain_url'] = "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
#### For HTTPS
|
||||
|
||||
```ruby
|
||||
gitlab_rails['gravatar_enabled'] = true
|
||||
gitlab_rails['gravatar_ssl_url'] = "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
|
||||
|
||||
## Default URL for missing images
|
||||
|
||||
[Libravatar supports different sets](https://wiki.libravatar.org/api/) of
|
||||
missing images for user email addresses that are not found on the Libravatar
|
||||
service.
|
||||
|
||||
In order to use a set other than `identicon`, replace the `&d=identicon`
|
||||
portion of the URL with another supported set.
|
||||
For example, you can use the `retro` set, in which case the URL would look like:
|
||||
`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
|
||||
|
||||
## Usage examples for Microsoft Office 365
|
||||
|
||||
If your users are Office 365 users, the `GetPersonaPhoto` service can be used.
|
||||
Note that this service requires a login, so this use case is most useful in a
|
||||
corporate installation where all users have access to Office 365.
|
||||
|
||||
```ruby
|
||||
gitlab_rails['gravatar_plain_url'] = 'http://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
|
||||
gitlab_rails['gravatar_ssl_url'] = 'https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
|
||||
```
|
||||
|
||||
<!-- ## 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,38 +1,5 @@
|
|||
---
|
||||
type: howto
|
||||
redirect_to: '../user/admin_area/appearance.md#sign-in--sign-up-pages'
|
||||
---
|
||||
|
||||
# Changing the logo and description on the login page
|
||||
|
||||
You can customize the login page of your GitLab server to show the logo and
|
||||
description of your organization.
|
||||
|
||||
By default, the page shows the GitLab logo and description:
|
||||
|
||||

|
||||
|
||||
To customize the login page:
|
||||
|
||||
1. Navigate to the **Admin** area and go to the **Appearance** page.
|
||||
1. Fill in your desired Title and Description. You can also choose an image file
|
||||
of the logo for your organization.
|
||||
|
||||

|
||||
|
||||
1. Save your changes.
|
||||
|
||||
Your GitLab login page will display the details you provided:
|
||||
|
||||

|
||||
|
||||
<!-- ## 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. -->
|
||||
This document was moved to [another location](../user/admin_area/appearance.md#sign-in--sign-up-pages).
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 83 KiB |
|
Before Width: | Height: | Size: 77 KiB |
|
Before Width: | Height: | Size: 71 KiB |
|
|
@ -1,37 +1,5 @@
|
|||
---
|
||||
type: howto
|
||||
redirect_to: '../user/admin_area/appearance.md#navigation-bar'
|
||||
---
|
||||
|
||||
# Changing the navigation bar and email header logo
|
||||
|
||||
You can customize the logo that appears in email headers and in the navigation
|
||||
bar on pages that are displayed by your GitLab server.
|
||||
|
||||
1. Navigate to the **Admin** area and go to the **Appearance** page, then locate
|
||||
the **Navigation bar** section.
|
||||
1. For the **Header Logo**, choose an image file of the logo for your
|
||||
organization.
|
||||
|
||||

|
||||
|
||||
1. Save your changes.
|
||||
|
||||
Your GitLab navigation bar will display the custom logo:
|
||||
|
||||

|
||||
|
||||
The GitLab pipeline emails will also display the custom logo:
|
||||
|
||||

|
||||
|
||||
<!-- ## 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. -->
|
||||
This document was moved to [another location](../user/admin_area/appearance.md#navigation-bar).
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 5.5 KiB |
|
Before Width: | Height: | Size: 5.2 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
|
@ -1,37 +1,5 @@
|
|||
---
|
||||
type: howto
|
||||
redirect_to: '../user/admin_area/appearance.md#favicon'
|
||||
---
|
||||
|
||||
# Changing the favicon
|
||||
|
||||
> [Introduced][ce-14497] in GitLab 11.0.
|
||||
|
||||
[ce-14497]: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14497
|
||||
|
||||
You can customize the favicon (the icon displayed in your web browser's
|
||||
address bar and web page tabs) for your GitLab server.
|
||||
|
||||
1. Navigate to the **Admin** area and go to the **Appearance** page, then
|
||||
locate the **Favicon** section.
|
||||
1. Upload an image file of your favicon.
|
||||
|
||||

|
||||
|
||||
1. Save your changes.
|
||||
|
||||
Your new favicon will display in the browser. The main favicon and the CI
|
||||
status icons will show the custom icon:
|
||||
|
||||

|
||||
|
||||
<!-- ## 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. -->
|
||||
This document was moved to [another location](../user/admin_area/appearance.md#favicon).
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 28 KiB |
|
Before Width: | Height: | Size: 31 KiB |
|
|
@ -1,36 +1,5 @@
|
|||
---
|
||||
type: howto
|
||||
redirect_to: '../user/admin_area/settings/help_page.md'
|
||||
---
|
||||
|
||||
# Customizing the 'Help' and login page messages
|
||||
|
||||
In large organizations, it is useful to have information about who maintains
|
||||
the company GitLab server. You can customize and display this information on
|
||||
the GitLab login page and on the GitLab server's `/help` page.
|
||||
|
||||
1. Navigate to the **Admin** area, then click on **Preferences** and expand
|
||||
**Help page**.
|
||||
1. Under **Help page text**, fill in the required information about the
|
||||
person(s) administering GitLab. This text can also contain any other
|
||||
information that you wish to display to users.
|
||||
|
||||

|
||||
|
||||
1. Save your changes.
|
||||
|
||||
The information you entered will be shown on the GitLab login page and on the
|
||||
GitLab `/help` page (e.g., <https://gitlab.com/help>).
|
||||
|
||||

|
||||
|
||||
<!-- ## 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. -->
|
||||
This document was moved to [another location](../user/admin_area/settings/help_page.md).
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 38 KiB |
|
Before Width: | Height: | Size: 24 KiB |
|
|
@ -1,18 +1,5 @@
|
|||
---
|
||||
type: index
|
||||
description: Learn how to customize GitLab's appearance for self-managed installations.
|
||||
redirect_to: '../user/admin_area/appearance.md'
|
||||
---
|
||||
|
||||
# Customizing GitLab's appearance **(CORE ONLY)**
|
||||
|
||||
For GitLab self-managed instances, you can customize the page logo,
|
||||
email headers, favicon, and several other aspects of GitLab's appearance.
|
||||
|
||||
The following pages explain how to customize the appearance of your instance:
|
||||
|
||||
- [Changing the logo and description on the login page](branded_login_page.md)
|
||||
- [Changing the navigation bar and email header logo](branded_page_and_email_header.md)
|
||||
- [Changing the favicon](favicon.md)
|
||||
- [Customizing the new project page](new_project_page.md)
|
||||
- [Customizing the `/help` and login page messages](help_message.md)
|
||||
- [Using the Libravatar service with GitLab](libravatar.md)
|
||||
This document was moved to [another location](../user/admin_area/appearance.md).
|
||||
|
|
|
|||
|
|
@ -1,101 +1,5 @@
|
|||
---
|
||||
type: howto
|
||||
redirect_to: '../administration/libravatar.md'
|
||||
---
|
||||
|
||||
# Using the Libravatar service with GitLab
|
||||
|
||||
GitLab by default supports the [Gravatar](https://gravatar.com) avatar service.
|
||||
|
||||
Libravatar is another service that delivers your avatar (profile picture) to
|
||||
other websites. The Libravatar API is
|
||||
[heavily based on gravatar](https://wiki.libravatar.org/api/), so you can
|
||||
easily switch to the Libravatar avatar service or even a self-hosted Libravatar
|
||||
server.
|
||||
|
||||
## Configuration
|
||||
|
||||
In the [`gitlab.yml` gravatar section](https://gitlab.com/gitlab-org/gitlab/blob/672bd3902d86b78d730cea809fce312ec49d39d7/config/gitlab.yml.example#L122), set
|
||||
the configuration options as follows:
|
||||
|
||||
### For HTTP
|
||||
|
||||
```yml
|
||||
gravatar:
|
||||
enabled: true
|
||||
# gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
|
||||
plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
### For HTTPS
|
||||
|
||||
```yml
|
||||
gravatar:
|
||||
enabled: true
|
||||
# gravatar URLs: possible placeholders: %{hash} %{size} %{email} %{username}
|
||||
ssl_url: "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
### Self-hosted Libravatar server
|
||||
|
||||
If you are [running your own libravatar service](https://wiki.libravatar.org/running_your_own/),
|
||||
the URL will be different in the configuration, but you must provide the same
|
||||
placeholders so GitLab can parse the URL correctly.
|
||||
|
||||
For example, you host a service on `http://libravatar.example.com` and the
|
||||
`plain_url` you need to supply in `gitlab.yml` is
|
||||
|
||||
`http://libravatar.example.com/avatar/%{hash}?s=%{size}&d=identicon`
|
||||
|
||||
### Omnibus GitLab example
|
||||
|
||||
In `/etc/gitlab/gitlab.rb`:
|
||||
|
||||
#### For HTTP
|
||||
|
||||
```ruby
|
||||
gitlab_rails['gravatar_enabled'] = true
|
||||
gitlab_rails['gravatar_plain_url'] = "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
#### For HTTPS
|
||||
|
||||
```ruby
|
||||
gitlab_rails['gravatar_enabled'] = true
|
||||
gitlab_rails['gravatar_ssl_url'] = "https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
|
||||
```
|
||||
|
||||
Then run `sudo gitlab-ctl reconfigure` for the changes to take effect.
|
||||
|
||||
## Default URL for missing images
|
||||
|
||||
[Libravatar supports different sets](https://wiki.libravatar.org/api/) of
|
||||
missing images for user email addresses that are not found on the Libravatar
|
||||
service.
|
||||
|
||||
In order to use a set other than `identicon`, replace the `&d=identicon`
|
||||
portion of the URL with another supported set.
|
||||
For example, you can use the `retro` set, in which case the URL would look like:
|
||||
`plain_url: "http://cdn.libravatar.org/avatar/%{hash}?s=%{size}&d=retro"`
|
||||
|
||||
## Usage examples for Microsoft Office 365
|
||||
|
||||
If your users are Office 365 users, the `GetPersonaPhoto` service can be used.
|
||||
Note that this service requires a login, so this use case is most useful in a
|
||||
corporate installation where all users have access to Office 365.
|
||||
|
||||
```ruby
|
||||
gitlab_rails['gravatar_plain_url'] = 'http://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
|
||||
gitlab_rails['gravatar_ssl_url'] = 'https://outlook.office365.com/owa/service.svc/s/GetPersonaPhoto?email=%{email}&size=HR120x120'
|
||||
```
|
||||
|
||||
<!-- ## 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. -->
|
||||
This document was moved to [another location](../administration/libravatar.md).
|
||||
|
|
|
|||
|
|
@ -1,38 +1,5 @@
|
|||
---
|
||||
type: howto
|
||||
redirect_to: '../user/admin_area/appearance.md#new-project-pages'
|
||||
---
|
||||
|
||||
# Customizing the new project page
|
||||
|
||||
You can add a markdown-formatted message to your GitLab new project page.
|
||||
|
||||
By default, the new project page shows a sidebar with general information:
|
||||
|
||||

|
||||
|
||||
To customize the information in the sidebar:
|
||||
|
||||
1. Navigate to the **Admin** area and go to the **Appearance** page, then
|
||||
locate the **New project pages** section.
|
||||
1. Fill in your new project project guidelines:
|
||||
|
||||

|
||||
|
||||
1. Save the page.
|
||||
|
||||
Your new project page will show the customized guidelines in the sidebar, below
|
||||
the general information:
|
||||
|
||||

|
||||
|
||||
<!-- ## 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. -->
|
||||
This document was moved to [another location](../user/admin_area/appearance.md#new-project-pages).
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 68 KiB |
|
Before Width: | Height: | Size: 61 KiB |
|
|
@ -1,23 +1,5 @@
|
|||
# Adding a system message to every page
|
||||
---
|
||||
redirect_to: '../user/admin_area/appearance.md#system-header-and-footer-messages'
|
||||
---
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
|
||||
> [Added](https://gitlab.com/gitlab-org/gitlab-foss/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
|
||||
|
||||
Navigate to the **Admin** area and go to the **Appearance** page.
|
||||
|
||||
Under **System header and footer** insert your header message and/or footer message.
|
||||
Both background and font color of the header and footer are customizable.
|
||||
|
||||
You can also apply the header and footer messages to GitLab emails,
|
||||
by checking the **Enable header and footer in emails** checkbox.
|
||||
Note that color settings will only be applied within the app interface and not to emails
|
||||
|
||||

|
||||
|
||||
After saving, all pages within GitLab will contain the custom system header and/or footer messages:
|
||||
|
||||

|
||||
|
||||
The GitLab sign in page will also show the header and the footer messages:
|
||||
|
||||

|
||||
This document was moved to [another location](../user/admin_area/appearance.md#system-header-and-footer-messages).
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 32 KiB |
|
Before Width: | Height: | Size: 114 KiB |
|
Before Width: | Height: | Size: 77 KiB |
|
After Width: | Height: | Size: 151 KiB |
|
Before Width: | Height: | Size: 7.7 KiB |
|
Before Width: | Height: | Size: 28 KiB |
|
After Width: | Height: | Size: 440 KiB |
|
Before Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 165 KiB |
|
Before Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 162 KiB |
|
Before Width: | Height: | Size: 8.2 KiB |
|
Before Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 223 KiB |
|
After Width: | Height: | Size: 97 KiB |
|
Before Width: | Height: | Size: 10 KiB |
|
After Width: | Height: | Size: 96 KiB |
|
Before Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 358 KiB |
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 136 KiB |
|
Before Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 212 KiB |
|
Before Width: | Height: | Size: 30 KiB |
|
Before Width: | Height: | Size: 25 KiB |
|
After Width: | Height: | Size: 266 KiB |
|
After Width: | Height: | Size: 305 KiB |
|
Before Width: | Height: | Size: 12 KiB |
|
After Width: | Height: | Size: 132 KiB |
|
Before Width: | Height: | Size: 19 KiB |
|
After Width: | Height: | Size: 231 KiB |
|
Before Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 166 KiB |
|
|
@ -35,16 +35,16 @@ those projects provide a barebones application built on some well-known framewor
|
|||
1. In GitLab, click the plus icon (**+**) at the top of the navigation bar and select
|
||||
**New project**.
|
||||
1. Go to the **Create from template** tab where you can choose among a Ruby on
|
||||
Rails, Spring, or NodeJS Express project. For this example,
|
||||
we'll use the Ruby on Rails template.
|
||||
Rails, Spring, or NodeJS Express project.
|
||||
We'll use the Ruby on Rails template.
|
||||
|
||||

|
||||

|
||||
|
||||
1. Give your project a name, optionally a description, and make it public so that
|
||||
you can take advantage of the features available in the
|
||||
[GitLab Gold plan](https://about.gitlab.com/pricing/#gitlab-com).
|
||||
|
||||

|
||||

|
||||
|
||||
1. Click **Create project**.
|
||||
|
||||
|
|
@ -56,37 +56,30 @@ under which this application will be deployed.
|
|||
1. On the project's landing page, click the button labeled **Add Kubernetes cluster**
|
||||
(note that this option is also available when you navigate to **Operations > Kubernetes**).
|
||||
|
||||

|
||||

|
||||
|
||||
1. Choose **Create on Google Kubernetes Engine**.
|
||||
1. One the **Create new cluster on GKE** tab, click "Sign in with Google".
|
||||
|
||||

|
||||
|
||||
1. Sign in with Google.
|
||||
|
||||

|
||||

|
||||
|
||||
1. Connect with your Google account and press **Allow** when asked (this will
|
||||
be shown only the first time you connect GitLab with your Google account).
|
||||
|
||||

|
||||

|
||||
|
||||
1. The last step is to fill in the cluster details. Give it a name, leave the
|
||||
1. The last step is to provide the cluster details. Give it a name, leave the
|
||||
environment scope as is, and choose the GCP project under which the cluster
|
||||
will be created. (Per the instructions when you
|
||||
[configured your Google account](#configuring-your-google-account), a project
|
||||
should have already been created for you.) Next, choose the
|
||||
[region/zone](https://cloud.google.com/compute/docs/regions-zones/) under which the
|
||||
cluster will be created, enter the number of nodes you want it to have, and
|
||||
finally choose their [machine type](https://cloud.google.com/compute/docs/machine-types).
|
||||
finally choose the [machine type](https://cloud.google.com/compute/docs/machine-types).
|
||||
|
||||

|
||||

|
||||
|
||||
1. Once ready, click **Create Kubernetes cluster**.
|
||||
|
||||
NOTE: **Note:**
|
||||
Do not select `f1-micro` from the **Machine type** dropdown. `f1-micro` machines cannot support a full GitLab installation.
|
||||
|
||||
After a couple of minutes, the cluster will be created. You can also see its
|
||||
status on your [GCP dashboard](https://console.cloud.google.com/kubernetes).
|
||||
|
||||
|
|
@ -99,7 +92,7 @@ GitLab's Kubernetes integration comes with some
|
|||
[pre-defined applications](../../user/project/clusters/index.md#installing-applications)
|
||||
for you to install.
|
||||
|
||||

|
||||

|
||||
|
||||
The first one to install is Helm Tiller, a package manager for Kubernetes, which
|
||||
is needed in order to install the rest of the applications. Go ahead and click
|
||||
|
|
@ -113,32 +106,31 @@ use to supervise the deployed application. We will not install GitLab Runner as
|
|||
we'll use the shared Runners that GitLab.com provides.
|
||||
|
||||
After the Ingress is installed, wait a few seconds and copy the IP address that
|
||||
is displayed, which we'll use in the next step when enabling Auto DevOps.
|
||||
is displayed in order to add in your base **Domain** at the top of the page. For
|
||||
the purpose of this guide, we will use the one suggested by GitLab. Once you have
|
||||
filled in the domain, click **Save changes**.
|
||||
|
||||
## Enabling Auto DevOps
|
||||

|
||||
|
||||
Now that the Kubernetes cluster is set up and ready, let's enable Auto DevOps.
|
||||
## Enabling Auto DevOps (optional)
|
||||
|
||||
Starting with GitLab 11.3, Auto DevOps is enabled by default. However, it is possible to disable
|
||||
Auto DevOps at both the instance-level (for self-managed instances) and also at the group-level.
|
||||
Follow these steps if Auto DevOps has been manually disabled.
|
||||
|
||||
1. First, navigate to **Settings > CI/CD > Auto DevOps**.
|
||||
1. Select **Enable Auto DevOps**.
|
||||
1. Add in your base **Domain** by using the one GitLab suggests. Note that
|
||||
generally, you would associate the IP address with a domain name on your
|
||||
registrar's settings. In this case, for the sake of the guide, we will use
|
||||
an alternative DNS that will map any domain name of the scheme
|
||||
`anything.ip_address.nip.io` to the corresponding `ip_address`. For example,
|
||||
if the IP address of the Ingress is `1.2.3.4`, the domain name to fill in
|
||||
would be `1.2.3.4.nip.io`.
|
||||
1. Select **Default to Auto DevOps pipeline**.
|
||||
1. Lastly, let's select the [continuous deployment strategy](index.md#deployment-strategy)
|
||||
which will automatically deploy the application to production once the pipeline
|
||||
successfully runs on the `master` branch.
|
||||
1. Click **Save changes**.
|
||||
|
||||

|
||||

|
||||
|
||||
Once you complete all the above and save your changes, a new pipeline is
|
||||
automatically created. To view the pipeline, go to **CI/CD > Pipelines**.
|
||||
|
||||

|
||||

|
||||
|
||||
In the next section we'll break down the pipeline and explain what each job does.
|
||||
|
||||
|
|
@ -149,7 +141,7 @@ By now you should see the pipeline running, but what is it running exactly?
|
|||
To navigate inside the pipeline, click its status badge. (Its status should be "running").
|
||||
The pipeline is split into 4 stages, each running a couple of jobs.
|
||||
|
||||

|
||||

|
||||
|
||||
In the **build** stage, the application is built into a Docker image and then
|
||||
uploaded to your project's [Container Registry](../../user/packages/container_registry/index.md) ([Auto Build](index.md#auto-build)).
|
||||
|
|
@ -190,7 +182,7 @@ page where you can also monitor your application. Let's explore that.
|
|||
Now that the application is successfully deployed, let's navigate to its
|
||||
website. First, go to **Operations > Environments**.
|
||||
|
||||

|
||||

|
||||
|
||||
In **Environments** you can see some details about the deployed
|
||||
applications. In the rightmost column for the production environment, you can make use of the three icons:
|
||||
|
|
@ -201,7 +193,7 @@ applications. In the rightmost column for the production environment, you can ma
|
|||
Prometheus collects data about the Kubernetes cluster and how the application
|
||||
affects it (in terms of memory/CPU usage, latency, etc.).
|
||||
|
||||

|
||||

|
||||
|
||||
- The third icon is the [web terminal](../../ci/environments.md#web-terminals)
|
||||
and it will open a terminal session right inside the container where the
|
||||
|
|
@ -235,13 +227,13 @@ you're on the Web IDE, make the following change:
|
|||
Stage the file, add a commit message, and create a new branch and a merge request
|
||||
by clicking **Commit**.
|
||||
|
||||

|
||||

|
||||
|
||||
Once you submit the merge request, you'll see the pipeline running. This will
|
||||
run all the jobs as [described previously](#deploying-the-application), as well as
|
||||
a few more that run only on branches other than `master`.
|
||||
|
||||

|
||||

|
||||
|
||||
After a few minutes you'll notice that there was a failure in a test.
|
||||
This means there's a test that was 'broken' by our change.
|
||||
|
|
@ -259,7 +251,7 @@ bin/rails test test/controllers/welcome_controller_test.rb:4
|
|||
|
||||
Let's fix that:
|
||||
|
||||
1. Back to the merge request, click the **Web IDE** button.
|
||||
1. Back to the merge request, click the **Open in Web IDE** button.
|
||||
1. Find the `test/controllers/welcome_controller_test.rb` file and open it.
|
||||
1. Change line 7 to say `You're on Rails! Powered by GitLab Auto DevOps.`
|
||||
1. Click **Commit**.
|
||||
|
|
@ -269,10 +261,10 @@ Let's fix that:
|
|||
|
||||
Now, if you go back to the merge request you should not only see the test passing, but
|
||||
also the application deployed as a [review app](index.md#auto-review-apps). You
|
||||
can visit it by following the URL in the merge request. The changes that we
|
||||
previously made should be there.
|
||||
can visit it by following clicking the **View app** button. You will see
|
||||
the changes that we previously made.
|
||||
|
||||

|
||||

|
||||
|
||||
Once you merge the merge request, the pipeline will run on the `master` branch,
|
||||
and the application will be eventually deployed straight to production.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
type: howto
|
||||
disqus_identifier: 'https://docs.gitlab.com/ee/customization/branded_login_page.html'
|
||||
---
|
||||
|
||||
# GitLab Appearance **(CORE ONLY)**
|
||||
|
||||
There are several options for customizing the appearance of a self hosted instance
|
||||
of GitLab. These settings are accessed from the **Admin Area** in the **Appearance**
|
||||
section.
|
||||
|
||||
## Navigation bar
|
||||
|
||||
By default, the navigation bar has the GitLab logo, but this can be customized with
|
||||
any image desired. It is optimized for images 28px high (any width), but any image can be
|
||||
used (less than 1MB) and it will automatically be resized.
|
||||
|
||||

|
||||
|
||||
Once you select and upload an image, click **Update appearance settings** at the bottom
|
||||
of the page to activate it in the GitLab instance.
|
||||
|
||||
NOTE: **Note:**
|
||||
GitLab pipeline emails will also display the custom logo.
|
||||
|
||||
## Favicon
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/14497) in GitLab 11.0.
|
||||
|
||||
By default, the favicon (used by the browser as the tab icon, as well as the CI status icon)
|
||||
uses the GitLab logo, but this can be customized with any icon desired. It must be a
|
||||
32x32 `.png` or `.ico` image.
|
||||
|
||||

|
||||
|
||||
After you select and upload an icon, click **Update appearance settings** at the bottom
|
||||
of the page to activate it in the GitLab instance.
|
||||
|
||||
## System header and footer messages
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/5023) in [GitLab Premium](https://about.gitlab.com/pricing/) 10.7.
|
||||
> - [Added](https://gitlab.com/gitlab-org/gitlab-foss/issues/55057) to [GitLab Core](https://about.gitlab.com/pricing/) in 11.9.
|
||||
|
||||
You can add a small header message, a small footer message, or both, to the interface
|
||||
of your GitLab instance. These messages will appear on all projects and pages of the
|
||||
instance, including the sign in / sign up page. The default color is white text on
|
||||
an orange background, but this can be customized by clicking on **Customize colors**.
|
||||
|
||||
Limited [markdown](../markdown.md) is supported, such as bold, italics, and links, for
|
||||
example. Other markdown features, including lists, images and quotes, are not supported,
|
||||
as the header and footer messages can only be a single line.
|
||||
|
||||

|
||||
|
||||
If desired, you can select **Enable header and footer in emails** to have the text of
|
||||
the header and footer added to all emails sent by the GitLab instance.
|
||||
|
||||
After you add a message, click **Update appearance settings** at the bottom of the page
|
||||
to activate it in the GitLab instance.
|
||||
|
||||
## Sign in / Sign up pages
|
||||
|
||||
You can replace the default message on the sign in / sign up page with your own message
|
||||
and logo. You can make full use of [markdown](../markdown.md) in the description:
|
||||
|
||||

|
||||
|
||||
The optimal size for the logo is 640x360px, but any image can be used (below 1MB)
|
||||
and it will be resized automatically. The logo image will appear between the title and
|
||||
the description, on the left of the sign-up page.
|
||||
|
||||

|
||||
|
||||
After you add a message, click **Update appearance settings** at the bottom of the page
|
||||
to activate it in the GitLab instance. You can also click on the **Sign-in page** button,
|
||||
to review the saved appearance settings:
|
||||
|
||||
NOTE: **Note:**
|
||||
You can add also add a [customized help message](settings/help_page.md) below the sign in message.
|
||||
|
||||
## New project pages
|
||||
|
||||
You can add a new project guidelines message to the **New project page** within GitLab.
|
||||
You can make full use of [markdown](../markdown.md) in the description:
|
||||
|
||||

|
||||
|
||||
The message will be displayed below the **New Project** message, on the left side
|
||||
of the **New project page**.
|
||||
|
||||
After you add a message, click **Update appearance settings** at the bottom of the page
|
||||
to activate it in the GitLab instance. You can also click on the **New project page**
|
||||
button, which will bring you to the new project page so you can review the change.
|
||||
|
||||

|
||||
|
||||
## Libravatar
|
||||
|
||||
[Libravatar](https://www.libravatar.org) is supported by GitLab for avatar images, but you must
|
||||
[manually enable Libravatar support on the GitLab instance](../../administration/libravatar.md)
|
||||
in order to use the service.
|
||||
|
||||
<!-- ## 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. -->
|
||||
|
After Width: | Height: | Size: 228 KiB |
|
After Width: | Height: | Size: 235 KiB |
|
After Width: | Height: | Size: 164 KiB |
|
After Width: | Height: | Size: 465 KiB |
|
After Width: | Height: | Size: 216 KiB |
|
After Width: | Height: | Size: 1.0 MiB |
|
After Width: | Height: | Size: 838 KiB |
|
|
@ -32,7 +32,7 @@ The Admin Area is made up of the following sections:
|
|||
| Deploy Keys | Create instance-wide [SSH deploy keys](../../ssh/README.md#deploy-keys). |
|
||||
| Service Templates | Create [service templates](../project/integrations/services_templates.md) for projects. |
|
||||
| Labels | Create and maintain [labels](labels.md) for your GitLab instance. |
|
||||
| Appearance | Customize [GitLab's appearance](../../customization/index.md). |
|
||||
| Appearance | Customize [GitLab's appearance](appearance.md). |
|
||||
| Settings | Modify the [settings](settings/index.md) for your GitLab instance. |
|
||||
|
||||
## Admin Dashboard
|
||||
|
|
|
|||
|
|
@ -0,0 +1,49 @@
|
|||
---
|
||||
type: howto
|
||||
---
|
||||
|
||||
# Customizing the 'Help' and login page messages
|
||||
|
||||
In large organizations, it is useful to have information about who to contact or where
|
||||
to go for help. You can customize and display this information on the GitLab server's
|
||||
`/help` page and on the GitLab login page.
|
||||
|
||||
## Adding a help message to the help page
|
||||
|
||||
You can add a help message, which will be shown on the GitLab `/help` page (e.g.,
|
||||
<https://gitlab.com/help>) in a new section at the top of the `/help` page:
|
||||
|
||||
1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
|
||||
1. Under **Help page text**, fill in the information you wish to display on `/help`.
|
||||
|
||||

|
||||
|
||||
1. Save your changes. You can now see the message on `/help`.
|
||||
|
||||

|
||||
|
||||
## Adding a help message to the login page **(STARTER)**
|
||||
|
||||
You can add a help message, which will be shown on the GitLab login page in a new section
|
||||
titled `Need Help?`, located below the login page message:
|
||||
|
||||
1. Navigate to **Admin area > Settings > Preferences**, then expand **Help page**.
|
||||
1. Under **Help text**, fill in the information you wish to display on the login page.
|
||||
|
||||

|
||||
|
||||
1. Save your changes.
|
||||
|
||||

|
||||
|
||||
<!-- ## 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. -->
|
||||
|
After Width: | Height: | Size: 296 KiB |
|
After Width: | Height: | Size: 89 KiB |
|
After Width: | Height: | Size: 147 KiB |
|
After Width: | Height: | Size: 67 KiB |
|
|
@ -21,6 +21,7 @@ include:
|
|||
- [User and IP rate limits](user_and_ip_rate_limits.md)
|
||||
- [Custom templates repository](instance_template_repository.md) **(PREMIUM)**
|
||||
- [Protected paths](protected_paths.md) **(CORE ONLY)**
|
||||
- [Help messages for the `/help` page and the login page](help_page.md)
|
||||
|
||||
NOTE: **Note:**
|
||||
You can change the [first day of the week](../../profile/preferences.md) for the entire GitLab instance
|
||||
|
|
|
|||
|
|
@ -17,7 +17,8 @@ module Gitlab
|
|||
# This is necessary to give Tiller time to restart after upgrade.
|
||||
# Ideally we'd be able to use --wait but cannot because of
|
||||
# https://github.com/helm/helm/issues/4855
|
||||
"for i in $(seq 1 30); do #{helm_check} && break; sleep 1s; echo \"Retrying ($i)...\"; false; done"
|
||||
|
||||
"for i in $(seq 1 30); do #{helm_check} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)"
|
||||
end
|
||||
|
||||
def repository_command
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ describe Gitlab::Kubernetes::Helm::DeleteCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm delete --purge app-name
|
||||
EOS
|
||||
end
|
||||
|
|
@ -36,7 +36,7 @@ describe Gitlab::Kubernetes::Helm::DeleteCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
#{helm_delete_command}
|
||||
EOS
|
||||
end
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm repo add app-name https://repository.example.com
|
||||
helm repo update
|
||||
#{helm_install_comand}
|
||||
|
|
@ -64,7 +64,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm repo add app-name https://repository.example.com
|
||||
helm repo update
|
||||
#{helm_install_command}
|
||||
|
|
@ -93,7 +93,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
#{helm_install_command}
|
||||
EOS
|
||||
end
|
||||
|
|
@ -120,7 +120,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm repo add app-name https://repository.example.com
|
||||
helm repo update
|
||||
/bin/date
|
||||
|
|
@ -151,7 +151,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm repo add app-name https://repository.example.com
|
||||
helm repo update
|
||||
#{helm_install_command}
|
||||
|
|
@ -182,7 +182,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm repo add app-name https://repository.example.com
|
||||
helm repo update
|
||||
#{helm_install_command}
|
||||
|
|
@ -210,7 +210,7 @@ describe Gitlab::Kubernetes::Helm::InstallCommand do
|
|||
let(:commands) do
|
||||
<<~EOS
|
||||
helm init --upgrade
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && break; sleep 1s; echo "Retrying ($i)..."; false; done
|
||||
for i in $(seq 1 30); do helm version #{tls_flags} && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)
|
||||
helm repo add app-name https://repository.example.com
|
||||
helm repo update
|
||||
#{helm_install_command}
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ describe Clusters::Applications::CertManager do
|
|||
'kubectl label --overwrite namespace gitlab-managed-apps certmanager.k8s.io/disable-validation=true'
|
||||
])
|
||||
expect(subject.postinstall).to eq([
|
||||
'for i in $(seq 1 30); do kubectl apply -f /data/helm/certmanager/config/cluster_issuer.yaml && break; sleep 1s; echo "Retrying ($i)..."; false; done'
|
||||
"for i in $(seq 1 30); do kubectl apply -f /data/helm/certmanager/config/cluster_issuer.yaml && s=0 && break || s=$?; sleep 1s; echo \"Retrying ($i)...\"; done; (exit $s)"
|
||||
])
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe AttachmentUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe AvatarUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe ExternalDiffUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe FileMover do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe FileUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
require 'carrierwave/storage/fog'
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe ImportExportUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe JobArtifactUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe LfsObjectUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe NamespaceFileUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
require 'carrierwave/storage/fog'
|
||||
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe PersonalFileUploader do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe RecordsUploads do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe UploaderHelper do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe ObjectStorage::BackgroundMoveWorker do
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
require 'spec_helper'
|
||||
|
||||
describe ObjectStorage::MigrateUploadsWorker, :sidekiq do
|
||||
|
|
|
|||