doc: Spelling fixes
This commit is contained in:
parent
6aed49bfca
commit
0cbbb08e79
36 changed files with 46 additions and 46 deletions
|
@ -144,7 +144,7 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
|
|||
1. [Reconfigure][reconf] or [restart] GitLab for Omnibus and installations
|
||||
from source respectively for the changes to take effect.
|
||||
|
||||
You might want to try this out on a incognito browser window.
|
||||
You might want to try this out on an incognito browser window.
|
||||
|
||||
## Configuring groups
|
||||
|
||||
|
|
|
@ -483,7 +483,7 @@ You can use GitLab as an auth endpoint and use a non-bundled Container Registry.
|
|||
1. A certificate keypair is required for GitLab and the Container Registry to
|
||||
communicate securely. By default omnibus-gitlab will generate one keypair,
|
||||
which is saved to `/var/opt/gitlab/gitlab-rails/etc/gitlab-registry.key`.
|
||||
When using an non-bundled Container Registry, you will need to supply a
|
||||
When using a non-bundled Container Registry, you will need to supply a
|
||||
custom certificate key. To do that, add the following to
|
||||
`/etc/gitlab/gitlab.rb`
|
||||
|
||||
|
|
|
@ -154,7 +154,7 @@ who will take all the decisions to restore the service availability by:
|
|||
- Reconfigure the old **Master** and demote to **Slave** when it comes back online
|
||||
|
||||
You must have at least `3` Redis Sentinel servers, and they need to
|
||||
be each in a independent machine (that are believed to fail independently),
|
||||
be each in an independent machine (that are believed to fail independently),
|
||||
ideally in different geographical areas.
|
||||
|
||||
You can configure them in the same machines where you've configured the other
|
||||
|
|
|
@ -172,7 +172,7 @@ Parameters:
|
|||
| --------- | ---- | -------- | ----------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
|
||||
| `issue_iid` | integer | yes | The internal ID of an issue |
|
||||
| `award_id` | integer | yes | The ID of a award_emoji |
|
||||
| `award_id` | integer | yes | The ID of an award_emoji |
|
||||
|
||||
```bash
|
||||
curl --request DELETE --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji/344
|
||||
|
@ -197,7 +197,7 @@ Parameters:
|
|||
| --------- | ---- | -------- | ----------- |
|
||||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
|
||||
| `issue_iid` | integer | yes | The internal ID of an issue |
|
||||
| `note_id` | integer | yes | The ID of an note |
|
||||
| `note_id` | integer | yes | The ID of a note |
|
||||
|
||||
|
||||
```bash
|
||||
|
@ -323,7 +323,7 @@ Parameters:
|
|||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
|
||||
| `issue_iid` | integer | yes | The internal ID of an issue |
|
||||
| `note_id` | integer | yes | The ID of a note |
|
||||
| `award_id` | integer | yes | The ID of a award_emoji |
|
||||
| `award_id` | integer | yes | The ID of an award_emoji |
|
||||
|
||||
```bash
|
||||
curl --request DELETE --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" https://gitlab.example.com/api/v4/projects/1/issues/80/award_emoji/345
|
||||
|
|
|
@ -73,7 +73,7 @@ POST /groups/:id/milestones
|
|||
Parameters:
|
||||
|
||||
- `id` (required) - The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user
|
||||
- `title` (required) - The title of an milestone
|
||||
- `title` (required) - The title of a milestone
|
||||
- `description` (optional) - The description of the milestone
|
||||
- `due_date` (optional) - The due date of the milestone
|
||||
- `start_date` (optional) - The start date of the milestone
|
||||
|
|
|
@ -591,7 +591,7 @@ PUT /projects/:id/merge_requests/:merge_request_iid
|
|||
| `title` | string | no | Title of MR |
|
||||
| `assignee_id` | integer | no | The ID of the user to assign the merge request to. Set to `0` or provide an empty value to unassign all assignees. |
|
||||
| `milestone_id` | integer | no | The ID of a milestone to assign the merge request to. Set to `0` or provide an empty value to unassign a milestone.|
|
||||
| `labels` | string | no | Comma-separated label names for an merge request. Set to an empty string to unassign all labels. |
|
||||
| `labels` | string | no | Comma-separated label names for a merge request. Set to an empty string to unassign all labels. |
|
||||
| `description` | string | no | Description of MR |
|
||||
| `state_event` | string | no | New state (close/reopen) |
|
||||
| `remove_source_branch` | boolean | no | Flag indicating if a merge request should remove the source branch when merging |
|
||||
|
|
|
@ -70,7 +70,7 @@ POST /projects/:id/milestones
|
|||
Parameters:
|
||||
|
||||
- `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
|
||||
- `title` (required) - The title of an milestone
|
||||
- `title` (required) - The title of a milestone
|
||||
- `description` (optional) - The description of the milestone
|
||||
- `due_date` (optional) - The due date of the milestone
|
||||
- `start_date` (optional) - The start date of the milestone
|
||||
|
|
|
@ -158,7 +158,7 @@ Parameters:
|
|||
|
||||
- `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
|
||||
- `snippet_id` (required) - The ID of a project snippet
|
||||
- `note_id` (required) - The ID of an snippet note
|
||||
- `note_id` (required) - The ID of a snippet note
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
@ -982,7 +982,7 @@ Example response:
|
|||
## Unarchive a project
|
||||
|
||||
Unarchives the project if the user is either admin or the project owner of this project. This action is
|
||||
idempotent, thus unarchiving an non-archived project will not change the project.
|
||||
idempotent, thus unarchiving a non-archived project will not change the project.
|
||||
|
||||
```
|
||||
POST /projects/:id/unarchive
|
||||
|
|
|
@ -455,7 +455,7 @@ Mappings are defined as entries in the root YAML array, and are identified by a
|
|||
- Literal periods (`.`) should be escaped as `\.`.
|
||||
- `public`
|
||||
- a string, starting and ending with `'`.
|
||||
- Can include `\N` expressions to refer to capture groups in the `source` regular expression in order of their occurence, starting with `\1`.
|
||||
- Can include `\N` expressions to refer to capture groups in the `source` regular expression in order of their occurrence, starting with `\1`.
|
||||
|
||||
The public path for a source path is determined by finding the first `source` expression that matches it, and returning the corresponding `public` path, replacing the `\N` expressions with the values of the `()` capture groups if appropriate.
|
||||
|
||||
|
|
|
@ -167,7 +167,7 @@ Finally, push to GitLab and let the tests begin!
|
|||
### Test against different PHP versions in Shell builds
|
||||
|
||||
The [phpenv][] project allows you to easily manage different versions of PHP
|
||||
each with its own config. This is specially usefull when testing PHP projects
|
||||
each with its own config. This is especially useful when testing PHP projects
|
||||
with the Shell executor.
|
||||
|
||||
You will have to install it on your build machine under the `gitlab-runner`
|
||||
|
@ -227,7 +227,7 @@ following in your `.gitlab-ci.yml`:
|
|||
...
|
||||
|
||||
# Composer stores all downloaded packages in the vendor/ directory.
|
||||
# Do not use the following if the vendor/ directory is commited to
|
||||
# Do not use the following if the vendor/ directory is committed to
|
||||
# your git repository.
|
||||
cache:
|
||||
paths:
|
||||
|
|
|
@ -42,7 +42,7 @@ production:
|
|||
This project has three jobs:
|
||||
1. `test` - used to test Django application,
|
||||
2. `staging` - used to automatically deploy staging environment every push to `master` branch
|
||||
3. `production` - used to automatically deploy production environmnet for every created tag
|
||||
3. `production` - used to automatically deploy production environment for every created tag
|
||||
|
||||
## Store API keys
|
||||
|
||||
|
|
|
@ -194,7 +194,7 @@ before_script:
|
|||
|
||||
##
|
||||
## You can optionally disable host key checking. Be aware that by adding that
|
||||
## you are suspectible to man-in-the-middle attacks.
|
||||
## you are susceptible to man-in-the-middle attacks.
|
||||
## WARNING: Use this only with the Docker executor, if you use it with shell
|
||||
## you will overwrite your user's SSH config.
|
||||
##
|
||||
|
|
|
@ -87,7 +87,7 @@ future GitLab releases.**
|
|||
|
||||
## 9.0 Renaming
|
||||
|
||||
To follow conventions of naming across GitLab, and to futher move away from the
|
||||
To follow conventions of naming across GitLab, and to further move away from the
|
||||
`build` term and toward `job` CI variables have been renamed for the 9.0
|
||||
release.
|
||||
|
||||
|
|
|
@ -61,7 +61,7 @@ against EE.
|
|||
1. Tries to apply it to current EE `master`
|
||||
1. If it applies cleanly, the job succeeds
|
||||
|
||||
In the case where the job fails, it means you should create a `ee-<ce_branch>`
|
||||
In the case where the job fails, it means you should create an `ee-<ce_branch>`
|
||||
or `<ce_branch>-ee` branch, push it to EE and open a merge request against EE
|
||||
`master`.
|
||||
At this point if you retry the failing job in your CE merge request, it should
|
||||
|
|
|
@ -123,7 +123,7 @@ roughly be as follows:
|
|||
scheduling jobs for newly created data.
|
||||
1. In a post-deployment migration you'll need to ensure no jobs remain. To do
|
||||
so you can use `Gitlab::BackgroundMigration.steal` to process any remaining
|
||||
jobs before continueing.
|
||||
jobs before continuing.
|
||||
1. Remove the old column.
|
||||
|
||||
## Example
|
||||
|
|
|
@ -420,7 +420,7 @@ the style below as a guide:
|
|||
In this case:
|
||||
|
||||
- before each step list the installation method is declared in bold
|
||||
- three dashes (`---`) are used to create an horizontal line and separate the
|
||||
- three dashes (`---`) are used to create a horizontal line and separate the
|
||||
two methods
|
||||
- the code blocks are indented one or more spaces under the list item to render
|
||||
correctly
|
||||
|
|
|
@ -56,7 +56,7 @@ To help us mock the responses we need we use [axios-mock-adapter][axios-mock-ada
|
|||
|
||||
### Mock poll requests on tests with axios
|
||||
|
||||
Because polling function requires an header object, we need to always include an object as the third argument:
|
||||
Because polling function requires a header object, we need to always include an object as the third argument:
|
||||
|
||||
```javascript
|
||||
mock.onGet('/users').reply(200, { foo: 'bar' }, {});
|
||||
|
|
|
@ -456,7 +456,7 @@ describe('Todos App', () => {
|
|||
});
|
||||
```
|
||||
#### `mountComponent` helper
|
||||
There is an helper in `spec/javascripts/helpers/vue_mount_component_helper.js` that allows you to mount a component with the given props:
|
||||
There is a helper in `spec/javascripts/helpers/vue_mount_component_helper.js` that allows you to mount a component with the given props:
|
||||
|
||||
```javascript
|
||||
import Vue from 'vue';
|
||||
|
|
|
@ -4,7 +4,7 @@ When writing migrations for GitLab, you have to take into account that
|
|||
these will be ran by hundreds of thousands of organizations of all sizes, some with
|
||||
many years of data in their database.
|
||||
|
||||
In addition, having to take a server offline for a a upgrade small or big is a
|
||||
In addition, having to take a server offline for an upgrade small or big is a
|
||||
big burden for most organizations. For this reason it is important that your
|
||||
migrations are written carefully, can be applied online and adhere to the style
|
||||
guide below.
|
||||
|
|
|
@ -8,7 +8,7 @@ Note that if your db user does not have advanced privileges you must create the
|
|||
bundle exec rake setup
|
||||
```
|
||||
|
||||
The `setup` task is a alias for `gitlab:setup`.
|
||||
The `setup` task is an alias for `gitlab:setup`.
|
||||
This tasks calls `db:reset` to create the database, calls `add_limits_mysql` that adds limits to the database schema in case of a MySQL database and finally it calls `db:seed_fu` to seed the database.
|
||||
Note: `db:setup` calls `db:seed` but this does nothing.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ View the [interactive example](http://codepen.io/awhildy/full/GNyEvM/) here.
|
|||
|
||||
### Dropdowns
|
||||
|
||||
The dropdown menu should feel like it is appearing from the triggering element. Combining a position shift `400ms cubic-bezier(0.23, 1, 0.32, 1)` with a opacity animation `200ms linear` on the second half of the motion achieves this affect.
|
||||
The dropdown menu should feel like it is appearing from the triggering element. Combining a position shift `400ms cubic-bezier(0.23, 1, 0.32, 1)` with an opacity animation `200ms linear` on the second half of the motion achieves this affect.
|
||||
|
||||
View the [interactive example](http://codepen.io/awhildy/full/jVLJpb/) here.
|
||||
|
||||
|
|
|
@ -108,7 +108,7 @@ Primary buttons communicate the main call to action. There should only be one ca
|
|||
![Primary button example](img/button-primary.png)
|
||||
|
||||
#### Secondary
|
||||
Secondary buttons are for alternative commands. They should be conveyed by a button with an stroke, and no background fill.
|
||||
Secondary buttons are for alternative commands. They should be conveyed by a button with a stroke, and no background fill.
|
||||
|
||||
![Secondary button example](img/button-secondary.png)
|
||||
|
||||
|
@ -181,7 +181,7 @@ A count element is used in navigation contexts where it is helpful to indicate t
|
|||
|
||||
## Lists
|
||||
|
||||
Lists are used where ever there is a single column of information to display. Ths [issues list](https://gitlab.com/gitlab-org/gitlab-ce/issues) is an example of a important list in the GitLab UI.
|
||||
Lists are used where ever there is a single column of information to display. Ths [issues list](https://gitlab.com/gitlab-org/gitlab-ce/issues) is an example of an important list in the GitLab UI.
|
||||
|
||||
### Types
|
||||
|
||||
|
@ -269,7 +269,7 @@ Modals are only used for having a conversation and confirmation with the user. T
|
|||
* Modals contain the header, body, and actions.
|
||||
* **Header(1):** The header title is a question instead of a descriptive phrase.
|
||||
* **Body(2):** The content in body should never be ambiguous and unclear. It provides specific information.
|
||||
* **Actions(3):** Contains a affirmative action, a dismissive action, and an extra action. The order of actions from left to right: Dismissive action → Extra action → Affirmative action
|
||||
* **Actions(3):** Contains an affirmative action, a dismissive action, and an extra action. The order of actions from left to right: Dismissive action → Extra action → Affirmative action
|
||||
* Confirmations regarding labels should keep labeling styling.
|
||||
* References to commits, branches, and tags should be **monospaced**.
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ This means that, as a rule, copy should be very short. A long message or label i
|
|||
|
||||
>**Example:**
|
||||
Use `Add` instead of `Add issue` as a button label.
|
||||
Preferrably use context and placement of controls to make it obvious what clicking on them will do.
|
||||
Preferably use context and placement of controls to make it obvious what clicking on them will do.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
@ -178,7 +178,7 @@ address. Read [IP address types and allocation methods in Azure][Azure-IP-Addres
|
|||
|
||||
At this stage you should have a running and fully operational VM. However, none of the services on
|
||||
your VM (e.g. GitLab) will be publicly accessible via the internet until you have opened up the
|
||||
neccessary ports to enable access to those services.
|
||||
necessary ports to enable access to those services.
|
||||
|
||||
Ports are opened by adding _security rules_ to the **"Network security group"** (NSG) which our VM
|
||||
has been assigned to. If you followed the process above, then Azure will have automatically created
|
||||
|
|
|
@ -431,7 +431,7 @@ GitLab Shell is an SSH access and repository management software developed speci
|
|||
**Note:** GitLab Shell application startup time can be greatly reduced by disabling RubyGems. This can be done in several manners:
|
||||
|
||||
* Export `RUBYOPT=--disable-gems` environment variable for the processes
|
||||
* Compile Ruby with `configure --disable-rubygems` to disable RubyGems by default. Not recommened for system-wide Ruby.
|
||||
* Compile Ruby with `configure --disable-rubygems` to disable RubyGems by default. Not recommended for system-wide Ruby.
|
||||
* Omnibus GitLab [replaces the *shebang* line of the `gitlab-shell/bin/*` scripts](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/1707)
|
||||
|
||||
### Install gitlab-workhorse
|
||||
|
@ -442,7 +442,7 @@ which is the recommended location.
|
|||
|
||||
sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse]" RAILS_ENV=production
|
||||
|
||||
You can specify a different Git repository by providing it as an extra paramter:
|
||||
You can specify a different Git repository by providing it as an extra parameter:
|
||||
|
||||
sudo -u git -H bundle exec rake "gitlab:workhorse:install[/home/git/gitlab-workhorse,https://example.com/gitlab-workhorse.git]" RAILS_ENV=production
|
||||
|
||||
|
@ -486,7 +486,7 @@ Make GitLab start on boot:
|
|||
# Fetch Gitaly source with Git and compile with Go
|
||||
sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly]" RAILS_ENV=production
|
||||
|
||||
You can specify a different Git repository by providing it as an extra paramter:
|
||||
You can specify a different Git repository by providing it as an extra parameter:
|
||||
|
||||
sudo -u git -H bundle exec rake "gitlab:gitaly:install[/home/git/gitaly,https://example.com/gitaly.git]" RAILS_ENV=production
|
||||
|
||||
|
@ -656,7 +656,7 @@ Checkout the [GitLab Runner section](https://about.gitlab.com/gitlab-ci/#gitlab-
|
|||
|
||||
### Adding your Trusted Proxies
|
||||
|
||||
If you are using a reverse proxy on an separate machine, you may want to add the
|
||||
If you are using a reverse proxy on a separate machine, you may want to add the
|
||||
proxy to the trusted proxies list. Otherwise users will appear signed in from the
|
||||
proxy's IP address.
|
||||
|
||||
|
|
|
@ -14,7 +14,7 @@ This article will show you how to install Git on macOS, Ubuntu Linux and Windows
|
|||
Although it is easy to use the version of Git shipped with macOS
|
||||
or install the latest version of Git on macOS by downloading it from the project website,
|
||||
we recommend installing it via Homebrew to get access to
|
||||
an extensive selection of dependancy managed libraries and applications.
|
||||
an extensive selection of dependency managed libraries and applications.
|
||||
|
||||
If you are sure you don't need access to any additional development libraries
|
||||
or don't have approximately 15gb of available disk space for Xcode and Homebrew
|
||||
|
|
|
@ -229,7 +229,7 @@ Our free on Premise solution with >100,000 users
|
|||
|
||||
### GitLab CI
|
||||
|
||||
Our own Continuos Integration [feature](https://about.gitlab.com/gitlab-ci/) that is shipped with each instance
|
||||
Our own Continuous Integration [feature](https://about.gitlab.com/gitlab-ci/) that is shipped with each instance
|
||||
|
||||
### GitLab EE
|
||||
|
||||
|
|
|
@ -147,7 +147,7 @@ change which will be helpful is the database name for which we can use
|
|||
## ElastiCache
|
||||
|
||||
EC is an in-memory hosted caching solution. Redis maintains its own
|
||||
persistance and is used for certain types of application.
|
||||
persistence and is used for certain types of application.
|
||||
|
||||
Let's choose the ElastiCache service in the Database section from our
|
||||
AWS console. Now lets create a cache subnet group which will be very
|
||||
|
@ -311,7 +311,7 @@ Here is a tricky part though, when adding subnets we need to associate
|
|||
public subnets instead of the private ones where our instances will
|
||||
actually live.
|
||||
|
||||
On the secruity group section let's create a new one named
|
||||
On the security group section let's create a new one named
|
||||
`gitlab-loadbalancer-sec-group` and allow both HTTP ad HTTPS traffic
|
||||
from anywhere.
|
||||
|
||||
|
|
|
@ -212,7 +212,7 @@ Sign in and re-enable two-factor authentication as soon as possible.
|
|||
For example, if a user is trying to access a GitLab instance from `first.host.xyz` and `second.host.xyz`:
|
||||
|
||||
- The user logs in via `first.host.xyz` and registers their U2F key.
|
||||
- The user logs out and attempts to log in via `first.host.xyz` - U2F authentication suceeds.
|
||||
- The user logs out and attempts to log in via `first.host.xyz` - U2F authentication succeeds.
|
||||
- The user logs out and attempts to log in via `second.host.xyz` - U2F authentication fails, because
|
||||
the U2F key has only been registered on `first.host.xyz`.
|
||||
|
||||
|
|
|
@ -10,7 +10,7 @@ In the _Recipients_ area, provide a list of emails separated by commas.
|
|||
|
||||
You can configure any of the following settings depending on your preference.
|
||||
|
||||
+ **Push events** - Email will be triggered when a push event is recieved
|
||||
+ **Push events** - Email will be triggered when a push event is received
|
||||
+ **Tag push events** - Email will be triggered when a tag is created and pushed
|
||||
+ **Send from committer** - Send notifications from the committer's email address if the domain is part of the domain GitLab is running on (e.g. `user@gitlab.com`).
|
||||
+ **Disable code diffs** - Don't include possibly sensitive code diffs in notification body.
|
||||
|
|
|
@ -316,7 +316,7 @@ X-Gitlab-Event: Issue Hook
|
|||
Triggered when a new comment is made on commits, merge requests, issues, and code snippets.
|
||||
The note data will be stored in `object_attributes` (e.g. `note`, `noteable_type`). The
|
||||
payload will also include information about the target of the comment. For example,
|
||||
a comment on a issue will include the specific issue information under the `issue` key.
|
||||
a comment on an issue will include the specific issue information under the `issue` key.
|
||||
Valid target types:
|
||||
|
||||
1. `commit`
|
||||
|
|
|
@ -40,7 +40,7 @@ issues around that same idea.
|
|||
You do that as explained above, when
|
||||
[mentioning an issue from a commit message](#from-commit-messages).
|
||||
|
||||
When mentioning the issue "A" in a issue "B", the issue "A" will also
|
||||
When mentioning the issue "A" in issue "B", the issue "A" will also
|
||||
display a notification in its tracker. The same is valid for mentioning
|
||||
issues in merge requests.
|
||||
|
||||
|
|
|
@ -52,7 +52,7 @@ special options available when filtering by milestone:
|
|||
The milestone sidebar shows percentage complete, start date and due date,
|
||||
issues, total issue weight, total issue time spent, and merge requests.
|
||||
|
||||
The percentage complete is calcualted as: Closed and merged merge requests plus all closed issues divided by
|
||||
The percentage complete is calculated as: Closed and merged merge requests plus all closed issues divided by
|
||||
total merge requests and issues.
|
||||
|
||||
![Milestone sidebar](img/sidebar.png)
|
||||
|
|
|
@ -91,7 +91,7 @@ to steal the tokens of other jobs.
|
|||
|
||||
Since 9.0 [pipeline triggers][triggers] do support the new permission model.
|
||||
The new triggers do impersonate their associated user including their access
|
||||
to projects and their project permissions. To migrate trigger to use new permisison
|
||||
to projects and their project permissions. To migrate trigger to use new permission
|
||||
model use **Take ownership**.
|
||||
|
||||
## Before GitLab 8.12
|
||||
|
|
|
@ -373,7 +373,7 @@ configuration.
|
|||
If the case of `404.html`, there are different scenarios. For example:
|
||||
|
||||
- If you use project Pages (served under `/projectname/`) and try to access
|
||||
`/projectname/non/exsiting_file`, GitLab Pages will try to serve first
|
||||
`/projectname/non/existing_file`, GitLab Pages will try to serve first
|
||||
`/projectname/404.html`, and then `/404.html`.
|
||||
- If you use user/group Pages (served under `/`) and try to access
|
||||
`/non/existing_file` GitLab Pages will try to serve `/404.html`.
|
||||
|
|
Loading…
Reference in a new issue