Commit 0c652914 authored by Evan Read's avatar Evan Read

Merge branch 'docs-fix-doc-lint-script' into 'master'

Fix docs-lint job that was missing half the docs

See merge request gitlab-org/gitlab!26951
parents 31f71291 01e8498f
...@@ -490,10 +490,10 @@ Particular attention should be shown to: ...@@ -490,10 +490,10 @@ Particular attention should be shown to:
1. Configure the `external_url` so that files could be served by GitLab 1. Configure the `external_url` so that files could be served by GitLab
by proper endpoint access by editing `/etc/gitlab/gitlab.rb`: by proper endpoint access by editing `/etc/gitlab/gitlab.rb`:
You will need to replace `GITLAB_SERVER_URL` with the real URL on which You will need to replace `GITLAB_SERVER_URL` with the real URL on which
current GitLab instance is serving: current GitLab instance is serving:
```ruby ```ruby
external_url 'GITLAB_SERVER_URL' external_url 'GITLAB_SERVER_URL'
``` ```
......
...@@ -741,7 +741,7 @@ To enable the read-only mode: ...@@ -741,7 +741,7 @@ To enable the read-only mode:
```sh ```sh
# Recycling unused tags # Recycling unused tags
sudo /opt/gitlab/embedded/bin/registry garbage-collect /var/opt/gitlab/registry/config.yml sudo /opt/gitlab/embedded/bin/registry garbage-collect /var/opt/gitlab/registry/config.yml
# Removing unused layers not referenced by manifests # Removing unused layers not referenced by manifests
sudo /opt/gitlab/embedded/bin/registry garbage-collect -m /var/opt/gitlab/registry/config.yml sudo /opt/gitlab/embedded/bin/registry garbage-collect -m /var/opt/gitlab/registry/config.yml
``` ```
......
...@@ -3,12 +3,12 @@ ...@@ -3,12 +3,12 @@
When there's a clear benefit to separating state management from components (e.g. due to state complexity) we recommend using [Vuex][vuex-docs] over any other Flux pattern. Otherwise, feel free to manage state within the components. When there's a clear benefit to separating state management from components (e.g. due to state complexity) we recommend using [Vuex][vuex-docs] over any other Flux pattern. Otherwise, feel free to manage state within the components.
Vuex should be strongly considered when: Vuex should be strongly considered when:
- You expect multiple parts of the application to react to state changes - You expect multiple parts of the application to react to state changes
- There's a need to share data between multiple components - There's a need to share data between multiple components
- There are complex interactions with Backend, e.g. multiple API calls - There are complex interactions with Backend, e.g. multiple API calls
- The app involves interacting with backend via both traditional REST API and GraphQL (especially when moving the REST API over to GraphQL is a pending backend task) - The app involves interacting with backend via both traditional REST API and GraphQL (especially when moving the REST API over to GraphQL is a pending backend task)
_Note:_ All of the below is explained in more detail in the official [Vuex documentation][vuex-docs]. _Note:_ All of the below is explained in more detail in the official [Vuex documentation][vuex-docs].
## Separation of concerns ## Separation of concerns
......
...@@ -64,7 +64,6 @@ Another example of GitLab as a company would be the following: ...@@ -64,7 +64,6 @@ Another example of GitLab as a company would be the following:
--- ---
When performing actions such as transferring or importing a project between When performing actions such as transferring or importing a project between
subgroups, the behavior is the same as when performing these actions at the subgroups, the behavior is the same as when performing these actions at the
`group/project` level. `group/project` level.
......
...@@ -362,7 +362,7 @@ sam init -h ...@@ -362,7 +362,7 @@ sam init -h
### Setting up your AWS credentials with your GitLab account ### Setting up your AWS credentials with your GitLab account
In order to interact with your AWS account, the GitLab CI/CD pipelines require both In order to interact with your AWS account, the GitLab CI/CD pipelines require both
`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` to be set in the project's CI/CD
variables. variables.
......
...@@ -48,7 +48,7 @@ then ...@@ -48,7 +48,7 @@ then
exit 1 exit 1
fi fi
MD_DOC_PATH=${MD_DOC_PATH:-doc/**/*.md} MD_DOC_PATH=${MD_DOC_PATH:-doc}
function run_locally_or_in_docker() { function run_locally_or_in_docker() {
local cmd=$1 local cmd=$1
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment