Commit 6f3fa06f authored by Marcel Amirault's avatar Marcel Amirault Committed by Achilleas Pipinellis

Change docs markdown linter

Change from ruby mdl to node markdownlint, add
config file to root of project, delete old config
file, update exceptions, and fix one doc that
was didn't meet standards
parent d58fb67f
...@@ -65,7 +65,7 @@ docs lint: ...@@ -65,7 +65,7 @@ docs lint:
- mv doc/ /tmp/gitlab-docs/content/$DOCS_GITLAB_REPO_SUFFIX - mv doc/ /tmp/gitlab-docs/content/$DOCS_GITLAB_REPO_SUFFIX
- cd /tmp/gitlab-docs - cd /tmp/gitlab-docs
# Lint Markdown # Lint Markdown
- bundle exec mdl content/$DOCS_GITLAB_REPO_SUFFIX -c $CI_PROJECT_DIR/.mdlrc - markdownlint --config $CI_PROJECT_DIR/.markdownlint.json content/$DOCS_GITLAB_REPO_SUFFIX/**/*.md
# Build HTML from Markdown # Build HTML from Markdown
- bundle exec nanoc - bundle exec nanoc
# Check the internal links # Check the internal links
......
{
"default": true,
"first-header-h1": true,
"header-style": {
"style": "atx"
},
"ul-style": {
"style": "dash"
},
"line-length": false,
"commands-show-output": false,
"no-duplicate-header": {
"allow_different_nesting": true
},
"no-trailing-punctuation": {
"punctuation": ".,;:!。,;:!?"
},
"ol-prefix": {
"style": "one"
},
"no-inline-html": false,
"hr-style": {
"style": "---"
},
"no-emphasis-as-heading": false,
"fenced-code-language": false,
"first-line-h1": false,
"code-block-style": {
"style": "fenced"
}
}
# This is the options file for mdl, configured in .gitlab/ci/docs.gitlab-ci.yml,
# and related to the style file ./mdlrc.style
# See https://github.com/markdownlint/markdownlint/blob/master/docs/configuration.md
ignore_front_matter true
style File.expand_path('.mdlrc.style', __dir__)
# This is the style file for mdl, configured in .gitlab/ci/docs.gitlab-ci.yml,
# and related to the options file ./mdlrc
# See https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
# for more detailed information on the rules and styles.
rule "MD001"
rule "MD002"
rule "MD003", :style => :atx
rule "MD006"
rule "MD010"
rule "MD011"
rule "MD012"
rule "MD019"
rule "MD022"
rule "MD023"
rule "MD025"
rule "MD028"
rule "MD029", :style => :one
rule "MD030"
# rule "MD032"
rule "MD034"
rule "MD037"
rule "MD038"
# Should not be used currently:
# rule "MD004", :style => :dash # unordered list style - dash
# False positives, see https://github.com/markdownlint/markdownlint/issues/261
# rule "MD039" # Spaces inside link text
# Crashes when link text has certain punctuation
# rubocop:disable Style/SignalException # rubocop:disable Style/SignalException
# frozen_string_literal: true # frozen_string_literal: true
has_only_docs_changes = helper.all_changed_files.all? { |file| file.start_with?('doc/', '.gitlab/ci/docs.gitlab-ci.yml', '.mdlrc') || file.end_with?('.md') } has_only_docs_changes = helper.all_changed_files.all? { |file| file.start_with?('doc/', '.gitlab/ci/docs.gitlab-ci.yml', '.markdownlint.json') || file.end_with?('.md') }
is_docs_only_branch = gitlab.branch_for_head =~ /(^docs[\/-].*|.*-docs$)/ is_docs_only_branch = gitlab.branch_for_head =~ /(^docs[\/-].*|.*-docs$)/
if is_docs_only_branch && !has_only_docs_changes if is_docs_only_branch && !has_only_docs_changes
......
...@@ -20,8 +20,8 @@ every time the project is saved. ...@@ -20,8 +20,8 @@ every time the project is saved.
The summary of those statistics per namespace is then retrieved The summary of those statistics per namespace is then retrieved
by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v12.2.0.pre/app/models/namespace.rb#L70) scope. Analyzing this query we noticed that: by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab-ce/blob/v12.2.0.pre/app/models/namespace.rb#L70) scope. Analyzing this query we noticed that:
* It takes up to `1.2` seconds for namespaces with over `15k` projects. - It takes up to `1.2` seconds for namespaces with over `15k` projects.
* It can't be analyzed with [ChatOps](chatops_on_gitlabcom.md), as it times out. - It can't be analyzed with [ChatOps](chatops_on_gitlabcom.md), as it times out.
Additionally, the pattern that is currently used to update the project statistics Additionally, the pattern that is currently used to update the project statistics
(the callback) doesn't scale adequately. It is currently one of the largest (the callback) doesn't scale adequately. It is currently one of the largest
...@@ -62,8 +62,8 @@ REFRESH MATERIALIZED VIEW root_namespace_storage_statistics; ...@@ -62,8 +62,8 @@ REFRESH MATERIALIZED VIEW root_namespace_storage_statistics;
While this implied a single query update (and probably a fast one), it has some downsides: While this implied a single query update (and probably a fast one), it has some downsides:
* Materialized views syntax varies from PostgreSQL and MySQL. While this feature was worked on, MySQL was still supported by GitLab. - Materialized views syntax varies from PostgreSQL and MySQL. While this feature was worked on, MySQL was still supported by GitLab.
* Rails does not have native support for materialized views. We'd need to use a specialized gem to take care of the management of the database views, which implies additional work. - Rails does not have native support for materialized views. We'd need to use a specialized gem to take care of the management of the database views, which implies additional work.
### Attempt B: An update through a CTE ### Attempt B: An update through a CTE
...@@ -131,8 +131,8 @@ WHERE namespace_id IN ( ...@@ -131,8 +131,8 @@ WHERE namespace_id IN (
Even though this approach would make aggregating much easier, it has some major downsides: Even though this approach would make aggregating much easier, it has some major downsides:
* We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost will not be great. The background migration will take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29772>. - We'd have to migrate **all namespaces** by adding and filling a new column. Because of the size of the table, dealing with time/cost will not be great. The background migration will take approximately `153h`, see <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/29772>.
* Background migration has to be shipped one release before, delaying the functionality by another milestone. - Background migration has to be shipped one release before, delaying the functionality by another milestone.
### Attempt E (final): Update the namespace storage statistics in async way ### Attempt E (final): Update the namespace storage statistics in async way
...@@ -155,10 +155,10 @@ but we refresh them through Sidekiq jobs and in different transactions: ...@@ -155,10 +155,10 @@ but we refresh them through Sidekiq jobs and in different transactions:
This implementation has the following benefits: This implementation has the following benefits:
* All the updates are done async, so we're not increasing the length of the transactions for `project_statistics`. - All the updates are done async, so we're not increasing the length of the transactions for `project_statistics`.
* We're doing the update in a single SQL query. - We're doing the update in a single SQL query.
* It is compatible with PostgreSQL and MySQL. - It is compatible with PostgreSQL and MySQL.
* No background migration required. - No background migration required.
The only downside of this approach is that namespaces' statistics are updated up to `1.5` hours after the change is done, The only downside of this approach is that namespaces' statistics are updated up to `1.5` hours after the change is done,
which means there's a time window in which the statistics are inaccurate. Because we're still not which means there's a time window in which the statistics are inaccurate. Because we're still not
...@@ -171,8 +171,8 @@ performant approach of aggregating the root namespaces. ...@@ -171,8 +171,8 @@ performant approach of aggregating the root namespaces.
All the details regarding this use case can be found on: All the details regarding this use case can be found on:
* <https://gitlab.com/gitlab-org/gitlab-ce/issues/62214> - <https://gitlab.com/gitlab-org/gitlab-ce/issues/62214>
* Merge Request with the implementation: <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28996> - Merge Request with the implementation: <https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28996>
Performance of the namespace storage statistics were measured in staging and production (GitLab.com). All results were posted Performance of the namespace storage statistics were measured in staging and production (GitLab.com). All results were posted
on <https://gitlab.com/gitlab-org/gitlab-ce/issues/64092>: No problem has been reported so far. on <https://gitlab.com/gitlab-org/gitlab-ce/issues/64092>: No problem has been reported so far.
...@@ -268,4 +268,3 @@ sequenceDiagram ...@@ -268,4 +268,3 @@ sequenceDiagram
This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled. This option affect the response to the `/authorize` call. When not enabled, the API response will not contain presigned URLs and workhorse will write the file the shared disk, on the path is provided by rails, acting like object storage was disabled.
Once the request reachs rails, it will schedule an object storage upload as a sidekiq job. Once the request reachs rails, it will schedule an object storage upload as a sidekiq job.
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