This is the administration documentation. There is a separate [user documentation](../user/project/issues/managing_issues.md#closing-issues-automatically)
on issue closing pattern.
...
...
@@ -16,7 +16,7 @@ is installed on.
The default pattern can be located in [`gitlab.yml.example`](https://gitlab.com/gitlab-org/gitlab/blob/master/config/gitlab.yml.example)
under the "Automatic issue closing" section.
> **Tip:**
TIP:**Tip:**
You are advised to use <https://rubular.com> to test the issue closing pattern.
Because Rubular doesn't understand `%{issue_ref}`, you can replace this by
`#\d+` when testing your patterns, which matches only local issue references like `#123`.
@@ -227,7 +227,7 @@ To use an external Prometheus server:
You can visit `http://localhost:9090` for the dashboard that Prometheus offers by default.
>**Note:**
NOTE: **Note:**
If SSL has been enabled on your GitLab instance, you may not be able to access
Prometheus on the same browser as GitLab if using the same FQDN due to [HSTS](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security). We plan to
[provide access via GitLab](https://gitlab.com/gitlab-org/multi-user-prometheus), but in the interim there are
@@ -89,7 +89,7 @@ This example uses NFS. We do not recommend using EFS for storage as it may impac
1.[Restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
>**Note:**
NOTE: **Note:**
The [`gitlab_shell: repos_path` entry](https://gitlab.com/gitlab-org/gitlab-foss/-/blob/8-9-stable/config/gitlab.yml.example#L457) in `gitlab.yml` will be
deprecated and replaced by `repositories: storages` in the future, so if you
are upgrading from a version prior to 8.10, make sure to add the configuration
>**Note:** This API requires an access token with Maintainer or Owner permissions
NOTE: **Note:**
This API requires an access token with Maintainer or Owner permissions
## List all active services
...
...
@@ -636,9 +637,9 @@ GET /projects/:id/services/github
## Hangouts Chat
Google GSuite team collaboration tool.
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20290) in GitLab 11.2.
>**Note:** This service was [introduced in v11.2](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/20290)
Google GSuite team collaboration tool.
### Create/Edit Hangouts Chat service
...
...
@@ -648,7 +649,8 @@ Set Hangouts Chat service for a project.
PUT /projects/:id/services/hangouts-chat
```
>**Note:** Specific event parameters (for example, `push_events` flag) were [introduced in v10.4](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11435)
NOTE: **Note:**
Specific event parameters (for example, `push_events` flag) were [introduced in v10.4](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11435)
Parameters:
...
...
@@ -1151,7 +1153,8 @@ Set Slack service for a project.
PUT /projects/:id/services/slack
```
>**Note:** Specific event parameters (for example, `push_events` flag and `push_channel`) were [introduced in v10.4](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11435)
NOTE: **Note:**
Specific event parameters (for example, `push_events` flag and `push_channel`) were [introduced in v10.4](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11435)
Parameters:
...
...
@@ -1260,7 +1263,8 @@ Set Mattermost service for a project.
PUT /projects/:id/services/mattermost
```
>**Note:** Specific event parameters (for example, `push_events` flag and `push_channel`) were [introduced in v10.4](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11435)
NOTE: **Note:**
Specific event parameters (for example, `push_events` flag and `push_channel`) were [introduced in v10.4](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/11435)
To run the above commands, we first need to have [Docker](https://docs.docker.com/engine/installation/) installed on our machine.
Congratulations! You just pushed the first Docker image to the GitLab Registry, and if you refresh the page you should be able to see it:
![container registry page with image](img/container_registry_page_with_image.jpg)
>**Note:**
NOTE: **Note:**
You can also [use GitLab CI/CD](https://about.gitlab.com/blog/2016/05/23/gitlab-container-registry/#use-with-gitlab-ci) to build and push your Docker images, rather than doing that on your machine.
We'll use this image further down in the `.gitlab-ci.yml` configuration file to handle the process of testing and deploying our app.
...
...
@@ -551,7 +551,7 @@ services:
...
```
>**Note:**
NOTE: **Note:**
If you wish to test your app with different PHP versions and [database management systems](../../services/README.md), you can define different `image` and `services` keywords for each test job.
As an example you might create 5 issues in between counts, which would cause the query count to increase by 5 if an N+1 problem exists.
> **Note:** In some cases the query count might change slightly between runs for unrelated reasons. In this case you might need to test `exceed_query_limit(control_count + acceptable_change)`, but this should be avoided if possible.
NOTE: **Note:**
In some cases the query count might change slightly between runs for unrelated reasons. In this case you might need to test `exceed_query_limit(control_count + acceptable_change)`, but this should be avoided if possible.
@@ -24,9 +24,8 @@ We have started to migrate frontend tests to the [Jest](https://jestjs.io) testi
Jest tests can be found in `/spec/frontend` and `/ee/spec/frontend` in EE.
> **Note:**
>
> Most examples have a Jest and Karma example. See the Karma examples only as explanation to what's going on in the code, should you stumble over some use cases during your discovery. The Jest examples are the one you should follow.
NOTE: **Note:**
Most examples have a Jest and Karma example. See the Karma examples only as explanation to what's going on in the code, should you stumble over some use cases during your discovery. The Jest examples are the one you should follow.
> **Note:** at this stage, you can review and modify the any of the settings you have made during all
NOTE: **Note:**
At this stage, you can review and modify the any of the settings you have made during all
previous steps, just click on any of the four steps to re-open them.
When you have read and agreed to the terms of use and are ready to proceed, click **"Purchase"**.
...
...
@@ -173,7 +178,8 @@ _(the full domain name of your own VM will be different, of course)_.
Click **"Save"** for the changes to take effect.
> **Note:** if you want to use your own domain name, you will need to add a DNS `A` record at your
NOTE **Note:**
If you want to use your own domain name, you will need to add a DNS `A` record at your
domain registrar which points to the public IP address of your Azure VM. If you do this, you'll need
to make sure your VM is configured to use a _static_ public IP address (i.e. not a _dynamic_ one)
or you will have to reconfigure the DNS `A` record each time Azure reassigns your VM a new public IP
...
...
@@ -189,7 +195,8 @@ Ports are opened by adding _security rules_ to the **"Network security group"**
has been assigned to. If you followed the process above, then Azure will have automatically created
an NSG named `GitLab-CE-nsg` and assigned the `GitLab-CE` VM to it.
> **Note:** if you gave your VM a different name then the NSG automatically created by Azure will
NOTE: **Note:**
If you gave your VM a different name then the NSG automatically created by Azure will
also have a different name - the name you have your VM, with `-nsg` appended to it.
You can navigate to the NSG settings via many different routes in the Azure Portal, but one of the
...
...
@@ -320,7 +327,8 @@ Under the **"Components"** section, we can see that our VM is currently running
GitLab. This is the version of GitLab which was contained in the Azure Marketplace
**"GitLab Community Edition"** offering we used to build the VM when we wrote this tutorial.
> **Note:** The version of GitLab in your own VM instance may well be different, but the update
NOTE **Note:**
The version of GitLab in your own VM instance may well be different, but the update
process will still be the same.
### Connect via SSH
...
...
@@ -332,12 +340,11 @@ connect to it using SSH ([Secure Shell](https://en.wikipedia.org/wiki/Secure_She
If you're running Windows, you'll need to connect using [PuTTY](https://www.putty.org) or an equivalent Windows SSH client.
If you're running Linux or macOS, then you already have an SSH client installed.
> **Note:**
>
> - Remember that you will need to login with the username and password you specified
> [when you created](#basics) your Azure VM
> - If you need to reset your VM password, read
> [how to reset SSH credentials for a user on an Azure VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection).
Remember that you will need to login with the username and password you specified
[when you created](#basics) your Azure VM.
If you need to reset your VM password, read
[how to reset SSH credentials for a user on an Azure VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection).
@@ -43,9 +43,9 @@ contains some settings that are common for all providers.
Before configuring individual OmniAuth providers there are a few global settings
that are in common for all providers that we need to consider.
> **NOTE:**
> Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
> earlier version, you'll need to explicitly enable it.
NOTE: **Note:**
Starting from GitLab 11.4, OmniAuth is enabled by default. If you're using an
earlier version, you'll need to explicitly enable it.
-`allow_single_sign_on` allows you to specify the providers you want to allow to
automatically create an account. It defaults to `false`. If `false` users must
...
...
@@ -57,16 +57,16 @@ that are in common for all providers that we need to consider.
be blocked by default and will have to be unblocked by an administrator before
they are able to sign in.
> **Note:**
> If you set `block_auto_created_users` to `false`, make sure to only
> define providers under `allow_single_sign_on` that you are able to control, like
> SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
> the Internet will be able to successfully sign in to your GitLab without
> administrative approval.
>
> **Note:**
> `auto_link_ldap_user` requires the `uid` of the user to be the same in both LDAP
> and the OmniAuth provider.
NOTE:**Note:**
If you set `block_auto_created_users` to `false`, make sure to only
define providers under `allow_single_sign_on` that you are able to control, like
SAML, Shibboleth, Crowd or Google, or set it to `false` otherwise any user on
the Internet will be able to successfully sign in to your GitLab without
administrative approval.
NOTE:**Note:**
`auto_link_ldap_user` requires the `uid` of the user to be the same in both LDAP
and the OmniAuth provider.
To change these settings:
...
...
@@ -142,8 +142,7 @@ The chosen OmniAuth provider is now active and can be used to sign in to GitLab
## Configure OmniAuth Providers as External
>**Note:**
This setting was introduced with version 8.7 of GitLab
> Introduced in GitLab 8.7.
You can define which OmniAuth providers you want to be `external` so that all users
**creating accounts, or logging in via these providers** will not be able to have
...
...
@@ -151,7 +150,7 @@ access to internal projects. You will need to use the full name of the provider,
like `google_oauth2` for Google. Refer to the examples for the full names of the
supported providers.
>**Note:**
NOTE: **Note:**
If you decide to remove an OmniAuth provider from the external providers list
you will need to manually update the users that use this method to login, if you
want their accounts to be upgraded to full internal accounts.
...
...
@@ -171,7 +170,7 @@ omniauth:
## Using Custom OmniAuth Providers
>**Note:**
NOTE: **Note:**
The following information only applies for installations from source.
GitLab uses [OmniAuth](https://github.com/omniauth/omniauth) for authentication and already ships
...
...
@@ -224,12 +223,11 @@ we'd like to at least help those with specific needs.
## Enable or disable Sign In with an OmniAuth provider without disabling import sources
>**Note:**
This setting was introduced with version 8.8 of GitLab.
> Introduced in GitLab 8.8.
Administrators are able to enable or disable Sign In via some OmniAuth providers.
>**Note:**
NOTE: **Note:**
By default Sign In is enabled via all the OAuth Providers that have been configured in `config/gitlab.yml`.
In order to enable/disable an OmniAuth provider, go to Admin Area -> Settings -> Sign-in Restrictions section -> Enabled OAuth Sign-In sources and select the providers you want to enable or disable.
@@ -266,11 +266,11 @@ One option is to use continuous integration (CI) to merge in `master` at the sta
Another option is to only merge in from well-defined points in time, for example, a tagged release.
You could also use [feature toggles](https://martinfowler.com/bliki/FeatureToggle.html) to hide incomplete features so you can still merge back into `master` every day.
> **Note:** Don't confuse automatic branch testing with continuous integration.
> Martin Fowler makes this distinction in [his article about feature branches](https://martinfowler.com/bliki/FeatureBranch.html):
>
> "I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit.
> That's continuous building, and a Good Thing, but there's no *integration*, so it's not CI."
NOTE: **Note:**
Don't confuse automatic branch testing with continuous integration.
Martin Fowler makes this distinction in [his article about feature branches](https://martinfowler.com/bliki/FeatureBranch.html):
"I've heard people say they are doing CI because they are running builds, perhaps using a CI server, on every branch with every commit.
That's continuous building, and a Good Thing, but there's no *integration*, so it's not CI."
In conclusion, you should try to prevent merge commits, but not eliminate them.
Your codebase should be clean, but your history should represent what actually happened.
@@ -258,7 +258,8 @@ If you're new to this, don't be <img src="https://gitlab.com/gitlab-org/gitlab-f
Consult the [Emoji Cheat Sheet](https://www.webfx.com/tools/emoji-cheat-sheet/) for a list of all supported emoji codes. <imgsrc="https://gitlab.com/gitlab-org/gitlab-foss/raw/master/app/assets/images/emoji/thumbsup.png"width="20px"height="20px"style="display:inline;margin:0">
> **Note:** The emoji example above uses hard-coded images for this documentation. The emoji,
NOTE: **Note:**
The emoji example above uses hard-coded images for this documentation. The emoji,
when rendered within GitLab, may appear different depending on the OS and browser used.
Most emoji are natively supported on macOS, Windows, iOS, Android, and will fall back on image-based emoji where there is no support.