Commit 33e3441c authored by Marcel Amirault's avatar Marcel Amirault Committed by Marcia Ramos

Docs: (EE Port) Fix broken anchors in development docs

parent 65e36e03
......@@ -4,8 +4,8 @@ comments: false
# Technical articles list (deprecated)
[Technical articles](../development/documentation/index.md#technical-articles) are
topic-related documentation, written with an user-friendly approach and language, aiming
Technical articles are
topic-related documentation, written with a user-friendly approach and language, aiming
to provide the community with guidance on specific processes to achieve certain objectives.
The list of technical articles was [deprecated](https://gitlab.com/gitlab-org/gitlab-ce/issues/41138) in favor of having them linked from their topic-related documentation:
......
......@@ -135,21 +135,13 @@ If you're working on the GitLab EE repository, the entry will be added to
| Argument | Shorthand | Purpose |
| ----------------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| [`--amend`] | | Amend the previous commit |
| [`--force`] | `-f` | Overwrite an existing entry |
| [`--merge-request`] | `-m` | Set merge request ID |
| [`--dry-run`] | `-n` | Don't actually write anything, just print |
| [`--git-username`] | `-u` | Use Git user.name configuration as the author |
| [`--type`] | `-t` | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` |
| [`--help`] | `-h` | Print help message |
[`--amend`]: #-amend
[`--force`]: #-force-or-f
[`--merge-request`]: #-merge-request-or-m
[`--dry-run`]: #-dry-run-or-n
[`--git-username`]: #-git-username-or-u
[`--type`]: #-type-or-t
[`--help`]: #-help
| [`--amend`](#--amend) | | Amend the previous commit |
| [`--force`](#--force-or--f) | `-f` | Overwrite an existing entry |
| [`--merge-request`](#--merge-request-or--m) | `-m` | Set merge request ID |
| [`--dry-run`](#--dry-run-or--n) | `-n` | Don't actually write anything, just print |
| [`--git-username`](#--git-username-or--u) | `-u` | Use Git user.name configuration as the author |
| [`--type`](#--type-or--t) | `-t` | The category of the change, valid options are: `added`, `fixed`, `changed`, `deprecated`, `removed`, `security`, `performance`, `other` |
| `--help` | `-h` | Print help message |
##### `--amend`
......
......@@ -179,7 +179,7 @@ the feature you contribute through all of these steps.
1. Added to [the website](https://gitlab.com/gitlab-com/www-gitlab-com/), if relevant
1. Community questions answered
1. Answers to questions radiated (in docs/wiki/support etc.)
1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-or-end-to-end-tests) added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams) with any questions
1. [Black-box tests/end-to-end tests](../testing_guide/testing_levels.md#black-box-tests-at-the-system-level-aka-end-to-end-tests) added if required. Please contact [the quality team](https://about.gitlab.com/handbook/engineering/quality/#teams) with any questions
If you add a dependency in GitLab (such as an operating system package) please
consider updating the following and note the applicability of each in your
......
......@@ -511,10 +511,10 @@ Currently, the following tests are in place:
1. `docs lint`: Check that all internal (relative) links work correctly and
that all cURL examples in API docs use the full switches. It's recommended
to [check locally](#previewing-locally) before pushing to GitLab by executing the command
to [check locally](#previewing-the-changes-live) before pushing to GitLab by executing the command
`bundle exec nanoc check internal_links` on your local
[`gitlab-docs`](https://gitlab.com/gitlab-com/gitlab-docs) directory.
1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-gt-ee-merge-conflicts-beforehand) (runs on CE only):
1. [`ee_compat_check`](../automatic_ce_ee_merge.md#avoiding-ce-ee-merge-conflicts-beforehand) (runs on CE only):
When you submit a merge request to GitLab Community Edition (CE),
there is this additional job that runs against Enterprise Edition (EE)
and checks if your changes can apply cleanly to the EE codebase.
......
......@@ -62,7 +62,7 @@ the consent of one of the technical writers.
The global nav is built from two files:
- [Data](#data-file)
- [Layout](#layout-file)
- [Layout](#layout-file-logic)
The data file feeds the layout with the links to the docs. The layout organizes
the data among the nav in containers properly [styled](#css-classes).
......
......@@ -36,7 +36,7 @@ gem will support all [GFM markup](../../user/markdown.md) in the future. For now
use regular markdown markup, following the rules on this style guide. For a complete
Kramdown reference, check the [GitLab Markdown Kramdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/).
Use Kramdown markup wisely: do not overuse its specific markup (e.g., `{:.class}`) as it will not render properly in
[`/help`](#gitlab-help).
[`/help`](index.md#gitlab-help).
## Content
......@@ -630,7 +630,7 @@ In this case:
- The code blocks are indented one or more spaces under the list item to render
correctly.
- Different highlighting languages are used for each config in the code block.
- The [references](#references) guide is used for reconfigure/restart.
- The [GitLab Restart](#gitlab-restart) section is used to explain a required restart/reconfigure of GitLab.
## API
......
......@@ -161,7 +161,7 @@ still having access the class's implementation with `super`.
There are a few gotchas with it:
- you should always [`extend ::Gitlab::Utils::Override`] and use `override` to
- you should always [`extend ::Gitlab::Utils::Override`](utilities.md#overridehttpsgitlabcomgitlab-orggitlab-ceblobmasterlibgitlabutilsoverriderb) and use `override` to
guard the "overrider" method to ensure that if the method gets renamed in
CE, the EE override won't be silently forgotten.
- when the "overrider" would add a line in the middle of the CE
......@@ -273,8 +273,6 @@ module EE
end
```
[`extend ::Gitlab::Utils::Override`]: utilities.md#override
##### Overriding CE class methods
The same applies to class methods, except we want to use
......@@ -977,7 +975,7 @@ if (renderIfEE) {
To separate EE-specific styles in SCSS files, if a component you're adding styles for
is limited to only EE, it is better to have a separate SCSS file in appropriate directory
within `app/assets/stylesheets`.
See [backporting changes](#backporting-changes) for instructions on how to merge changes safely.
See [backporting changes](#backporting-changes-from-EE-to-CE) for instructions on how to merge changes safely.
In some cases, this is not entirely possible or creating dedicated SCSS file is an overkill,
e.g. a text style of some component is different for EE. In such cases,
......
......@@ -11,12 +11,9 @@ Architectural decisions should be accessible to everyone, so please document
them in the relevant Merge Request discussion or by updating our documentation
when appropriate.
You can find the Frontend Architecture experts on the [team page][team-page].
You can find the Frontend Architecture experts on the [team page](https://about.gitlab.com/team).
## Examples
You can find documentation about the desired architecture for a new feature
built with Vue.js [here][vue-section].
[team-page]: https://about.gitlab.com/team
[vue-section]: vue.md#frontend.html#how-to-build-a-new-feature-with-vue-js
built with Vue.js [here](vue.md).
......@@ -122,7 +122,7 @@ Check this [page](vuex.md) for more details.
## Style guide
Please refer to the Vue section of our [style guide](style_guide_js.md#vue-js)
Please refer to the Vue section of our [style guide](style_guide_js.md#vuejs)
for best practices while writing your Vue components and templates.
## Testing Vue Components
......@@ -132,7 +132,7 @@ Each Vue component has a unique output. This output is always present in the ren
Although we can test each method of a Vue component individually, our goal must be to test the output
of the render/template function, which represents the state at all times.
Make use of the [axios mock adapter](axios.md#mock-axios-response-on-tests) to mock data returned.
Make use of the [axios mock adapter](axios.md#mock-axios-response-in-tests) to mock data returned.
Here's how we would test the Todo App above:
......
......@@ -391,8 +391,8 @@ requests.
### System hooks (GitLab 8.7 to 9.5)
Later was decided to move away from custom code and integrate by using
[System Webhooks](#system-webhooks). More people are using them, so
Later, it was decided to move away from custom code and begin using
system hooks. More people were using them, so
many would benefit from improvements made to this communication layer.
There is a specific **internal** endpoint in our API code (Grape),
......@@ -403,7 +403,7 @@ We switch and filter from each event by the `event_name` field.
### Geo Log Cursor (GitLab 10.0 and up)
Since GitLab 10.0, [System Webhooks](#system-webhooks) are no longer
Since GitLab 10.0, [System Webhooks](#system-hooks-gitlab-87-to-95) are no longer
used and Geo Log Cursor is used instead. The Log Cursor traverses the
`Geo::EventLog` rows to see if there are changes since the last time
the log was checked and will handle repository updates, deletes,
......
......@@ -40,7 +40,7 @@ bundle exec rspec spec/[path]/[to]/[spec].rb
to separate phases.
- Use `Gitlab.config.gitlab.host` rather than hard coding `'localhost'`
- Don't assert against the absolute value of a sequence-generated attribute (see
[Gotchas](../gotchas.md#dont-assert-against-the-absolute-value-of-a-sequence-generated-attribute)).
[Gotchas](../gotchas.md#do-not-assert-against-the-absolute-value-of-a-sequence-generated-attribute)).
- Don't supply the `:each` argument to hooks since it's the default.
- On `before` and `after` hooks, prefer it scoped to `:context` over `:all`
- When using `evaluate_script("$('.js-foo').testSomething()")` (or `execute_script`) which acts on a given element,
......
......@@ -46,7 +46,7 @@ They're useful to test permissions, redirections, what view is rendered etc.
| `app/mailers/` | `spec/mailers/` | RSpec | |
| `lib/api/` | `spec/requests/api/` | RSpec | |
| `lib/ci/api/` | `spec/requests/ci/api/` | RSpec | |
| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [JavaScript](#javascript) section. |
| `app/assets/javascripts/` | `spec/javascripts/` | Karma | More details in the [Karma JavaScript test suite](frontend_testing.md#karma-test-suite) section. |
### About controller tests
......@@ -210,7 +210,7 @@ trade-off:
- Integration tests are a bit more expensive, but don't abuse them. A system test
is often better than an integration test that is stubbing a lot of internals.
- System tests are expensive (compared to unit tests), even more if they require
a JavaScript driver. Make sure to follow the guidelines in the [Speed](#test-speed)
a JavaScript driver. Make sure to follow the guidelines in the [Speed](best_practices.md#test-speed)
section.
Another way to see it is to think about the "cost of tests", this is well
......
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