Commit 0553d098 authored by Marcel Amirault's avatar Marcel Amirault

Merge branch '20200324-aqualls-codeblocks' into 'master'

Add languages to code blocks

See merge request gitlab-org/gitlab!27915
parents ea48cd31 57dbda7f
......@@ -612,7 +612,7 @@ To check the configuration:
If everything is working, you should see something like this:
```
```plaintext
gitlabhq_geo_production=# SELECT * from information_schema.foreign_tables;
foreign_table_catalog | foreign_table_schema | foreign_table_name | foreign_server_catalog | foreign_server_name
-------------------------+----------------------+-------------------------------------------------+-------------------------+---------------------
......
......@@ -920,7 +920,7 @@ after it has been restored to service.
Once `repmgrd` and PostgreSQL are runnning, the node will need to follow the new
as a standby node.
```
```shell
gitlab-ctl repmgr standby follow NEW_MASTER
```
......@@ -930,7 +930,7 @@ after it has been restored to service.
Once the old master node has been unregistered from the cluster, it will need
to be setup as a new standby:
```
```shell
gitlab-ctl repmgr standby setup NEW_MASTER
```
......
......@@ -93,7 +93,7 @@ open up the page for the project.
The "Gitaly relative path" is shown there, for example:
```
```plaintext
"@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
```
......@@ -126,7 +126,7 @@ with `.git` from the end of the directory name removed.
The output includes the project id and the project name:
```
```plaintext
=> #<Project id:16 it/supportteam/ticketsystem>
```
......
......@@ -121,8 +121,8 @@ In this case, the guidance we had from development was to drop deadlock_timeout
PostgresSQL defaults:
- statement_timeout = 0 (never)
- idle_in_transaction_session_timeout = 0 (never)
- `statement_timeout = 0` (never)
- `idle_in_transaction_session_timeout = 0` (never)
Comments in issue [#1](https://gitlab.com/gitlab-org/gitlab/issues/30528) indicate that these should both be set to at least a number of minutes for all Omnibus installations (so they don't hang indefinitely). However, 15s for statement_timeout is very short, and will only be effective if the underlying infrastructure is very performant.
......@@ -136,7 +136,7 @@ puts c.execute('SHOW idle_in_transaction_session_timeout').to_a ;"
It may take a little while to respond.
```
```ruby
{"statement_timeout"=>"1min"}
{"lock_timeout"=>"0"}
{"idle_in_transaction_session_timeout"=>"1min"}
......
......@@ -82,7 +82,7 @@ Example response:
Creates a new deploy token for a project.
```
```plaintext
POST /projects/:id/deploy_tokens
```
......@@ -119,7 +119,7 @@ Example response:
Removes a deploy token from the project.
```
```plaintext
DELETE /projects/:id/deploy_tokens/:token_id
```
......@@ -144,7 +144,7 @@ These endpoints require group maintainer access or higher.
Get a list of a group's deploy tokens
```
```plaintext
GET /groups/:id/deploy_tokens
```
......@@ -183,7 +183,7 @@ Example response:
Creates a new deploy token for a group.
```
```plaintext
POST /groups/:id/deploy_tokens
```
......@@ -222,7 +222,7 @@ Example response:
Removes a deploy token from the group.
```
```plaintext
DELETE /groups/:id/deploy_tokens/:token_id
```
......
......@@ -447,7 +447,7 @@ Where `MD_DOC_PATH` points to the file or directory you would like to run lint c
If you omit it completely, it will default to the `doc/` directory.
The output should be similar to:
```
```plaintext
=> Linting documents at path /path/to/gitlab as <user>...
=> Checking for cURL short options...
=> Checking for CHANGELOG.md duplicate entries...
......
......@@ -521,7 +521,7 @@ For ordered lists, use three spaces for each level of indentation:
You can nest full lists inside other lists using the same rules as above. If you wish
to mix types, that is also possible, as long as you don't mix items at the same level:
```
```markdown
1. Ordered list item one.
1. Ordered list item two.
- Nested unordered list item one.
......
......@@ -184,7 +184,7 @@ If the current version is `v12p1`, and we need to create a new version for `v12p
You might get an error such as
```
```plaintext
[2018-10-31T15:54:19,762][WARN ][o.e.c.r.a.DiskThresholdMonitor] [pval5Ct]
flood stage disk watermark [95%] exceeded on
[pval5Ct7SieH90t5MykM5w][pval5Ct][/usr/local/var/lib/elasticsearch/nodes/0] free: 56.2gb[3%],
......@@ -195,20 +195,20 @@ This is because you've exceeded the disk space threshold - it thinks you don't h
In addition, the `read_only_allow_delete` setting will be set to `true`. It will block indexing, `forcemerge`, etc
```
```shell
curl "http://localhost:9200/gitlab-development/_settings?pretty"
```
Add this to your `elasticsearch.yml` file:
```
```yaml
# turn off the disk allocator
cluster.routing.allocation.disk.threshold_enabled: false
```
_or_
```
```yaml
# set your own limits
cluster.routing.allocation.disk.threshold_enabled: true
cluster.routing.allocation.disk.watermark.flood_stage: 5gb # ES 6.x only
......
......@@ -58,7 +58,7 @@ The author then adds a comment to this piece of code and adds a link to the issu
- Track necessary events. See the [telemetry guide](../../telemetry/index.md) for details.
- After the merge request is merged, use [`chatops`](../../ci/chatops/README.md) to enable the feature flag and start the experiment. For visibility, please run the command in the `#s_growth` channel:
```
```shell
/chatops run feature set --project=gitlab-org/gitlab experimental_sign_up_flow true
```
......
......@@ -10,9 +10,9 @@ Copy the content over to your issue or merge request and if something doesn't ap
This checklist is intended to help us during development of bigger features/refactorings, it's not a "use it always and every point always matches" list.
Please use your best judgement when to use it and please contribute new points through merge requests if something comes to your mind.
Please use your best judgment when to use it and please contribute new points through merge requests if something comes to your mind.
```
```markdown
### Frontend development
#### Planning development
......
......@@ -149,7 +149,7 @@ Using local Apollo Cache is handy when we have a need to mock some GraphQL API r
For example, we have a [fragment](#fragments) on `DesignVersion` used in our queries:
```
```javascript
fragment VersionListItem on DesignVersion {
id
sha
......@@ -158,7 +158,7 @@ fragment VersionListItem on DesignVersion {
We need to fetch also version author and the 'created at' property to display them in the versions dropdown but these changes are still not implemented in our API. We can change the existing fragment to get a mocked response for these new fields:
```
```javascript
fragment VersionListItem on DesignVersion {
id
sha
......
......@@ -294,7 +294,7 @@ Please check this [rules](https://github.com/vuejs/eslint-plugin-vue#bulb-rules)
1. Tag order in `.vue` file
```
```html
<script>
// ...
</script>
......
......@@ -64,36 +64,36 @@ The easiest way to include prettier in your workflow is by setting up your prefe
Please take care that you only let Prettier format the same file types as the global Yarn script does (.js, .vue, and .scss). In VSCode by example you can easily exclude file formats in your settings file:
```
```json
"prettier.disableLanguages": [
"json",
"markdown"
],
]
```
### Yarn Script
The following yarn scripts are available to do global formatting:
```
```shell
yarn prettier-staged-save
```
Updates all currently staged files (based on `git diff`) with Prettier and saves the needed changes.
```
```shell
yarn prettier-staged
```
Checks all currently staged files (based on `git diff`) with Prettier and log which files would need manual updating to the console.
```
```shell
yarn prettier-all
```
Checks all files with Prettier and logs which files need manual updating to the console.
```
```shell
yarn prettier-all-save
```
......@@ -103,13 +103,13 @@ The source of these Yarn scripts can be found in `/scripts/frontend/prettier.js`
#### Scripts during Conversion period
```
```shell
node ./scripts/frontend/prettier.js check-all ./vendor/
```
This will go over all files in a specific folder check it.
```
```shell
node ./scripts/frontend/prettier.js save-all ./vendor/
```
......
......@@ -25,7 +25,7 @@ In some features implemented with Vue.js, like the [issue board][issue-boards]
or [environments table][environments-table]
you can find a clear separation of concerns:
```
```plaintext
new_feature
├── components
│ └── component.vue
......
......@@ -22,7 +22,7 @@ _Note:_ The action itself will not update the state, only a mutation should upda
When using Vuex at GitLab, separate these concerns into different files to improve readability:
```
```plaintext
└── store
├── index.js # where we assemble modules and export the store
├── actions.js # actions
......
......@@ -12,7 +12,7 @@ Follow the Chatops document to [request access](../chatops_on_gitlabcom.md#reque
Once you are added to the project test if your access propagated,
run:
```
```shell
/chatops run feature --help
```
......@@ -70,7 +70,7 @@ and <https://dev.gitlab.org>.
For example, to enable a feature for 25% of all users, run the following in
Slack:
```
```shell
/chatops run feature set new_navigation_bar 25 --dev
/chatops run feature set new_navigation_bar 25 --staging
```
......@@ -92,7 +92,7 @@ feature enabled, you can roll out the change to GitLab.com.
Similar to above, to enable a feature for 25% of all users, run the following in
Slack:
```
```shell
/chatops run feature set new_navigation_bar 25
```
......@@ -117,13 +117,13 @@ Feature gates can also be actor based, for example a feature could first be
enabled for only the `gitlab` project. The project is passed by supplying a
`--project` flag:
```
```shell
/chatops run feature set --project=gitlab-org/gitlab some_feature true
```
For groups the `--group` flag is available:
```
```shell
/chatops run feature set --group=gitlab-org some_feature true
```
......@@ -131,7 +131,7 @@ Note that actor-based gates are applied before percentages. For example, conside
`group/project` as `gitlab-org/gitlab` and a given example feature as `some_feature`, if
you run these 2 commands:
```
```shell
/chatops run feature set --project=gitlab-org/gitlab some_feature true
/chatops run feature set some_feature 25
```
......
......@@ -60,7 +60,7 @@ hash of the project ID instead, if project migrates to the new approach (introdu
Files are stored at multiple locations and use different path schemes.
All the `GitlabUploader` derived classes should comply with this path segment schema:
```
```plaintext
| GitlabUploader
| ----------------------- + ------------------------- + --------------------------------- + -------------------------------- |
| `<gitlab_root>/public/` | `uploads/-/system/` | `user/avatar/:id/` | `:filename` |
......
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