Fix markdown in various docs
Clean up issues that may cause the docs-lint test to fail, such as trailing whitespace, no EOF newline, blockquotes, etc
This commit is contained in:
Marcel Amirault
Achilleas Pipinellis
parent
1873e4c160
commit
d7d218628f
|
|
@ -32,7 +32,7 @@ For example, [Active Directory](https://technet.microsoft.com/en-us/library/hh83
|
|||
|
||||
We won't cover the installation and configuration of Windows Server or Active Directory Domain Services in this tutorial. There are a number of resources online to guide you through this process:
|
||||
|
||||
- Install Windows Server 2012 - (_technet.microsoft.com_) - [Installing Windows Server 2012 ](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
|
||||
- Install Windows Server 2012 - (_technet.microsoft.com_) - [Installing Windows Server 2012](https://technet.microsoft.com/en-us/library/jj134246(v=ws.11).aspx)
|
||||
|
||||
- Install Active Directory Domain Services (AD DS) (_technet.microsoft.com_)- [Install Active Directory Domain Services](https://technet.microsoft.com/windows-server-docs/identity/ad-ds/deploy/install-active-directory-domain-services--level-100-#BKMK_PS)
|
||||
|
||||
|
|
@ -249,7 +249,7 @@ After configuring LDAP, basic authentication will be available. Users can then l
|
|||
|
||||
Users that are removed from the LDAP base group (e.g `OU=GitLab INT,DC=GitLab,DC=org`) will be **blocked** in GitLab. [More information](../ldap.md#security) on LDAP security.
|
||||
|
||||
If `allow_username_or_email_login` is enabled in the LDAP configuration, GitLab will ignore everything after the first '@' in the LDAP username used on login. Example: The username `` jon.doe@example.com `` is converted to `jon.doe` when authenticating with the LDAP server. Disable this setting if you use `userPrincipalName` as the `uid`.
|
||||
If `allow_username_or_email_login` is enabled in the LDAP configuration, GitLab will ignore everything after the first '@' in the LDAP username used on login. Example: The username `jon.doe@example.com` is converted to `jon.doe` when authenticating with the LDAP server. Disable this setting if you use `userPrincipalName` as the `uid`.
|
||||
|
||||
## LDAP extended features on GitLab EE
|
||||
|
||||
|
|
|
|||
|
|
@ -98,20 +98,20 @@ Now that the Okta app is configured, it's time to enable it in GitLab.
|
|||
>**Notes:**
|
||||
>
|
||||
>- Change the value for `assertion_consumer_service_url` to match the HTTPS endpoint
|
||||
of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
|
||||
installation to generate the correct value).
|
||||
> of GitLab (append `users/auth/saml/callback` to the HTTPS URL of your GitLab
|
||||
> installation to generate the correct value).
|
||||
>
|
||||
>- To get the `idp_cert_fingerprint` fingerprint, first download the
|
||||
certificate from the Okta app you registered and then run:
|
||||
`openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
|
||||
with the location of your certificate.
|
||||
> certificate from the Okta app you registered and then run:
|
||||
> `openssl x509 -in okta.cert -noout -fingerprint`. Substitute `okta.cert`
|
||||
> with the location of your certificate.
|
||||
>
|
||||
>- Change the value of `idp_sso_target_url`, with the value of the
|
||||
**Identity Provider Single Sign-On URL** from the step when you
|
||||
configured the Okta app.
|
||||
> **Identity Provider Single Sign-On URL** from the step when you
|
||||
> configured the Okta app.
|
||||
>
|
||||
>- Change the value of `issuer` to the value of the **Audience Restriction** from your Okta app configuration. This will identify GitLab
|
||||
to the IdP.
|
||||
> to the IdP.
|
||||
>
|
||||
>- Leave `name_identifier_format` as-is.
|
||||
|
||||
|
|
|
|||
|
|
@ -297,7 +297,7 @@ for another **primary** node. All the old replication settings will be overwritt
|
|||
|
||||
## Troubleshooting
|
||||
|
||||
### I followed the disaster recovery instructions and now two-factor auth is broken!
|
||||
### I followed the disaster recovery instructions and now two-factor auth is broken
|
||||
|
||||
The setup instructions for Geo prior to 10.5 failed to replicate the
|
||||
`otp_key_base` secret, which is used to encrypt the two-factor authentication
|
||||
|
|
|
|||
|
|
@ -538,7 +538,7 @@ can simply reset the existing tracking database with:
|
|||
sudo gitlab-rake geo:db:reset
|
||||
```
|
||||
|
||||
### Geo node has a database that is writable which is an indication it is not configured for replication with the primary node.
|
||||
### Geo node has a database that is writable which is an indication it is not configured for replication with the primary node
|
||||
|
||||
This error refers to a problem with the database replica on a **secondary** node,
|
||||
which Geo expects to have access to. It usually means, either:
|
||||
|
|
@ -552,7 +552,7 @@ PostgreSQL instances:
|
|||
- A read-only replica of the **primary** node.
|
||||
- A regular, writable instance that holds replication metadata. That is, the Geo tracking database.
|
||||
|
||||
### Geo node does not appear to be replicating the database from the primary node.
|
||||
### Geo node does not appear to be replicating the database from the primary node
|
||||
|
||||
The most common problems that prevent the database from replicating correctly are:
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ Check the directory layout on your Gitaly server to be sure.
|
|||
```
|
||||
|
||||
1. Append the following to `/etc/gitlab/gitlab.rb` for each respective server:
|
||||
|
||||
|
||||
For `gitaly1.internal`:
|
||||
|
||||
```
|
||||
|
|
@ -194,7 +194,7 @@ Check the directory layout on your Gitaly server to be sure.
|
|||
{ 'name' => 'storage1' },
|
||||
]
|
||||
```
|
||||
|
||||
|
||||
For `gitaly2.internal`:
|
||||
|
||||
```
|
||||
|
|
@ -226,7 +226,7 @@ Check the directory layout on your Gitaly server to be sure.
|
|||
```
|
||||
|
||||
1. Append the following to `/home/git/gitaly/config.toml` for each respective server:
|
||||
|
||||
|
||||
For `gitaly1.internal`:
|
||||
|
||||
```toml
|
||||
|
|
@ -236,7 +236,7 @@ Check the directory layout on your Gitaly server to be sure.
|
|||
[[storage]]
|
||||
name = 'storage1'
|
||||
```
|
||||
|
||||
|
||||
For `gitaly2.internal`:
|
||||
|
||||
```toml
|
||||
|
|
@ -262,12 +262,12 @@ Additionally, you need to
|
|||
[disable Rugged if previously manually enabled](../high_availability/nfs.md#improving-nfs-performance-with-gitlab).
|
||||
|
||||
We assume that your `gitaly1.internal` Gitaly server can be reached at
|
||||
`gitaly1.internal:8075` from your GitLab server, and that Gitaly server
|
||||
`gitaly1.internal:8075` from your GitLab server, and that Gitaly server
|
||||
can read and write to `/mnt/gitlab/default` and `/mnt/gitlab/storage1`.
|
||||
|
||||
We assume also that your `gitaly2.internal` Gitaly server can be reached at
|
||||
`gitaly2.internal:8075` from your GitLab server, and that Gitaly server
|
||||
can read and write to `/mnt/gitlab/storage2`.
|
||||
`gitaly2.internal:8075` from your GitLab server, and that Gitaly server
|
||||
can read and write to `/mnt/gitlab/storage2`.
|
||||
|
||||
**For Omnibus GitLab**
|
||||
|
||||
|
|
@ -540,6 +540,7 @@ gitaly['concurrency'] = [
|
|||
}
|
||||
]
|
||||
```
|
||||
|
||||
This will limit the number of in-flight RPC calls for the given RPC's.
|
||||
The limit is applied per repository. In the example above, each on the
|
||||
Gitaly server can have at most 20 simultaneous PostUploadPack calls in
|
||||
|
|
@ -729,4 +730,4 @@ To remove the proxy setting, run the following commands (depending on which vari
|
|||
```bash
|
||||
unset http_proxy
|
||||
unset https_proxy
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -4,9 +4,9 @@ type: reference
|
|||
|
||||
# Configuring GitLab for Scaling and High Availability
|
||||
|
||||
> **Note:** There is some additional configuration near the bottom for
|
||||
additional GitLab application servers. It's important to read and understand
|
||||
these additional steps before proceeding with GitLab installation.
|
||||
NOTE: **Note:** There is some additional configuration near the bottom for
|
||||
additional GitLab application servers. It's important to read and understand
|
||||
these additional steps before proceeding with GitLab installation.
|
||||
|
||||
1. If necessary, install the NFS client utility packages using the following
|
||||
commands:
|
||||
|
|
@ -82,19 +82,19 @@ type: reference
|
|||
|
||||
1. [Enable monitoring](#enable-monitoring)
|
||||
|
||||
> **Note:** To maintain uniformity of links across HA clusters, the `external_url`
|
||||
NOTE: **Note:** To maintain uniformity of links across HA clusters, the `external_url`
|
||||
on the first application server as well as the additional application
|
||||
servers should point to the external url that users will use to access GitLab.
|
||||
In a typical HA setup, this will be the url of the load balancer which will
|
||||
route traffic to all GitLab application servers in the HA cluster.
|
||||
>
|
||||
> **Note:** When you specify `https` in the `external_url`, as in the example
|
||||
|
||||
NOTE: **Note:** When you specify `https` in the `external_url`, as in the example
|
||||
above, GitLab assumes you have SSL certificates in `/etc/gitlab/ssl/`. If
|
||||
certificates are not present, Nginx will fail to start. See
|
||||
[Nginx documentation](https://docs.gitlab.com/omnibus/settings/nginx.html#enable-https)
|
||||
for more information.
|
||||
>
|
||||
> **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
|
||||
|
||||
NOTE: **Note:** It is best to set the `uid` and `gid`s prior to the initial reconfigure
|
||||
of GitLab. Omnibus will not recursively `chown` directories if set after the initial reconfigure.
|
||||
|
||||
## First GitLab application server
|
||||
|
|
@ -105,8 +105,8 @@ Do not run this on additional application servers.
|
|||
1. Initialize the database by running `sudo gitlab-rake gitlab:setup`.
|
||||
1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
|
||||
|
||||
> **WARNING:** Only run this setup task on **NEW** GitLab instances because it
|
||||
will wipe any existing data.
|
||||
CAUTION: **WARNING:** Only run this setup task on **NEW** GitLab instances because it
|
||||
will wipe any existing data.
|
||||
|
||||
## Extra configuration for additional GitLab application servers
|
||||
|
||||
|
|
@ -173,9 +173,10 @@ If you enable Monitoring, it must be enabled on **all** GitLab servers.
|
|||
|
||||
1. Run `sudo gitlab-ctl reconfigure` to compile the configuration.
|
||||
|
||||
> **Warning:** After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
|
||||
it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
|
||||
For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
|
||||
CAUTION: **Warning:**
|
||||
After changing `unicorn['listen']` in `gitlab.rb`, and running `sudo gitlab-ctl reconfigure`,
|
||||
it can take an extended period of time for unicorn to complete reloading after receiving a `HUP`.
|
||||
For more information, see the [issue](https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4401).
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
|
|
|
|||
|
|
@ -343,21 +343,6 @@ world. Custom domains and TLS are supported.
|
|||
1. Restart NGINX
|
||||
1. [Restart GitLab][restart]
|
||||
|
||||
## Change storage path
|
||||
|
||||
Follow the steps below to change the default path where GitLab Pages' contents
|
||||
are stored.
|
||||
|
||||
1. Pages are stored by default in `/var/opt/gitlab/gitlab-rails/shared/pages`.
|
||||
If you wish to store them in another location you must set it up in
|
||||
`/etc/gitlab/gitlab.rb`:
|
||||
|
||||
```ruby
|
||||
gitlab_rails['pages_path'] = "/mnt/storage/pages"
|
||||
```
|
||||
|
||||
1. [Reconfigure GitLab][reconfigure]
|
||||
|
||||
## NGINX caveats
|
||||
|
||||
>**Note:**
|
||||
|
|
@ -468,7 +453,6 @@ than GitLab to prevent XSS attacks.
|
|||
[NGINX configs]: https://gitlab.com/gitlab-org/gitlab-ee/tree/8-5-stable-ee/lib/support/nginx
|
||||
[pages-readme]: https://gitlab.com/gitlab-org/gitlab-pages/blob/master/README.md
|
||||
[pages-userguide]: ../../user/project/pages/index.md
|
||||
[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
|
||||
[restart]: ../restart_gitlab.md#installations-from-source
|
||||
[gitlab-pages]: https://gitlab.com/gitlab-org/gitlab-pages/tree/v0.4.0
|
||||
[gl-example]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/support/init.d/gitlab.default.example
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# GitHub import
|
||||
|
||||
> [Introduced]( https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10308) in GitLab 9.1.
|
||||
> [Introduced]( https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10308) in GitLab 9.1.
|
||||
|
||||
In order to retrieve and import GitHub repositories, you will need a
|
||||
[GitHub personal access token](https://github.com/settings/tokens).
|
||||
|
|
|
|||
|
|
@ -19,8 +19,6 @@ sudo gitlab-rake gitlab:ldap:check
|
|||
sudo -u git -H bundle exec rake gitlab:ldap:check RAILS_ENV=production
|
||||
```
|
||||
|
||||
------
|
||||
|
||||
By default, the task will return a sample of 100 LDAP users. Change this
|
||||
limit by passing a number to the check task:
|
||||
|
||||
|
|
@ -135,8 +133,6 @@ What is the old provider? Ex. 'ldapmain': ldapmain
|
|||
What is the new provider? Ex. 'ldapcustom': ldapmycompany
|
||||
```
|
||||
|
||||
------
|
||||
|
||||
This tasks also accepts the `force` environment variable which will skip the
|
||||
confirmation dialog:
|
||||
|
||||
|
|
|
|||
|
|
@ -260,7 +260,7 @@ To check the status of migrations, you can use the following rake task:
|
|||
sudo gitlab-rake db:migrate:status
|
||||
```
|
||||
|
||||
This will output a table with a `Status` of `up` or `down` for
|
||||
This will output a table with a `Status` of `up` or `down` for
|
||||
each Migration ID.
|
||||
|
||||
```bash
|
||||
|
|
@ -269,4 +269,4 @@ database: gitlabhq_production
|
|||
Status Migration ID Migration Name
|
||||
--------------------------------------------------
|
||||
up migration_id migration_name
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ sudo -u git -H bundle exec rake "gitlab:uploads:migrate[FileUploader, MergeReque
|
|||
|
||||
> Introduced in GitLab 12.3.
|
||||
|
||||
To migrate all uploads created by legacy uploaders, run:
|
||||
To migrate all uploads created by legacy uploaders, run:
|
||||
|
||||
```shell
|
||||
bundle exec rake gitlab:uploads:legacy:migrate
|
||||
|
|
|
|||
|
|
@ -266,9 +266,9 @@ ElasticSearch administrator.
|
|||
|
||||
Generally speaking, ensure:
|
||||
|
||||
* The ElasticSearch server **is not** running on the same node as GitLab.
|
||||
* The ElasticSearch server have enough RAM and CPU cores.
|
||||
* That sharding **is** being used.
|
||||
- The ElasticSearch server **is not** running on the same node as GitLab.
|
||||
- The ElasticSearch server have enough RAM and CPU cores.
|
||||
- That sharding **is** being used.
|
||||
|
||||
Going into some more detail here, if ElasticSearch is running on the same server as GitLab, resource contention is **very** likely to occur. Ideally, ElasticSearch, which requires ample resources, should be running on its own server (maybe coupled with logstash and kibana).
|
||||
|
||||
|
|
|
|||
|
|
@ -96,8 +96,9 @@ corresponding Ruby code where this is happening.
|
|||
`gdb` can be another effective tool for debugging Sidekiq. It gives you a little
|
||||
more interactive way to look at each thread and see what's causing problems.
|
||||
|
||||
> **Note:** Attaching to a process with `gdb` will suspends the normal operation
|
||||
of the process (Sidekiq will not process jobs while `gdb` is attached).
|
||||
NOTE: **Note:**
|
||||
Attaching to a process with `gdb` will suspends the normal operation
|
||||
of the process (Sidekiq will not process jobs while `gdb` is attached).
|
||||
|
||||
Start by attaching to the Sidekiq PID:
|
||||
|
||||
|
|
@ -280,10 +281,10 @@ has number of drawbacks, as mentioned in [Why Ruby’s Timeout is dangerous (and
|
|||
|
||||
> This is where the implications get interesting, and terrifying. This means that an exception can get raised:
|
||||
>
|
||||
> * during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
|
||||
> * during the cleanup for the network request
|
||||
> * during a rescue block
|
||||
> * while creating an object to save to the database afterwards
|
||||
> * in any of your code, regardless of whether it could have possibly raised an exception before
|
||||
> - during a network request (ok, as long as the surrounding code is prepared to catch Timeout::Error)
|
||||
> - during the cleanup for the network request
|
||||
> - during a rescue block
|
||||
> - while creating an object to save to the database afterwards
|
||||
> - in any of your code, regardless of whether it could have possibly raised an exception before
|
||||
>
|
||||
> Nobody writes code to defend against an exception being raised on literally any line. That’s not even possible. So Thread.raise is basically like a sneak attack on your code that could result in almost anything. It would probably be okay if it were pure-functional code that did not modify any state. But this is Ruby, so that’s unlikely :)
|
||||
|
|
|
|||
|
|
@ -516,4 +516,3 @@ The API can be explored interactively using the [GraphiQL IDE](../index.md#graph
|
|||
| `username` | String! | |
|
||||
| `avatarUrl` | String! | |
|
||||
| `webUrl` | String! | |
|
||||
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ It has a pipeline that looks like the following:
|
|||
| ----- | ---- | ------ |
|
||||
| build_a | test_a | deploy_a |
|
||||
| build_b | test_b | deploy_b |
|
||||
| build_c | test_c | deploy_c |
|
||||
| build_c | test_c | deploy_c |
|
||||
| build_d | test_d | deploy_d |
|
||||
|
||||
Using a DAG, you can relate the `_a` jobs to each other separately from the `_b` jobs,
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ There are some high level differences between the products worth mentioning:
|
|||
|
||||
## Groovy vs. YAML
|
||||
|
||||
Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code.
|
||||
Jenkins Pipelines are based on [Groovy](https://groovy-lang.org/), so the pipeline specification is written as code.
|
||||
GitLab works a bit differently, we use the more highly structured [YAML](https://yaml.org/) format, which
|
||||
places scripting elements inside of `script:` blocks separate from the pipeline specification itself.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ rspec:
|
|||
- .in-docker
|
||||
script:
|
||||
- rake rspec
|
||||
```
|
||||
```
|
||||
|
||||
## Artifact publishing
|
||||
|
||||
|
|
@ -143,7 +143,7 @@ default:
|
|||
|
||||
GitLab CI also lets you define stages, but is a little bit more free-form to configure. The GitLab [`stages` keyword](../yaml/README.md#stages)
|
||||
is a top level setting that enumerates the list of stages, but you are not required to nest individual jobs underneath
|
||||
the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
|
||||
the `stages` section. Any job defined in the `.gitlab-ci.yml` can be made a part of any stage through use of the
|
||||
[`stage:` keyword](../yaml/README.md#stage).
|
||||
|
||||
Note that, unless otherwise specified, every pipeline is instantiated with a `build`, `test`, and `deploy` stage
|
||||
|
|
@ -229,4 +229,4 @@ our very powerful [`only/except` rules system](../yaml/README.md#onlyexcept-basi
|
|||
```yaml
|
||||
my_job:
|
||||
only: branches
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -141,4 +141,4 @@ please ask administrator to execute the following commands:
|
|||
> sudo gitlab-rails console # Login to Rails console of GitLab instance.
|
||||
> Feature.enabled?(:merge_trains_enabled) # Check if it's enabled or not.
|
||||
> Feature.disable(:merge_trains_enabled) # Disable the feature flag.
|
||||
```
|
||||
```
|
||||
|
|
|
|||
|
|
@ -27,8 +27,8 @@ variables:
|
|||
|
||||
NOTE: **Note:**
|
||||
The `MYSQL_DATABASE` and `MYSQL_ROOT_PASSWORD` variables can't be set in the GitLab UI.
|
||||
To set them, assign them to a variable [in the UI](../variables/README.md#via-the-ui),
|
||||
and then assign that variable to the
|
||||
To set them, assign them to a variable [in the UI](../variables/README.md#via-the-ui),
|
||||
and then assign that variable to the
|
||||
`MYSQL_DATABASE` and `MYSQL_ROOT_PASSWORD` variables in your `.gitlab-ci.yml`.
|
||||
|
||||
And then configure your application to use the database, for example:
|
||||
|
|
|
|||
|
|
@ -58,8 +58,7 @@ Read more about the [pipelines trigger API][trigapi].
|
|||
|
||||
#### When a pipeline depends on the artifacts of another pipeline **(PREMIUM)**
|
||||
|
||||
> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346]
|
||||
in [GitLab Premium][ee] 9.5.
|
||||
> The use of `CI_JOB_TOKEN` in the artifacts download API was [introduced][ee-2346] in [GitLab Premium][ee] 9.5.
|
||||
|
||||
With the introduction of dependencies between different projects, one of
|
||||
them may need to access artifacts created by a previous one. This process
|
||||
|
|
@ -271,7 +270,7 @@ Old triggers, created before GitLab 9.0 will be marked as legacy.
|
|||
|
||||
Triggers with the legacy label do not have an associated user and only have
|
||||
access to the current project. They are considered deprecated and will be
|
||||
removed with one of the future versions of GitLab.
|
||||
removed with one of the future versions of GitLab.
|
||||
|
||||
[ee-2017]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2017
|
||||
[ee-2346]: https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/2346
|
||||
|
|
|
|||
|
|
@ -65,7 +65,7 @@ Sign up for the mailing list, answer GitLab questions on StackOverflow or
|
|||
respond in the IRC channel. You can also sign up on [CodeTriage][codetriage] to help with
|
||||
the remaining issues on the GitHub issue tracker.
|
||||
|
||||
## I want to contribute!
|
||||
## I want to contribute
|
||||
|
||||
If you want to contribute to GitLab,
|
||||
[issues with the `Accepting merge requests` label](issue_workflow.md#label-for-community-contributors)
|
||||
|
|
|
|||
|
|
@ -783,8 +783,6 @@ For multiple paragraphs, use the symbol `>` before every line:
|
|||
>
|
||||
> - This is a list item
|
||||
> - Second item in the list
|
||||
>
|
||||
> ### This is an `h3`
|
||||
```
|
||||
|
||||
Which renders to:
|
||||
|
|
@ -795,9 +793,6 @@ Which renders to:
|
|||
>
|
||||
> - This is a list item
|
||||
> - Second item in the list
|
||||
>
|
||||
> ### This is an `h3`
|
||||
>{:.no_toc}
|
||||
|
||||
## Terms
|
||||
|
||||
|
|
|
|||
|
|
@ -81,7 +81,7 @@ bundle and included on the page.
|
|||
> can find this out by inspecting `document.body.dataset.page` within your
|
||||
> browser's developer console while on any page within gitlab.
|
||||
|
||||
#### Important Considerations:
|
||||
#### Important Considerations
|
||||
|
||||
- **Keep Entry Points Lite:**
|
||||
Page-specific javascript entry points should be as lite as possible. These
|
||||
|
|
|
|||
|
|
@ -92,4 +92,3 @@ To propose additions to the glossary please
|
|||
In French, the "écriture inclusive" is now over (see on [Legifrance](https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000036068906&categorieLien=id)).
|
||||
So, to include both genders, write “Utilisateurs et utilisatrices” instead of “Utilisateur·rice·s”.
|
||||
When space is missing, the male gender should be used alone.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Dependencies
|
||||
|
||||
## Adding Dependencies.
|
||||
## Adding Dependencies
|
||||
|
||||
GitLab uses `yarn` to manage dependencies. These dependencies are defined in
|
||||
two groups within `package.json`, `dependencies` and `devDependencies`. For
|
||||
|
|
|
|||
|
|
@ -3,4 +3,3 @@ redirect_to: '../../testing_guide/frontend_testing.md'
|
|||
---
|
||||
|
||||
This document was moved to [another location](../../testing_guide/frontend_testing.md).
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ It's important to understand that end-to-end tests of isolated features, such as
|
|||
|
||||
If you don't exactly understand what we mean by **not everything needs to happen through the GUI,** please make sure you've read the [best practices](best_practices.md) before moving on.
|
||||
|
||||
## This document covers the following items:
|
||||
## This document covers the following items
|
||||
|
||||
- [0.](#0-are-end-to-end-tests-needed) Identifying if end-to-end tests are really needed
|
||||
- [1.](#1-identifying-the-devops-stage) Identifying the [DevOps stage](https://about.gitlab.com/stages-devops-lifecycle/) of the feature that you are going to cover with end-to-end tests
|
||||
|
|
|
|||
|
|
@ -141,4 +141,4 @@ Resource::MergeRequest.fabricate! do |merge_request_page|
|
|||
end
|
||||
```
|
||||
|
||||
> Besides the advantage of having a standard in place, by following this standard we also write shorter lines of code.
|
||||
> Besides the advantage of having a standard in place, by following this standard we also write shorter lines of code.
|
||||
|
|
|
|||
|
|
@ -132,7 +132,7 @@ to prevent other pods from being scheduled on this node pool.
|
|||
This is to ensure Tiller isn't affected by "noisy" neighbors that could put
|
||||
their node under pressure.
|
||||
|
||||
## How to:
|
||||
## How to
|
||||
|
||||
### Log into my Review App
|
||||
|
||||
|
|
|
|||
|
|
@ -126,7 +126,7 @@ possible).
|
|||
| ---------- | -------------- | ----- |
|
||||
| `spec/features/` | [Capybara] + [RSpec] | If your test has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. |
|
||||
|
||||
### Consider **not** writing a system test!
|
||||
### Consider **not** writing a system test
|
||||
|
||||
If we're confident that the low-level components work well (and we should be if
|
||||
we have enough Unit & Integration tests), we shouldn't need to duplicate their
|
||||
|
|
|
|||
Loading…
Reference in New Issue