diff options
| author | Evan Read <eread@gitlab.com> | 2019-02-22 13:17:10 +0000 |
|---|---|---|
| committer | Achilleas Pipinellis <axil@gitlab.com> | 2019-02-22 13:17:10 +0000 |
| commit | eb866309591f64a3cafb3c950b2cb6a0185595e8 (patch) | |
| tree | 669e1fed24babeb9d36abce149e4e01979aa6787 | |
| parent | 0152d6ff1187c1baf25415189a0d73972875c328 (diff) | |
| download | gitlab-ce-eb866309591f64a3cafb3c950b2cb6a0185595e8.tar.gz | |
Ensure all lists are surrounded by new lines
Markdown renderers find it easier to determine
where lists start and end when lists are surrounded
by new lines.
For consistency, also ensure entries in the list
are aligned when they span multipls lines.
68 files changed, 388 insertions, 353 deletions
diff --git a/doc/administration/auth/authentiq.md b/doc/administration/auth/authentiq.md index 94a8803fff1..726622d8599 100644 --- a/doc/administration/auth/authentiq.md +++ b/doc/administration/auth/authentiq.md @@ -51,7 +51,7 @@ Authentiq will generate a Client ID and the accompanying Client Secret for you t ``` 1. The `scope` is set to request the user's name, email (required and signed), and permission to send push notifications to sign in on subsequent visits. -See [OmniAuth Authentiq strategy](https://github.com/AuthentiqID/omniauth-authentiq/wiki/Scopes,-callback-url-configuration-and-responses) for more information on scopes and modifiers. + See [OmniAuth Authentiq strategy](https://github.com/AuthentiqID/omniauth-authentiq/wiki/Scopes,-callback-url-configuration-and-responses) for more information on scopes and modifiers. 1. Change `YOUR_CLIENT_ID` and `YOUR_CLIENT_SECRET` to the Client credentials you received in step 1. diff --git a/doc/administration/auth/ldap.md b/doc/administration/auth/ldap.md index 37e596f198f..d5d0d99ac24 100644 --- a/doc/administration/auth/ldap.md +++ b/doc/administration/auth/ldap.md @@ -451,7 +451,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt -b "$ba ### Invalid credentials when logging in - Make sure the user you are binding with has enough permissions to read the user's -tree and traverse it. + tree and traverse it. - Check that the `user_filter` is not blocking otherwise valid users. - Run the following check command to make sure that the LDAP settings are correct and GitLab can see your users: diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md index 1f431f8bd62..ab43ec2cc4f 100644 --- a/doc/administration/monitoring/performance/grafana_configuration.md +++ b/doc/administration/monitoring/performance/grafana_configuration.md @@ -34,7 +34,7 @@ Test Connection to ensure the configuration is correct. - **Default**: Checked - **Type**: InfluxDB 0.9.x (Even if you're using InfluxDB 0.10.x) - **Url**: `https://localhost:8086` (Or the remote URL if you've installed InfluxDB -on a separate server) + on a separate server) - **Access**: proxy - **Database**: gitlab - **User**: admin (Or the username configured when setting up InfluxDB) diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md index 6a55dbe1eb4..95f497a1470 100644 --- a/doc/administration/monitoring/performance/performance_bar.md +++ b/doc/administration/monitoring/performance/performance_bar.md @@ -10,11 +10,11 @@ It allows you to see (from left to right): - the current host serving the page - the timing of the page (backend, frontend) - time taken and number of DB queries, click through for details of these queries - +  - time taken and number of [Gitaly] calls, click through for details of these calls - +  - profile of the code used to generate the page, line by line. In the profile view, the numbers in the left panel represent wall time, cpu time, and number of calls (based on [rblineprof](https://github.com/tmm1/rblineprof)). - +  - time taken and number of calls to Redis - time taken and number of background jobs created by Sidekiq - time taken and number of Ruby GC calls diff --git a/doc/administration/operations/index.md b/doc/administration/operations/index.md index a16fc7ae74f..32f36d68c50 100644 --- a/doc/administration/operations/index.md +++ b/doc/administration/operations/index.md @@ -3,20 +3,20 @@ Keep your GitLab instance up and running smoothly. - [Clean up Redis sessions](cleaning_up_redis_sessions.md): Prior to GitLab 7.3, -user sessions did not automatically expire from Redis. If -you have been running a large GitLab server (thousands of users) since before -GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis -database after you upgrade to GitLab 7.3. + user sessions did not automatically expire from Redis. If + you have been running a large GitLab server (thousands of users) since before + GitLab 7.3 we recommend cleaning up stale sessions to compact the Redis + database after you upgrade to GitLab 7.3. - [Moving repositories](moving_repositories.md): Moving all repositories managed -by GitLab to another file system or another server. + by GitLab to another file system or another server. - [Sidekiq MemoryKiller](sidekiq_memory_killer.md): Configure Sidekiq MemoryKiller -to restart Sidekiq. + to restart Sidekiq. - [Unicorn](unicorn.md): Understand Unicorn and unicorn-worker-killer. - Speed up SSH operations by [Authorizing SSH users via a fast, -indexed lookup to the GitLab database](fast_ssh_key_lookup.md), and/or -by [doing away with user SSH keys stored on GitLab entirely in favor -of SSH certificates](ssh_certificates.md). + indexed lookup to the GitLab database](fast_ssh_key_lookup.md), and/or + by [doing away with user SSH keys stored on GitLab entirely in favor + of SSH certificates](ssh_certificates.md). - [Filesystem Performance Benchmarking](filesystem_benchmarking.md): Filesystem -performance can have a big impact on GitLab performance, especially for actions -that read or write Git repositories. This information will help benchmark -filesystem performance against known good and bad real-world systems. + performance can have a big impact on GitLab performance, especially for actions + that read or write Git repositories. This information will help benchmark + filesystem performance against known good and bad real-world systems. diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index 5c809f25fbd..279ad018aed 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -337,10 +337,10 @@ The default is 100MB. You may want to run GitLab Pages daemon on a separate server in order to decrease the load on your main application server. Follow the steps below to configure GitLab Pages in a separate server. -1. Suppose you have the main GitLab application server named `app1`. Prepare -new Linux server (let's call it `app2`), create NFS share there and configure access to -this share from `app1`. Let's use the default GitLab Pages folder `/var/opt/gitlab/gitlab-rails/shared/pages` -as the shared folder on `app2` and mount it to `/mnt/pages` on `app1`. +1. Suppose you have the main GitLab application server named `app1`. Prepare + new Linux server (let's call it `app2`), create NFS share there and configure access to + this share from `app1`. Let's use the default GitLab Pages folder `/var/opt/gitlab/gitlab-rails/shared/pages` + as the shared folder on `app2` and mount it to `/mnt/pages` on `app1`. 1. On `app2` install GitLab omnibus and modify `/etc/gitlab/gitlab.rb` this way: @@ -365,7 +365,7 @@ as the shared folder on `app2` and mount it to `/mnt/pages` on `app1`. pages_external_url "http://<your-pages-domain>" gitlab_rails['pages_path'] = "/mnt/pages" ``` - + 1. Run `sudo gitlab-ctl reconfigure`. ## Backup diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md index 9f2b4d9075a..60800d445b8 100644 --- a/doc/administration/pages/source.md +++ b/doc/administration/pages/source.md @@ -88,12 +88,13 @@ since that is needed in all configurations. ### Wildcard domains ->**Requirements:** -> - [Wildcard DNS setup](#dns-configuration) -> -> --- -> -> URL scheme: `http://page.example.io` +**Requirements:** + +- [Wildcard DNS setup](#dns-configuration) + +--- + +URL scheme: `http://page.example.io` This is the minimum setup that you can use Pages with. It is the base for all other setups as described below. Nginx will proxy all requests to the daemon. diff --git a/doc/administration/polling.md b/doc/administration/polling.md index 35aaa20df2c..a1077614677 100644 --- a/doc/administration/polling.md +++ b/doc/administration/polling.md @@ -10,15 +10,15 @@ say that issue notes poll every 2 seconds, and issue titles poll every 5 seconds; these are _not_ the actual values. - 1 is the default, and recommended for most installations. (Issue notes poll -every 2 seconds, and issue titles poll every 5 seconds.) + every 2 seconds, and issue titles poll every 5 seconds.) - 0 will disable UI polling completely. (On the next poll, clients will stop -polling for updates.) + polling for updates.) - A value greater than 1 will slow polling down. If you see issues with -database load from lots of clients polling for updates, increasing the -multiplier from 1 can be a good compromise, rather than disabling polling -completely. (For example: If this is set to 2, then issue notes poll every 4 -seconds, and issue titles poll every 10 seconds.) + database load from lots of clients polling for updates, increasing the + multiplier from 1 can be a good compromise, rather than disabling polling + completely. (For example: If this is set to 2, then issue notes poll every 4 + seconds, and issue titles poll every 10 seconds.) - A value between 0 and 1 will make the UI poll more frequently (so updates -will show in other sessions faster), but is **not recommended**. 1 should be -fast enough. (For example, if this is set to 0.5, then issue notes poll every -1 second, and issue titles poll every 2.5 seconds.) + will show in other sessions faster), but is **not recommended**. 1 should be + fast enough. (For example, if this is set to 0.5, then issue notes poll every + 1 second, and issue titles poll every 2.5 seconds.) diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md index 0d863594fc7..b295b7d5dc4 100644 --- a/doc/administration/raketasks/maintenance.md +++ b/doc/administration/raketasks/maintenance.md @@ -60,6 +60,7 @@ Runs the following rake tasks: It will check that each component was set up according to the installation guide and suggest fixes for issues found. You may also have a look at our Troubleshooting Guides: + - [Troubleshooting Guide (GitLab)](http://docs.gitlab.com/ee/README.html#troubleshooting) - [Troubleshooting Guide (Omnibus Gitlab)](http://docs.gitlab.com/omnibus/README.html#troubleshooting) diff --git a/doc/api/repository_files.md b/doc/api/repository_files.md index 8c1d982f394..6fcc06ea8cd 100644 --- a/doc/api/repository_files.md +++ b/doc/api/repository_files.md @@ -171,6 +171,7 @@ Parameters: If the commit fails for any reason we return a 400 error with a non-specific error message. Possible causes for a failed commit include: + - the `file_path` contained `/../` (attempted directory traversal); - the new file contents were identical to the current file contents, i.e. the user tried to make an empty commit; diff --git a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md index c0346d78141..f24e79355aa 100644 --- a/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md +++ b/doc/ci/examples/test_phoenix_app_with_gitlab_ci_cd/index.md @@ -75,7 +75,7 @@ When we call `mix` command, we'll pass two arguments: - The task we want it to run: `phoenix.new` - And the parameter `phoenix.new` requires, which is the name of the new project. In this case, -we're calling it `hello_gitlab_ci`, but you're free to set your own name: + we're calling it `hello_gitlab_ci`, but you're free to set your own name: ```bash mix phoenix.new hello_gitlab_ci @@ -249,7 +249,7 @@ project.  - On next screen, we can select a template ready to go. Click on **Apply a GitLab CI/CD Yaml -template** and select **Elixir**: + template** and select **Elixir**:  diff --git a/doc/ci/merge_request_pipelines/index.md b/doc/ci/merge_request_pipelines/index.md index b7b5c660586..2af0a03cbe4 100644 --- a/doc/ci/merge_request_pipelines/index.md +++ b/doc/ci/merge_request_pipelines/index.md @@ -106,10 +106,10 @@ flow, external contributors follow the following steps: 1. Fork a parent project. 1. Create a merge request from the forked project that targets the `master` branch -in the parent project. + in the parent project. 1. A pipeline runs on the merge request. 1. A maintainer from the parent project checks the pipeline result, and merge -into a target branch if the latest pipeline has passed. + into a target branch if the latest pipeline has passed. Currently, those pipelines are created in a **forked** project, not in the parent project. This means you cannot completely trust the pipeline result, diff --git a/doc/development/automatic_ce_ee_merge.md b/doc/development/automatic_ce_ee_merge.md index fed772b9240..3ca841353e6 100644 --- a/doc/development/automatic_ce_ee_merge.md +++ b/doc/development/automatic_ce_ee_merge.md @@ -115,16 +115,16 @@ Now, every time you create an MR for CE and EE: 1. Continue cherry-picking: `git cherry-pick --continue` 1. Push to EE: `git push origin branch-example-ee` 1. Create the EE-equivalent MR and link to the CE MR from the -description "Ports [CE-MR-LINK] to EE" + description "Ports [CE-MR-LINK] to EE" 1. Once all the jobs are passing in both CE and EE, you've addressed the -feedback from your own team, and got them approved, the merge requests can be merged. + feedback from your own team, and got them approved, the merge requests can be merged. 1. When both MRs are ready, the EE merge request will be merged first, and the -CE-equivalent will be merged next. + CE-equivalent will be merged next. **Important notes:** - The commit SHA can be easily found from the GitLab UI. From a merge request, -open the tab **Commits** and click the copy icon to copy the commit SHA. + open the tab **Commits** and click the copy icon to copy the commit SHA. - To cherry-pick a **commit range**, such as [A > B > C > D] use: ```shell @@ -140,7 +140,7 @@ open the tab **Commits** and click the copy icon to copy the commit SHA. ``` - To cherry-pick a **merge commit**, use the flag `-m 1`. For example, suppose that the -merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`: + merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`: ```shell git cherry-pick -m 1 138f5e2f20289bb376caffa0303adb0cac859ce1 @@ -163,12 +163,12 @@ merge commit SHA is `138f5e2f20289bb376caffa0303adb0cac859ce1`: commits and you want to cherry-pick all but the merge commit. - If you push more commits to the CE branch, you can safely repeat the procedure -to cherry-pick them to the EE-equivalent branch. You can do that as many times as -necessary, using the same CE and EE branches. + to cherry-pick them to the EE-equivalent branch. You can do that as many times as + necessary, using the same CE and EE branches. - If you submitted the merge request to the CE repo and the `ee-compat-check` job passed, -you are not required to submit the EE-equivalent MR, but it's still recommended. If the -job failed, you are required to submit the EE MR so that you can fix the conflicts in EE -before merging your changes into CE. + you are not required to submit the EE-equivalent MR, but it's still recommended. If the + job failed, you are required to submit the EE MR so that you can fix the conflicts in EE + before merging your changes into CE. ## FAQ diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index c5344139ab4..4c53643ed9c 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -199,7 +199,7 @@ different way. We add the ~"Accepting merge requests" label to: - Low priority ~bug issues (i.e. we do not add it to the bugs that we want to -solve in the ~"Next Patch Release") + solve in the ~"Next Patch Release") - Small ~feature - Small ~"technical debt" issues @@ -300,17 +300,17 @@ below will make it easy to manage this, without unnecessary overhead. 1. Set weight for any issue at the earliest possible convenience 1. If you don't agree with a set weight, discuss with other developers until -consensus is reached about the weight + consensus is reached about the weight 1. Issue weights are an abstract measurement of complexity of the issue. Do not -relate issue weight directly to time. This is called [anchoring](https://en.wikipedia.org/wiki/Anchoring) -and something you want to avoid. + relate issue weight directly to time. This is called [anchoring](https://en.wikipedia.org/wiki/Anchoring) + and something you want to avoid. 1. Something that has a weight of 1 (or no weight) is really small and simple. -Something that is 9 is rewriting a large fundamental part of GitLab, -which might lead to many hard problems to solve. Changing some text in GitLab -is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9. + Something that is 9 is rewriting a large fundamental part of GitLab, + which might lead to many hard problems to solve. Changing some text in GitLab + is probably 1, adding a new Git Hook maybe 4 or 5, big features 7-9. 1. If something is very large, it should probably be split up in multiple -issues or chunks. You can simply not set the weight of a parent issue and set -weights to children issues. + issues or chunks. You can simply not set the weight of a parent issue and set + weights to children issues. ## Regression issues diff --git a/doc/development/documentation/feature-change-workflow.md b/doc/development/documentation/feature-change-workflow.md index eb479b85083..3f31fe5ca19 100644 --- a/doc/development/documentation/feature-change-workflow.md +++ b/doc/development/documentation/feature-change-workflow.md @@ -7,16 +7,16 @@ description: How to add docs for new or enhanced GitLab features. At GitLab, developers contribute new or updated documentation along with their code, but product managers and technical writers also have essential roles in the process. - **Developers**: Author/update documentation in the same MR as their code, and -merge it by the feature freeze for the assigned milestone. Request technical writer -assistance if needed. Other developers typically act as reviewers. + merge it by the feature freeze for the assigned milestone. Request technical writer + assistance if needed. Other developers typically act as reviewers. - **Product Managers** (PMs): In the issue for all new and enhanced features, -confirm the documentation requirements, plus the mentioned feature description -and use cases, which can be reused in docs. They can bring in a technical -writer for discussion or collaboration, and can be called upon themselves as a doc reviewer. + confirm the documentation requirements, plus the mentioned feature description + and use cases, which can be reused in docs. They can bring in a technical + writer for discussion or collaboration, and can be called upon themselves as a doc reviewer. - **Technical Writers**: Review doc requirements in issues, track issues and MRs -that contain docs changes, help with any questions throughout the authoring/editing process, -work on special projects related to the documentation, and review all new and updated -docs content, whether before or after it is merged. + that contain docs changes, help with any questions throughout the authoring/editing process, + work on special projects related to the documentation, and review all new and updated + docs content, whether before or after it is merged. Beyond this process, any member of the GitLab community can also author or request documentation improvements that are not associated with a new or changed feature. See the [Documentation improvement workflow](improvement-workflow.md). @@ -35,7 +35,7 @@ documentation updates if screenshots are now needed, or need to be updated. Documentation is not required when a feature is changed on the backend only and does not directly affect the way that any user or administrator would -interact with GitLab. +interact with GitLab. NOTE: **Note:** When revamping documentation, if unrelated to the feature change, this should be submitted @@ -80,7 +80,7 @@ must: - Add the `Documentation` label. - Confirm or add the [documentation requirements](#documentation-requirements). - Ensure the issue contains any new or updated feature name, overview/description, -and use cases, as required per the [documentation structure and template](structure.md), when applicable. + and use cases, as required per the [documentation structure and template](structure.md), when applicable. Everyone is encouraged to draft the requirements in the issue, but a product manager will do the following: @@ -100,20 +100,20 @@ Follow the process below unless otherwise agreed with the product manager and te - Include any new and edited docs in the MR introducing the code. - Use the Documentation requirements confirmed by the Product Manager in the -issue and discuss any further doc plans or ideas as needed. - - If the new or changed doc requires extensive collaboration or conversation, a separate, -linked issue can be used for the planning process. - - We are trying to avoid using a separate MR, so that the docs stay with the code, but the -Technical Writing team is interested in discussing any potential exceptions that may be suggested. + issue and discuss any further doc plans or ideas as needed. + - If the new or changed doc requires extensive collaboration or conversation, a separate, + linked issue can be used for the planning process. + - We are trying to avoid using a separate MR, so that the docs stay with the code, but the + Technical Writing team is interested in discussing any potential exceptions that may be suggested. - Use the [Documentation guidelines](index.md), as well as other resources linked from there, -including the Documentation [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). + including the Documentation [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). - If you need any help to choose the correct place for a doc, discuss a documentation -idea or outline, or request any other help, ping the Technical Writer for the relevant -[DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages) -in your issue or MR, or write within `#docs` on the GitLab Slack. + idea or outline, or request any other help, ping the Technical Writer for the relevant + [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages) + in your issue or MR, or write within `#docs` on the GitLab Slack. - The docs must be merged with the code **by the feature freeze date**, otherwise -the feature cannot be included with the release. A policy for documenting feature-flagged -issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/56813). + the feature cannot be included with the release. A policy for documenting feature-flagged + issues is forthcoming and you are welcome to join the [discussion](https://gitlab.com/gitlab-org/gitlab-ce/issues/56813). #### Reviews and merging @@ -124,35 +124,35 @@ All reviewers can help ensure accuracy, clarity, completeness, and adherence to 1. **The code reviewer** for the MR, to confirm accuracy, clarity, and completeness. 1. Optionally: Others involved in the work, such as other devs or the PM. 1. Optionally: The technical writer for the DevOps stage. If not prior to merging, the technical writer will review after the merge. -This helps us ensure that the developer has time to merge good content by the freeze, and that it can be further refined by the release, if needed. + This helps us ensure that the developer has time to merge good content by the freeze, and that it can be further refined by the release, if needed. - To decide whether to request this review before the merge, consider the amount of time left before the code freeze, the size of the change, -and your degree of confidence in having users of an RC use your docs as written. + and your degree of confidence in having users of an RC use your docs as written. - Pre-merge tech writer reviews should be most common when the code is complete well in advance of the freeze and/or for larger documentation changes. - You can request a review and if there is not sufficient time to complete it prior to the freeze, -the maintainer can merge the current doc changes (if complete) and create a follow-up doc review issue. + the maintainer can merge the current doc changes (if complete) and create a follow-up doc review issue. - The technical writer can also help decide what docs to merge before the freeze and whether to work on further changes in a follow up MR. - **To request a pre-merge technical writer review**, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages). - **To request a post-merge technical writer review**, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change. 1. **The maintainer** who is assigned to merge the MR, to verify clarity, completeness, and quality, to the best of their ability. - Upon merging, if a technical writer review has not been performed and there is not yet a linked issue for a follow-up review, the maintainer should [create an issue using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review), link it from the MR, and -mention the original MR author in the new issue. Alternatively, the mainitainer can ask the MR author to create and link this issue before the MR is merged. + mention the original MR author in the new issue. Alternatively, the mainitainer can ask the MR author to create and link this issue before the MR is merged. - After merging, documentation changes are reviewed by: 1. The technical writer--**if** their review was not performed prior to the merge. 2. Optionally: by the PM (for accuracy and to ensure it's consistent with the vision for how the product will be used). -Any party can raise the item to the PM for review at any point: the dev, the technical writer, or the PM, who can request/plan a review at the outset. + Any party can raise the item to the PM for review at any point: the dev, the technical writer, or the PM, who can request/plan a review at the outset. ### Technical Writer role #### Planning - The technical writer monitors the documentation needs of issues assigned to the current and next milestone -for their DevOps stage(s), and participates in any needed discussion on docs planning and requirements refinement -with the dev, PM, and others. + for their DevOps stage(s), and participates in any needed discussion on docs planning and requirements refinement + with the dev, PM, and others. - The technical writer will review these requirements again upon the kickoff and provide feedback, as needed. -This is not a blocking review and developers should not wait to work on docs. + This is not a blocking review and developers should not wait to work on docs. #### Collaboration @@ -165,12 +165,12 @@ Additionally, technical writers are available for questions at any time. #### Review - Techncial writers provide non-blocking reviews of all documentation changes, -before or after the change is merged. However, if the docs are ready in the MR while -there's time before the freeze, the technical writer's review can commence early, on request. + before or after the change is merged. However, if the docs are ready in the MR while + there's time before the freeze, the technical writer's review can commence early, on request. - The technical writer will confirm that the doc is clear, grammatically correct, -and discoverable, while avoiding redundancy, bad file locations, typos, broken links, -etc. The technical writer will review the documentation for the following, which -the developer and code reviewer should have already made a good-faith effort to ensure: + and discoverable, while avoiding redundancy, bad file locations, typos, broken links, + etc. The technical writer will review the documentation for the following, which + the developer and code reviewer should have already made a good-faith effort to ensure: - Clarity. - Adherence to the plans and goals in the issue. - Location (make sure the docs are in the correct directorkes and has the correct name). diff --git a/doc/development/documentation/improvement-workflow.md b/doc/development/documentation/improvement-workflow.md index c97d8966b8c..a12c3d5ea7b 100644 --- a/doc/development/documentation/improvement-workflow.md +++ b/doc/development/documentation/improvement-workflow.md @@ -21,10 +21,10 @@ to accomplish their work with GitLab. ## How to update the docs 1. Click "Edit this Page" at the bottom of any page on docs.gitlab.com, or navigate to -one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page. -Work in a fork if you do not have developer access to the GitLab project. + one of the repositories and doc paths listed on the [GitLab Documentation guidelines](index.md) page. + Work in a fork if you do not have developer access to the GitLab project. 1. Follow the described standards and processes listed on that Guidelines page, -including the linked resources: the [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). + including the linked resources: the [Structure and template](structure.md) page, [Style Guide](styleguide.md), and [Markdown Guide](https://about.gitlab.com/handbook/product/technical-writing/markdown-guide/). 1. Follow GitLab's [Merge Request Guidelines](../contributing/merge_request_workflow.md#merge-request-guidelines). If you need any help to choose the correct place for a doc, discuss a documentation @@ -45,7 +45,7 @@ before merging, mention the writer who is assigned to the relevant [DevOps stage The process can involve the following parties/phases, and is replicated in the `Documentation` MR template for GitLab CE and EE, to help with following the process. **1. Primary Reviewer** - Review by a [code reviewer](https://about.gitlab.com/handbook/engineering/projects/) or other appropriate colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes. - + **2. Technical Writer** - Optional - If not requested for this MR, must be scheduled post-merge. To request a pre-merge review, assign the writer listed for the applicable [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages). To request a post-merge review, [create an issue for one using the Doc Review template](https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issuable_template=Doc%20Review) and link it from the MR that makes the doc change. diff --git a/doc/development/documentation/structure.md b/doc/development/documentation/structure.md index ee3bd5606a5..95b5fcd99a1 100644 --- a/doc/development/documentation/structure.md +++ b/doc/development/documentation/structure.md @@ -20,7 +20,7 @@ Every feature or use case document should include the following content in the f with exceptions and details noted below and in the template included on this page. - **Title**: Top-level heading with the feature name, or a use case name, which would start with -a verb, like Configuring, Enabling, etc. + a verb, like Configuring, Enabling, etc. - **Introduction**: A couple sentences about the subject matter and what's to be found on this page. - **Overview** Describe what it is, what it does, and in what context it should be used. - **Use cases**: describes real use case scenarios for that feature/configuration. @@ -95,7 +95,7 @@ Link each one to an appropriate place for more information. "Instructions" is usually not the name of the heading. This is the part of the document where you can include one or more sets of instructions, each to accomplish a specific task. Headers should describe the task the reader will achieve by following the instructions within, typically starting with a verb. -Larger instruction sets may have subsections covering specific phases of the process. +Larger instruction sets may have subsections covering specific phases of the process. - Write a step-by-step guide, with no gaps between the steps. - Start with an h2 (`##`), break complex steps into small steps using diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md index 905668eef58..f3fdaa3b883 100644 --- a/doc/development/fe_guide/development_process.md +++ b/doc/development/fe_guide/development_process.md @@ -61,17 +61,19 @@ Please use your best judgement when to use it and please contribute new points t --- ### Share your work early + 1. Before writing code, ensure your vision of the architecture is aligned with -GitLab's architecture. + GitLab's architecture. 1. Add a diagram to the issue and ask a frontend architect in the slack channel `#fe_architectural` about it.  1. Don't take more than one week between starting work on a feature and -sharing a Merge Request with a reviewer or a maintainer. + sharing a Merge Request with a reviewer or a maintainer. ### Vue features + 1. Follow the steps in [Vue.js Best Practices](vue.md) 1. Follow the style guide. 1. Only a handful of people are allowed to merge Vue related features. -Reach out to one of Vue experts early in this process. + Reach out to one of Vue experts early in this process. diff --git a/doc/development/fe_guide/droplab/plugins/filter.md b/doc/development/fe_guide/droplab/plugins/filter.md index ddc6a3386c7..1f188c64fe4 100644 --- a/doc/development/fe_guide/droplab/plugins/filter.md +++ b/doc/development/fe_guide/droplab/plugins/filter.md @@ -9,7 +9,7 @@ Add the `Filter` object to the plugins array of a `DropLab.prototype.init` or `D - `Filter` requires a config value for `template`. - `template` should be the key of the objects within your data array that you want to compare -to the user input string, for filtering. + to the user input string, for filtering. ```html <input href="#" id="trigger" data-dropdown-trigger="#list"> diff --git a/doc/development/fe_guide/droplab/plugins/input_setter.md b/doc/development/fe_guide/droplab/plugins/input_setter.md index e229103e462..e4050213869 100644 --- a/doc/development/fe_guide/droplab/plugins/input_setter.md +++ b/doc/development/fe_guide/droplab/plugins/input_setter.md @@ -9,7 +9,7 @@ Add the `InputSetter` object to the plugins array of a `DropLab.prototype.init` - `InputSetter` requires a config value for `input` and `valueAttribute`. - `input` should be the DOM element that you want to manipulate. - `valueAttribute` should be a string that is the name of an attribute on your list items that is used to get the value -to update the `input` element with. + to update the `input` element with. You can also set the `InputSetter` config to an array of objects, which will allow you to update multiple elements. diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md index 0aba38aca8c..2628e95dbc1 100644 --- a/doc/development/fe_guide/performance.md +++ b/doc/development/fe_guide/performance.md @@ -5,6 +5,7 @@ ### Realtime Components When writing code for realtime features we have to keep a couple of things in mind: + 1. Do not overload the server with requests. 1. It should feel realtime. @@ -12,16 +13,16 @@ Thus, we must strike a balance between sending requests and the feeling of realt Use the following rules when creating realtime solutions. 1. The server will tell you how much to poll by sending `Poll-Interval` in the header. -Use that as your polling interval. This way it is [easy for system administrators to change the -polling rate](../../administration/polling.md). -A `Poll-Interval: -1` means you should disable polling, and this must be implemented. + Use that as your polling interval. This way it is [easy for system administrators to change the + polling rate](../../administration/polling.md). + A `Poll-Interval: -1` means you should disable polling, and this must be implemented. 1. A response with HTTP status different from 2XX should disable polling as well. 1. Use a common library for polling. 1. Poll on active tabs only. Please use [Visibility](https://github.com/ai/visibilityjs). 1. Use regular polling intervals, do not use backoff polling, or jitter, as the interval will be -controlled by the server. + controlled by the server. 1. The backend code will most likely be using etags. You do not and should not check for status -`304 Not Modified`. The browser will transform it for you. + `304 Not Modified`. The browser will transform it for you. ### Lazy Loading Images diff --git a/doc/development/fe_guide/style_guide_js.md b/doc/development/fe_guide/style_guide_js.md index 1e0529262ad..060cd8baf7f 100644 --- a/doc/development/fe_guide/style_guide_js.md +++ b/doc/development/fe_guide/style_guide_js.md @@ -14,9 +14,9 @@ See [our current .eslintrc](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/ #### ESlint 1. **Never** disable eslint rules unless you have a good reason. -You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */` -at the top, but legacy files are a special case. Any time you develop a new feature or -refactor an existing one, you should abide by the eslint rules. + You may see a lot of legacy files with `/* eslint-disable some-rule, some-other-rule */` + at the top, but legacy files are a special case. Any time you develop a new feature or + refactor an existing one, you should abide by the eslint rules. 1. **Never Ever EVER** disable eslint globally for a file @@ -53,7 +53,7 @@ refactor an existing one, you should abide by the eslint rules. 1. [class-methods-use-this][eslint-this] 1. When they are needed _always_ place ESlint directive comment blocks on the first line of a script, -followed by any global declarations, then a blank newline prior to any imports or code. + followed by any global declarations, then a blank newline prior to any imports or code. ```javascript // bad @@ -125,8 +125,8 @@ followed by any global declarations, then a blank newline prior to any imports o ``` 1. Relative paths: when importing a module in the same directory, a child -directory, or an immediate parent directory prefer relative paths. When -importing a module which is two or more levels up, prefer either `~/` or `ee/`. + directory, or an immediate parent directory prefer relative paths. When + importing a module which is two or more levels up, prefer either `~/` or `ee/`. In **app/assets/javascripts/my-feature/subdir**: @@ -163,9 +163,9 @@ importing a module which is two or more levels up, prefer either `~/` or `ee/`. ``` 1. Avoid using IIFE. Although we have a lot of examples of files which wrap their -contents in IIFEs (immediately-invoked function expressions), -this is no longer necessary after the transition from Sprockets to webpack. -Do not use them anymore and feel free to remove them when refactoring legacy code. + contents in IIFEs (immediately-invoked function expressions), + this is no longer necessary after the transition from Sprockets to webpack. + Do not use them anymore and feel free to remove them when refactoring legacy code. 1. Avoid adding to the global namespace. ```javascript @@ -484,8 +484,8 @@ Please check this [rules][eslint-plugin-vue-rules] for more documentation. ``` 1. Default key should be provided if the prop is not required. -_Note:_ There are some scenarios where we need to check for the existence of the property. -On those a default key should not be provided. + _Note:_ There are some scenarios where we need to check for the existence of the property. + On those a default key should not be provided. ```javascript // good diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md index 60f322c6e75..3cd70bd63fa 100644 --- a/doc/development/fe_guide/vue.md +++ b/doc/development/fe_guide/vue.md @@ -223,6 +223,7 @@ need to test the rendered output. [Vue][vue-test] guide's to unit test show us e ## Vue.js Expert Role One should apply to be a Vue.js expert by opening an MR when the Merge Request's they create and review show: + - Deep understanding of Vue and Vuex reactivy - Vue and Vuex code are structured according to both official and our guidelines - Full understanding of testing a Vue and Vuex application diff --git a/doc/development/logging.md b/doc/development/logging.md index 5c1d96b9e0c..d61441813b2 100644 --- a/doc/development/logging.md +++ b/doc/development/logging.md @@ -32,8 +32,8 @@ These logs suffer from a number of problems: 1. They often lack timestamps or other contextual information (e.g. project ID, user) 2. They may span multiple lines, which make them hard to find via Elasticsearch. 3. They lack a common structure, which make them hard to parse by log -forwarders, such as Logstash or Fluentd. This also makes them hard to -search. + forwarders, such as Logstash or Fluentd. This also makes them hard to + search. Note that currently on GitLab.com, any messages in `production.log` will NOT get indexed by Elasticsearch due to the sheer volume and noise. They @@ -61,12 +61,12 @@ importer. You want to log issues created, merge requests, etc. as the importer progresses. Here's what to do: 1. Look at [the list of GitLab Logs](../administration/logs.md) to see -if your log message might belong with one of the existing log files. + if your log message might belong with one of the existing log files. 1. If there isn't a good place, consider creating a new filename, but -check with a maintainer if it makes sense to do so. A log file should -make it easy for people to search pertinent logs in one place. For -example, `geo.log` contains all logs pertaining to GitLab Geo. -To create a new file: + check with a maintainer if it makes sense to do so. A log file should + make it easy for people to search pertinent logs in one place. For + example, `geo.log` contains all logs pertaining to GitLab Geo. + To create a new file: 1. Choose a filename (e.g. `importer_json.log`). 1. Create a new subclass of `Gitlab::JsonLogger`: @@ -130,15 +130,15 @@ To create a new file: ## Additional steps with new log files 1. Consider log retention settings. By default, Omnibus will rotate any -logs in `/var/log/gitlab/gitlab-rails/*.log` every hour and [keep at -most 30 compressed files](https://docs.gitlab.com/omnibus/settings/logs.html#logrotate). -On GitLab.com, that setting is only 6 compressed files. These settings should suffice -for most users, but you may need to tweak them in [omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab). + logs in `/var/log/gitlab/gitlab-rails/*.log` every hour and [keep at + most 30 compressed files](https://docs.gitlab.com/omnibus/settings/logs.html#logrotate). + On GitLab.com, that setting is only 6 compressed files. These settings should suffice + for most users, but you may need to tweak them in [omnibus-gitlab](https://gitlab.com/gitlab-org/omnibus-gitlab). 1. If you add a new file, submit an issue to the [production -tracker](https://gitlab.com/gitlab-com/gl-infra/production/issues) or -a merge request to the [gitlab_fluentd](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd) -project. See [this example](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd/merge_requests/51/diffs). + tracker](https://gitlab.com/gitlab-com/gl-infra/production/issues) or + a merge request to the [gitlab_fluentd](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd) + project. See [this example](https://gitlab.com/gitlab-cookbooks/gitlab_fluentd/merge_requests/51/diffs). 1. Be sure to update the [GitLab CE/EE documentation](../administration/logs.md) and the [GitLab.com -runbooks](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/logging.md). + runbooks](https://gitlab.com/gitlab-com/runbooks/blob/master/howto/logging.md). diff --git a/doc/development/new_fe_guide/development/accessibility.md b/doc/development/new_fe_guide/development/accessibility.md index 2a3a126ca5c..8420a504ec4 100644 --- a/doc/development/new_fe_guide/development/accessibility.md +++ b/doc/development/new_fe_guide/development/accessibility.md @@ -2,7 +2,7 @@ Using semantic HTML plays a key role when it comes to accessibility. ## Accessible Rich Internet Applications - ARIA -WAI-ARIA, the Accessible Rich Internet Applications specification, defines a way to make Web content and Web applications more accessible to people with disabilities. +WAI-ARIA, the Accessible Rich Internet Applications specification, defines a way to make Web content and Web applications more accessible to people with disabilities. > Note: It is [recommended][using-aria] to use semantic elements as the primary method to achieve accessibility rather than adding aria attributes. Adding aria attributes should be seen as a secondary method for creating accessible elements. @@ -15,6 +15,7 @@ Check the list of WAI-ARIA roles [here][roles] When using icons or images that aren't absolutely needed to understand the context, we should use `aria-hidden="true"`. On the other hand, if an icon is crucial to understand the context we should do one of the following: + 1. Use `aria-label` in the element with a meaningful description 1. Use `aria-labelledby` to point to an element that contains the explanation for that icon diff --git a/doc/development/new_fe_guide/style/html.md b/doc/development/new_fe_guide/style/html.md index 2d5b7d048ab..035fcbb28df 100644 --- a/doc/development/new_fe_guide/style/html.md +++ b/doc/development/new_fe_guide/style/html.md @@ -3,6 +3,7 @@ ## Buttons <a name="button-type"></a><a name="1.1"></a> + - [1.1](#button-type) **Use button type** Button tags requires a `type` attribute according to the [W3C HTML specification][button-type-spec]. ``` @@ -14,6 +15,7 @@ ``` <a name="button-role"></a><a name="1.2"></a> + - [1.2](#button-role) **Use button role for non buttons** If an HTML element has an onClick handler but is not a button, it should have `role="button"`. This is more [accessible][button-role-accessible]. ``` @@ -27,6 +29,7 @@ ## Links <a name="blank-links"></a><a name="2.1"></a> + - [2.1](#blank-links) **Use rel for target blank** Use `rel="noopener noreferrer"` whenever your links open in a new window i.e. `target="_blank"`. This prevents [the following][jitbit-target-blank] security vulnerability documented by JitBit ``` @@ -38,6 +41,7 @@ ``` <a name="fake-links"></a><a name="2.2"></a> + - [2.2](#fake-links) **Do not use fake links** Use a button tag if a link only invokes JavaScript click event handlers. This is more semantic. ``` diff --git a/doc/development/new_fe_guide/style/javascript.md b/doc/development/new_fe_guide/style/javascript.md index 922fd1e4ea4..7985b893c9e 100644 --- a/doc/development/new_fe_guide/style/javascript.md +++ b/doc/development/new_fe_guide/style/javascript.md @@ -10,6 +10,7 @@ You can run eslint locally by running `yarn eslint` ## Arrays <a name="avoid-foreach"></a><a name="1.1"></a> + - [1.1](#avoid-foreach) **Avoid ForEach when mutating data** Use `map`, `reduce` or `filter` instead of `forEach` when mutating data. This will minimize mutations in functions ([which is aligned with Airbnb's style guide][airbnb-minimize-mutations]) ``` @@ -17,7 +18,7 @@ You can run eslint locally by running `yarn eslint` users.forEach((user, index) => { user.id = index; }); - + // good const usersWithId = users.map((user, index) => { return Object.assign({}, user, { id: index }); @@ -27,6 +28,7 @@ You can run eslint locally by running `yarn eslint` ## Functions <a name="limit-params"></a><a name="2.1"></a> + - [2.1](#limit-params) **Limit number of parameters** If your function or method has more than 3 parameters, use an object as a parameter instead. ``` @@ -34,7 +36,7 @@ You can run eslint locally by running `yarn eslint` function a(p1, p2, p3) { // ... }; - + // good function a(p) { // ... @@ -44,6 +46,7 @@ You can run eslint locally by running `yarn eslint` ## Classes & constructors <a name="avoid-constructor-side-effects"></a><a name="3.1"></a> + - [3.1](#avoid-constructor-side-effects) **Avoid side effects in constructors** Avoid making some operations in the `constructor`, such as asynchronous calls, API requests and DOM manipulations. Prefer moving them into separate functions. This will make tests easier to write and code easier to maintain. ```javascript @@ -54,23 +57,24 @@ You can run eslint locally by running `yarn eslint` axios.get(this.config.endpoint) } } - + // good class myClass { constructor(config) { this.config = config; } - + makeRequest() { axios.get(this.config.endpoint) } } const instance = new myClass(); instance.makeRequest(); - + ``` <a name="avoid-classes-to-handle-dom-events"></a><a name="3.2"></a> + - [3.2](#avoid-classes-to-handle-dom-events) **Avoid classes to handle DOM events** If the only purpose of the class is to bind a DOM event and handle the callback, prefer using a function. ``` @@ -79,14 +83,14 @@ You can run eslint locally by running `yarn eslint` constructor(config) { this.config = config; } - + init() { document.addEventListener('click', () => {}); } } - + // good - + const myFunction = () => { document.addEventListener('click', () => { // handle callback here @@ -95,8 +99,9 @@ You can run eslint locally by running `yarn eslint` ``` <a name="element-container"></a><a name="3.3"></a> + - [3.3](#element-container) **Pass element container to constructor** When your class manipulates the DOM, receive the element container as a parameter. -This is more maintainable and performant. + This is more maintainable and performant. ``` // bad @@ -105,7 +110,7 @@ This is more maintainable and performant. document.querySelector('.b'); } } - + // good class a { constructor(options) { @@ -117,12 +122,13 @@ This is more maintainable and performant. ## Type Casting & Coercion <a name="use-parseint"></a><a name="4.1"></a> + - [4.1](#use-parseint) **Use ParseInt** Use `ParseInt` when converting a numeric string into a number. ``` // bad Number('10') - + // good parseInt('10', 10); ``` @@ -130,12 +136,13 @@ This is more maintainable and performant. ## CSS Selectors <a name="use-js-prefix"></a><a name="5.1"></a> + - [5.1](#use-js-prefix) **Use js prefix** If a CSS class is only being used in JavaScript as a reference to the element, prefix the class name with `js-` ``` // bad <button class="add-user"></button> - + // good <button class="js-add-user"></button> ``` @@ -143,44 +150,51 @@ This is more maintainable and performant. ## Modules <a name="use-absolute-paths"></a><a name="6.1"></a> + - [6.1](#use-absolute-paths) **Use absolute paths for nearby modules** Use absolute paths if the module you are importing is less than two levels up. ``` // bad import GitLabStyleGuide from '~/guides/GitLabStyleGuide'; - + // good import GitLabStyleGuide from '../GitLabStyleGuide'; ``` <a name="use-relative-paths"></a><a name="6.2"></a> + - [6.2](#use-relative-paths) **Use relative paths for distant modules** If the module you are importing is two or more levels up, use a relative path instead of an absolute path. ``` // bad import GitLabStyleGuide from '../../../guides/GitLabStyleGuide'; - + // good import GitLabStyleGuide from '~/GitLabStyleGuide'; ``` <a name="global-namespace"></a><a name="6.3"></a> + - [6.3](#global-namespace) **Do not add to global namespace** <a name="domcontentloaded"></a><a name="6.4"></a> + - [6.4](#domcontentloaded) **Do not use DOMContentLoaded in non-page modules** Imported modules should act the same each time they are loaded. `DOMContentLoaded` events are only allowed on modules loaded in the `/pages/*` directory because those are loaded dynamically with webpack. ## Security <a name="avoid-xss"></a><a name="7.1"></a> + - [7.1](#avoid-xss) **Avoid XSS** Do not use `innerHTML`, `append()` or `html()` to set content. It opens up too many vulnerabilities. ## ESLint <a name="disable-eslint-file"></a><a name="8.1"></a> + - [8.1](#disable-eslint-file) **Disabling ESLint in new files** Do not disable ESLint when creating new files. Existing files may have existing rules disabled due to legacy compatibility reasons but they are in the process of being refactored. <a name="disable-eslint-rule"></a><a name="8.2"></a> + - [8.2](#disable-eslint-rule) **Disabling ESLint rule** Do not disable specific ESLint rules. Due to technical debt, you may disable the following rules only if you are invoking/instantiating existing code modules - [no-new][no-new] diff --git a/doc/development/policies.md b/doc/development/policies.md index 6a3b90f3604..c4ac42bb40a 100644 --- a/doc/development/policies.md +++ b/doc/development/policies.md @@ -88,10 +88,10 @@ An example debug output would look as follows: Each line represents a rule that was evaluated. There are a few things to note: 1. The `-` or `+` symbol indicates whether the rule block was evaluated to be -`false` or `true`, respectively. + `false` or `true`, respectively. 2. The number inside the brackets indicates the score. 3. The last part of the line (e.g. `@john : Issue/1`) shows the username -and subject for that rule. + and subject for that rule. Here you can see that the first four rules were evaluated `false` for which user and subject. For example, you can see in the last line that diff --git a/doc/development/polling.md b/doc/development/polling.md index 3b34f985cd4..76bb5ae7819 100644 --- a/doc/development/polling.md +++ b/doc/development/polling.md @@ -51,6 +51,7 @@ request path. By doing this we avoid query parameter ordering problems and make route matching easier. For more information see: + - [`Poll-Interval` header](fe_guide/performance.md#realtime-components) - [RFC 7232](https://tools.ietf.org/html/rfc7232) - [ETag proposal](https://gitlab.com/gitlab-org/gitlab-ce/issues/26926) diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md index 4cc500ed1b6..dcb32c89f65 100644 --- a/doc/development/rake_tasks.md +++ b/doc/development/rake_tasks.md @@ -73,6 +73,7 @@ To make sure that indices still fit. You could find great details in: ## Run tests In order to run the test you can use the following commands: + - `rake spec` to run the rspec suite - `rake karma` to run the karma test suite - `rake gitlab:test` to run all the tests diff --git a/doc/development/testing_guide/end_to_end_tests.md b/doc/development/testing_guide/end_to_end_tests.md index e9f236c6b3a..a239dc84a1c 100644 --- a/doc/development/testing_guide/end_to_end_tests.md +++ b/doc/development/testing_guide/end_to_end_tests.md @@ -41,24 +41,24 @@ Currently, we are using _multi-project pipeline_-like approach to run QA pipelines. 1. Developer triggers a manual action, that can be found in CE / EE merge -requests. This starts a chain of pipelines in multiple projects. + requests. This starts a chain of pipelines in multiple projects. 1. The script being executed triggers a pipeline in [Omnibus GitLab][omnibus-gitlab] -and waits for the resulting status. We call this a _status attribution_. + and waits for the resulting status. We call this a _status attribution_. 1. GitLab packages are being built in the [Omnibus GitLab][omnibus-gitlab] -pipeline. Packages are then pushed to its Container Registry. + pipeline. Packages are then pushed to its Container Registry. 1. When packages are ready, and available in the registry, a final step in the -[Omnibus GitLab][omnibus-gitlab] pipeline, triggers a new -[GitLab QA pipeline][gitlab-qa-pipelines]. It also waits for a resulting status. + [Omnibus GitLab][omnibus-gitlab] pipeline, triggers a new + [GitLab QA pipeline][gitlab-qa-pipelines]. It also waits for a resulting status. 1. GitLab QA pulls images from the registry, spins-up containers and runs tests -against a test environment that has been just orchestrated by the `gitlab-qa` -tool. + against a test environment that has been just orchestrated by the `gitlab-qa` + tool. 1. The result of the [GitLab QA pipeline][gitlab-qa-pipelines] is being -propagated upstream, through Omnibus, back to the CE / EE merge request. + propagated upstream, through Omnibus, back to the CE / EE merge request. #### How do I write tests? diff --git a/doc/install/azure/index.md b/doc/install/azure/index.md index be14858f4c8..fa5be1d30f9 100644 --- a/doc/install/azure/index.md +++ b/doc/install/azure/index.md @@ -21,14 +21,14 @@ First, you'll need an account on Azure. There are three ways to do this: - If your company (or you) already has an account, then you are ready to go! - You can also open your own Azure account for free. _At time of writing_, you get $200 -of credit to spend on Azure services for 30 days. You can use this credit to try out paid Azure -services, exploring Microsoft's cloud for free. Even after the first 30 days, you never have to pay -anything unless you decide to transition to paid services with a Pay-As-You-Go Azure subscription. -This is a great way to try out Azure and cloud computing, and you can -[read more in their comprehensive FAQ][Azure-Free-Account-FAQ]. + of credit to spend on Azure services for 30 days. You can use this credit to try out paid Azure + services, exploring Microsoft's cloud for free. Even after the first 30 days, you never have to pay + anything unless you decide to transition to paid services with a Pay-As-You-Go Azure subscription. + This is a great way to try out Azure and cloud computing, and you can + [read more in their comprehensive FAQ][Azure-Free-Account-FAQ]. - If you have an MSDN subscription, you can activate your Azure subscriber benefits. Your MSDN -subscription gives you recurring Azure credits every month, so why not put those credits to use and -try out GitLab right now? + subscription gives you recurring Azure credits every month, so why not put those credits to use and + try out GitLab right now? ## Working with Azure @@ -216,10 +216,10 @@ Like all servers, our VM will be running many services. However, we want to open ports to enable public internet access to two services in particular: 1. **HTTP** (port 80) - opening port 80 will enable our VM to respond to HTTP requests, allowing -public access to the instance of GitLab running on our VM. + public access to the instance of GitLab running on our VM. 1. **SSH** (port 22) - opening port 22 will enable our VM to respond to SSH connection requests, -allowing public access (with authentication) to remote terminal sessions -_(you'll see why we need [SSH] access to our VM [later on in this tutorial](#maintaining-your-gitlab-instance))_ + allowing public access (with authentication) to remote terminal sessions + _(you'll see why we need [SSH] access to our VM [later on in this tutorial](#maintaining-your-gitlab-instance))_ ### Open HTTP on Port 80 diff --git a/doc/install/kubernetes/preparation/eks.md b/doc/install/kubernetes/preparation/eks.md index 647b856d54e..ea3b075dd82 100644 --- a/doc/install/kubernetes/preparation/eks.md +++ b/doc/install/kubernetes/preparation/eks.md @@ -5,6 +5,7 @@ There are a few nuances to Amazon EKS which are important to be aware of, when d ## Persistent volume management There are two methods to manage volume claims on Kubernetes: + 1. Manually creating each persistent volume (recommended on EKS) 1. Utilizing dynamic provisioning to automatically create the persistent volumes diff --git a/doc/integration/README.md b/doc/integration/README.md index 7941cb42667..f7a624def53 100644 --- a/doc/integration/README.md +++ b/doc/integration/README.md @@ -12,7 +12,7 @@ See the documentation below for details on how to configure these services. - [Akismet](akismet.md) Configure Akismet to stop spam - [Auth0 OmniAuth](auth0.md) Enable the Auth0 OmniAuth provider - [Bitbucket](bitbucket.md) Import projects from Bitbucket.org and login to your GitLab instance with your -Bitbucket.org account + Bitbucket.org account - [CAS](cas.md) Configure GitLab to sign in using CAS - [External issue tracker](external-issue-tracker.md) Redmine, JIRA, etc. - [Gmail actions buttons](gmail_action_buttons_for_gitlab.md) Adds GitLab actions to messages diff --git a/doc/integration/auth0.md b/doc/integration/auth0.md index e2ed7a4b1ab..c67375ede50 100644 --- a/doc/integration/auth0.md +++ b/doc/integration/auth0.md @@ -4,18 +4,18 @@ To enable the Auth0 OmniAuth provider, you must create an Auth0 account, and an application. 1. Sign in to the [Auth0 Console](https://auth0.com/auth/login). If you need to -create an account, you can do so at the same link. + create an account, you can do so at the same link. 1. Select "New App/API". 1. Provide the Application Name ('GitLab' works fine). 1. Once created, you should see the Quick Start options. Disregard them and -select 'Settings' above the Quick Start options. + select 'Settings' above the Quick Start options. 1. At the top of the Settings screen, you should see your Domain, Client ID and -Client Secret. Take note of these as you'll need to put them in the -configuration file. For example: + Client Secret. Take note of these as you'll need to put them in the + configuration file. For example: - Domain: `test1234.auth0.com` - Client ID: `t6X8L2465bNePWLOvt9yi41i` - Client Secret: `KbveM3nqfjwCbrhaUy_gDu2dss8TIlHIdzlyf33pB7dEK5u_NyQdp65O_o02hXs2` @@ -44,7 +44,7 @@ configuration file. For example: ``` 1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) -for initial settings. + for initial settings. 1. Add the provider configuration: @@ -76,10 +76,10 @@ for initial settings. ``` 1. Change `YOUR_AUTH0_CLIENT_ID` to the client ID from the Auth0 Console page -from step 5. + from step 5. 1. Change `YOUR_AUTH0_CLIENT_SECRET` to the client secret from the Auth0 Console -page from step 5. + page from step 5. 1. [Reconfigure][] or [restart GitLab][] for the changes to take effect if you installed GitLab via Omnibus or from source respectively. diff --git a/doc/integration/facebook.md b/doc/integration/facebook.md index a67de23b17b..fe789a80eed 100644 --- a/doc/integration/facebook.md +++ b/doc/integration/facebook.md @@ -9,7 +9,7 @@ To enable the Facebook OmniAuth provider you must register your application with 1. Select the type "Website" 1. Enter a name for your app. This can be anything. Consider something like "<Organization>'s GitLab" or "<Your Name>'s GitLab" or -something else descriptive. + something else descriptive. 1. Choose "Create New Facebook App ID" diff --git a/doc/university/high-availability/aws/README.md b/doc/university/high-availability/aws/README.md index b4ba5b7a24e..4095f71e501 100644 --- a/doc/university/high-availability/aws/README.md +++ b/doc/university/high-availability/aws/README.md @@ -125,10 +125,10 @@ image below we have the settings for this article but note the following two options which are of particular interest for HA: 1. Multi-AZ-Deployment is recommended as redundancy. Read more at -[High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) + [High Availability (Multi-AZ)](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) 1. While we chose a General Purpose (SSD) for this article a Provisioned -IOPS (SSD) is best suited for HA. Read more about it at -[Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) + IOPS (SSD) is best suited for HA. Read more about it at + [Storage for Amazon RDS](http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html)  diff --git a/doc/university/training/end-user/README.md b/doc/university/training/end-user/README.md index 60c0eadc572..99fb5e83387 100644 --- a/doc/university/training/end-user/README.md +++ b/doc/university/training/end-user/README.md @@ -86,6 +86,7 @@ git config --global user.email you@example.com ```bash git config --global --list ``` + - You might want or be required to use an SSH key. - Instructions: [SSH](http://doc.gitlab.com/ce/ssh/README.html) @@ -413,6 +414,7 @@ Revert is safer considering we can revert a revert --- ### Version Control + - Local VCS was used with a filesystem or a simple db. - Centralized VCS such as Subversion includes collaboration but still is prone to data loss as the main server is the single point of diff --git a/doc/university/training/topics/stash.md b/doc/university/training/topics/stash.md index f1c91fb1b37..dfd28fbcbc9 100644 --- a/doc/university/training/topics/stash.md +++ b/doc/university/training/topics/stash.md @@ -30,7 +30,7 @@ and we need to change to a different branch. ---------- - Every time we save a stash it gets stacked so by using list we can see all our -stashes. + stashes. ``` git stash list diff --git a/doc/update/mysql_to_postgresql.md b/doc/update/mysql_to_postgresql.md index 1f4b5fbffa7..350072186ee 100644 --- a/doc/update/mysql_to_postgresql.md +++ b/doc/update/mysql_to_postgresql.md @@ -95,7 +95,7 @@ Now, you can use pgloader to migrate the data from MySQL to PostgreSQL: ``` 1. Once the migration finishes, you should see a summary table that looks like -the following: + the following: ``` table name read imported errors total time @@ -242,7 +242,7 @@ Now, you can use pgloader to migrate the data from MySQL to PostgreSQL: ``` 1. Once the migration finishes, you should see a summary table that looks like -the following: + the following: ``` table name read imported errors total time diff --git a/doc/user/discussions/index.md b/doc/user/discussions/index.md index d202b1260ad..1e2fad1efe9 100644 --- a/doc/user/discussions/index.md +++ b/doc/user/discussions/index.md @@ -248,10 +248,10 @@ For large projects with many contributors, it may be useful to stop discussions in issues or merge requests in these scenarios: - The project maintainer has already resolved the discussion and it is not helpful -for continued feedback. The project maintainer has already directed new conversation -to newer issues or merge requests. + for continued feedback. The project maintainer has already directed new conversation + to newer issues or merge requests. - The people participating in the discussion are trolling, abusive, or otherwise -being unproductive. + being unproductive. In these cases, a user with Developer permissions or higher in the project can lock (and unlock) an issue or a merge request, using the "Lock" section in the sidebar. For issues, @@ -276,17 +276,17 @@ Additionally locked issues can not be reopened. ## Filtering notes -> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/26723) in GitLab 11.5. +> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/26723) in GitLab 11.5. -For issues with many comments like activity notes and user comments, sometimes -finding useful information can be hard. There is a way to filter comments from single notes and discussions for merge requests and issues. +For issues with many comments like activity notes and user comments, sometimes +finding useful information can be hard. There is a way to filter comments from single notes and discussions for merge requests and issues. From a merge request's **Discussion** tab, or from an epic/issue overview, find the filter's dropdown menu on the right side of the page, from which you can choose one of the following options: - **Show all activity**: displays all user comments and system notes -(issue updates, mentions from other issues, changes to the description, etc). + (issue updates, mentions from other issues, changes to the description, etc). - **Show comments only**: only displays user comments in the list. -- **Show history only**: only displays activity notes. +- **Show history only**: only displays activity notes.  @@ -298,21 +298,21 @@ from any device you're logged into. > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/18008) in GitLab 11.6. -As a reviewer, you're able to suggest code changes with a simple +As a reviewer, you're able to suggest code changes with a simple markdown syntax in Merge Request Diff discussions. Then, the -Merge Request author (or other users with appropriate +Merge Request author (or other users with appropriate [permission](../permissions.md)) is able to apply these -suggestions with a click, which will generate a commit in +suggestions with a click, which will generate a commit in the Merge Request authored by the user that applied them. 1. Choose a line of code to be changed, add a new comment, then click -on the **Insert suggestion** icon in the toolbar: + on the **Insert suggestion** icon in the toolbar:  - + > **Note:** The suggestion will only affect the commented line. Multi-line - suggestions are currently not supported. Will be introduced by + suggestions are currently not supported. Will be introduced by [#53310](https://gitlab.com/gitlab-org/gitlab-ce/issues/53310). 1. In the comment, add your suggestion to the pre-populated code block: @@ -327,9 +327,9 @@ on the **Insert suggestion** icon in the toolbar:  > **Note:** - Discussions are _not_ automatically resolved. Will be introduced by + Discussions are _not_ automatically resolved. Will be introduced by [#54405](https://gitlab.com/gitlab-org/gitlab-ce/issues/54405). - + Once the author applies a suggestion, it will be marked with the **Applied** label, and GitLab will create a new commit with the message `Apply suggestion to <file-name>` and push the suggested change directly into the codebase in the merge request's branch. diff --git a/doc/user/group/index.md b/doc/user/group/index.md index 5fea683a7fd..300e0115c60 100644 --- a/doc/user/group/index.md +++ b/doc/user/group/index.md @@ -18,9 +18,9 @@ a link to the group settings. By clicking the last button you can leave that gro You can create groups for numerous reasons. To name a few: - Organize related projects under the same [namespace](#namespaces), add members to that -group and grant access to all their projects at once + group and grant access to all their projects at once - Create a group, include members of your team, and make it easier to -`@mention` all the team at once in issues and merge requests + `@mention` all the team at once in issues and merge requests - Create a group for your company members, and create [subgroups](subgroups/index.md) for each individual team. Let's say you create a group called `company-team`, and among others, you created subgroups in this group for each individual team `backend-team`, @@ -43,11 +43,11 @@ In GitLab, a namespace is a unique name to be used as a user name, a group name, For example, consider a user named Alex: 1. Alex creates an account on GitLab.com with the username `alex`; -their profile will be accessed under `https://gitlab.example.com/alex` + their profile will be accessed under `https://gitlab.example.com/alex` 1. Alex creates a group for their team with the groupname `alex-team`; -the group and its projects will be accessed under `https://gitlab.example.com/alex-team` + the group and its projects will be accessed under `https://gitlab.example.com/alex-team` 1. Alex creates a subgroup of `alex-team` with the subgroup name `marketing`; -this subgroup and its projects will be accessed under `https://gitlab.example.com/alex-team/marketing` + this subgroup and its projects will be accessed under `https://gitlab.example.com/alex-team/marketing` By doing so: @@ -107,7 +107,7 @@ Consider we have a group with two projects: - On the **Group Members** page we can now add a new user to the group. - Now because this user is a **Developer** member of the group, he automatically -gets **Developer** access to **all projects** within that group. + gets **Developer** access to **all projects** within that group. If necessary, you can increase the access level of an individual user for a specific project, by adding them again as a new member to the project with the new permission levels. @@ -267,9 +267,9 @@ Define project templates at a group-level by setting a group as a template sourc ### Advanced settings - **Projects**: view all projects within that group, add members to each project, -access each project's settings, and remove any project from the same screen. + access each project's settings, and remove any project from the same screen. - **Webhooks**: configure [webhooks](../project/integrations/webhooks.md) to your group. - **Kubernetes cluster integration**: connect your GitLab group with [Kubernetes clusters](clusters/index.md). - **Audit Events**: view [Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html#audit-events) -for the group. **[STARTER ONLY]** + for the group. **[STARTER ONLY]** - **Pipelines quota**: keep track of the [pipeline quota](../admin_area/settings/continuous_integration.md) for the group. diff --git a/doc/user/index.md b/doc/user/index.md index 22506b30498..71378920ed4 100644 --- a/doc/user/index.md +++ b/doc/user/index.md @@ -38,10 +38,10 @@ GitLab is a Git-based platform that integrates a great number of essential tools - Hosting code in repositories with version control - Tracking proposals for new implementations, bug reports, and feedback with a -fully featured [Issue Tracker](project/issues/index.md#issue-tracker) + fully featured [Issue Tracker](project/issues/index.md#issue-tracker) - Organizing and prioritizing with [Issue Boards](project/issues/index.md#issue-boards) - Reviewing code in [Merge Requests](project/merge_requests/index.md) with live-preview changes per -branch with [Review Apps](../ci/review_apps/index.md) + branch with [Review Apps](../ci/review_apps/index.md) - Building, testing and deploying with built-in [Continuous Integration](../ci/README.md) - Deploying personal and professional static websites with [GitLab Pages](project/pages/index.md) - Integrating with Docker by using [GitLab Container Registry](project/container_registry.md) @@ -51,9 +51,9 @@ With GitLab Enterprise Edition, you can also: - Provide support with [Service Desk](https://docs.gitlab.com/ee/user/project/service_desk.html) - Improve collaboration with -[Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-approvals), -[Multiple Assignees for Issues](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html), -and [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards) + [Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/index.html#merge-request-approvals), + [Multiple Assignees for Issues](https://docs.gitlab.com/ee/user/project/issues/multiple_assignees_for_issues.html), + and [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards) - Create formal relationships between issues with [Related Issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) - Use [Burndown Charts](https://docs.gitlab.com/ee/user/project/milestones/burndown_charts.html) to track progress during a sprint or while working on a new version of their software. - Leverage [Elasticsearch](https://docs.gitlab.com/ee/integration/elasticsearch.html) with [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_global_search.html) and [Advanced Syntax Search](https://docs.gitlab.com/ee/user/search/advanced_search_syntax.html) for faster, more advanced code search across your entire GitLab instance @@ -77,12 +77,12 @@ build, test, and deploy your app with built-in GitLab CI/CD. Or, you can do it all at once, from one single project. - [Repositories](project/repository/index.md): Host your codebase in -repositories with version control and as part of a fully integrated platform. + repositories with version control and as part of a fully integrated platform. - [Issues](project/issues/index.md): Explore the best of GitLab Issues' features. - [Merge Requests](project/merge_requests/index.md): Collaborate on code, -reviews, live preview changes per branch, and request approvals with Merge Requests. + reviews, live preview changes per branch, and request approvals with Merge Requests. - [Milestones](project/milestones/index.md): Work on multiple issues and merge -requests towards the same target date with Milestones. + requests towards the same target date with Milestones. ## GitLab CI/CD @@ -92,9 +92,9 @@ directly from GitLab. No third-party integrations needed. - [GitLab Auto Deploy](../ci/autodeploy/index.md): Deploy your application out-of-the-box with GitLab Auto Deploy. - [Review Apps](../ci/review_apps/index.md): Live-preview the changes introduced by a merge request with Review Apps. - [GitLab Pages](project/pages/index.md): Publish your static site directly from -GitLab with GitLab Pages. You can build, test, and deploy any Static Site Generator with Pages. + GitLab with GitLab Pages. You can build, test, and deploy any Static Site Generator with Pages. - [GitLab Container Registry](project/container_registry.md): Build and deploy Docker -images with Container Registry. + images with Container Registry. ## Account @@ -102,13 +102,13 @@ There is a lot you can customize and configure to enjoy the best of GitLab. - [Settings](profile/index.md): Manage your user settings to change your personal info, -personal access tokens, authorized applications, etc. + personal access tokens, authorized applications, etc. - [Authentication](../topics/authentication/index.md): Read through the authentication -methods available in GitLab. + methods available in GitLab. - [Permissions](permissions.md): Learn the different set of permissions levels for each -user type (guest, reporter, developer, maintainer, owner). + user type (guest, reporter, developer, maintainer, owner). - [Feature highlight](feature_highlight.md): Learn more about the little blue dots -around the app that explain certain features + around the app that explain certain features - [Abuse reports](abuse_reports.md): Report abuse from users to GitLab administrators ## Groups diff --git a/doc/user/profile/account/two_factor_authentication.md b/doc/user/profile/account/two_factor_authentication.md index 0a7c5832a2d..8e5fe4b0fb9 100644 --- a/doc/user/profile/account/two_factor_authentication.md +++ b/doc/user/profile/account/two_factor_authentication.md @@ -41,7 +41,7 @@ or a U2F device. **On your phone:** 1. Install a compatible application. We recommend [Google Authenticator] -\(proprietary\) or [FreeOTP] \(open source\). + \(proprietary\) or [FreeOTP] \(open source\). 1. In the application, add a new entry in one of two ways: - Scan the code with your phone's camera to add the entry automatically. - Enter the details provided to add the entry manually. diff --git a/doc/user/profile/index.md b/doc/user/profile/index.md index ba756c4b793..a2b15d058d7 100644 --- a/doc/user/profile/index.md +++ b/doc/user/profile/index.md @@ -35,13 +35,13 @@ From there, you can: - Manage [2FA](account/two_factor_authentication.md) - Change your username and [delete your account](account/delete_account.md) - Manage applications that can -[use GitLab as an OAuth provider](../../integration/oauth_provider.md#introduction-to-oauth) + [use GitLab as an OAuth provider](../../integration/oauth_provider.md#introduction-to-oauth) - Manage [personal access tokens](personal_access_tokens.md) to access your account via API and authorized applications - Add and delete emails linked to your account - Choose which email to use for notifications, web-based commits, and display on your public profile - Manage [SSH keys](../../ssh/README.md#ssh) to access your account via SSH - Manage your [preferences](preferences.md#syntax-highlighting-theme) -to customize your own GitLab experience + to customize your own GitLab experience - [View your active sessions](active_sessions.md) and revoke any of them if necessary - Access your audit log, a security log of important events involving your account diff --git a/doc/user/project/cycle_analytics.md b/doc/user/project/cycle_analytics.md index 529a82ded9e..05127b274e0 100644 --- a/doc/user/project/cycle_analytics.md +++ b/doc/user/project/cycle_analytics.md @@ -80,6 +80,7 @@ Here's a little explanation of how this works behind the scenes: To sum up, anything that doesn't follow the [GitLab flow] won't be tracked at all. So, the Cycle Analytics dashboard won't present any data: + - For merge requests that do not close an issue. - For issues not labeled with a label present in the Issue Board. - For issues not assigned a milestone. diff --git a/doc/user/project/import/bitbucket_server.md b/doc/user/project/import/bitbucket_server.md index ebf87890cfd..d51a0c0ccca 100644 --- a/doc/user/project/import/bitbucket_server.md +++ b/doc/user/project/import/bitbucket_server.md @@ -22,14 +22,14 @@ Import your projects from Bitbucket Server to GitLab with minimal effort. ## Limitations 1. Currently GitLab doesn't allow comments on arbitrary lines of code, so any -Bitbucket comments out of bounds will be inserted as comments in the merge -request. + Bitbucket comments out of bounds will be inserted as comments in the merge + request. 1. Bitbucket Server allows multiple levels of threading. GitLab -import will collapse this into one discussion and quote part of the original -comment. + import will collapse this into one discussion and quote part of the original + comment. 1. Declined pull requests have unreachable commits, which prevents the GitLab -importer from generating a proper diff. These pull requests will show up as -empty changes. + importer from generating a proper diff. These pull requests will show up as + empty changes. 1. Attachments in Markdown are currently not imported. 1. Task lists are not imported. 1. Emoji reactions are not imported diff --git a/doc/user/project/import/fogbugz.md b/doc/user/project/import/fogbugz.md index 17222c53675..13409c93929 100644 --- a/doc/user/project/import/fogbugz.md +++ b/doc/user/project/import/fogbugz.md @@ -23,6 +23,6 @@ users to GitLab users.  1. Once the import has finished click the link to take you to the project -dashboard. Follow the directions to push your existing repository. + dashboard. Follow the directions to push your existing repository.  diff --git a/doc/user/project/import/github.md b/doc/user/project/import/github.md index cf99dded5e2..63b90dd76fd 100644 --- a/doc/user/project/import/github.md +++ b/doc/user/project/import/github.md @@ -67,7 +67,7 @@ developer documentation. Before you begin, ensure that any GitHub users who you want to map to GitLab users have either: - A GitLab account that has logged in using the GitHub icon -\- or - + \- or - - A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with diff --git a/doc/user/project/index.md b/doc/user/project/index.md index 6a1aadf058e..c62de41c539 100644 --- a/doc/user/project/index.md +++ b/doc/user/project/index.md @@ -19,7 +19,7 @@ When you create a project in GitLab, you'll have access to a large number of - [Issue Boards](issue_board.md): Organize and prioritize your workflow - [Multiple Issue Boards](https://docs.gitlab.com/ee/user/project/issue_board.html#multiple-issue-boards): Allow your teams to create their own workflows (Issue Boards) for the same project **[STARTER]** - [Repositories](repository/index.md): Host your code in a fully -integrated platform + integrated platform - [Branches](repository/branches/index.md): use Git branching strategies to collaborate on code - [Protected branches](protected_branches.md): Prevent collaborators @@ -29,7 +29,7 @@ integrated platform - [Signing commits](gpg_signed_commits/index.md): use GPG to sign your commits - [Deploy tokens](deploy_tokens/index.md): Manage project-based deploy tokens that allow permanent access to the repository and Container Registry. - [Merge Requests](merge_requests/index.md): Apply your branching -strategy and get reviewed by your team + strategy and get reviewed by your team - [Merge Request Approvals](https://docs.gitlab.com/ee/user/project/merge_requests/merge_request_approvals.html): Ask for approval before implementing a change **[STARTER]** - [Fix merge conflicts from the UI](merge_requests/resolve_conflicts.md): @@ -38,13 +38,13 @@ strategy and get reviewed by your team of the changes proposed in a merge request in a per-branch basis - [Labels](labels.md): Organize issues and merge requests by labels - [Time Tracking](../../workflow/time_tracking.md): Track estimate time -and time spent on + and time spent on the conclusion of an issue or merge request - [Milestones](milestones/index.md): Work towards a target date - [Description templates](description_templates.md): Define context-specific -templates for issue and merge request description fields for your project + templates for issue and merge request description fields for your project - [Slash commands (quick actions)](quick_actions.md): Textual shortcuts for -common actions on issues or merge requests + common actions on issues or merge requests - [Web IDE](web_ide/index.md) **GitLab CI/CD:** @@ -68,7 +68,7 @@ common actions on issues or merge requests - [Kubernetes cluster integration](clusters/index.md): Connecting your GitLab project with a Kubernetes cluster - [GitLab Pages](pages/index.md): Build, test, and deploy your static -website with GitLab Pages + website with GitLab Pages **Other features:** @@ -76,11 +76,11 @@ website with GitLab Pages - [Snippets](../snippets.md): store, share and collaborate on code snippets. - [Cycle Analytics](cycle_analytics.md): review your development lifecycle. - [Syntax highlighting](highlighting.md): an alternative to customize -your code blocks, overriding GitLab's default choice of language. + your code blocks, overriding GitLab's default choice of language. - [Badges](badges.md): badges for the project overview. - [Releases](releases/index.md): a way to track deliverables in your project as snapshot in time of -the source, build output, and other metadata or artifacts -associated with a released version of your code. + the source, build output, and other metadata or artifacts + associated with a released version of your code. ### Project's integrations @@ -96,7 +96,7 @@ Learn how to [create a new project](../../gitlab-basics/create-project.md) in Gi You can [fork a project](../../gitlab-basics/fork-project.md) in order to: - Collaborate on code by forking a project and creating a merge request -from your fork to the upstream project + from your fork to the upstream project - Fork a sample project to work on the top of that ## Project settings diff --git a/doc/user/project/integrations/irker.md b/doc/user/project/integrations/irker.md index f220fa8497a..4fb753d1707 100644 --- a/doc/user/project/integrations/irker.md +++ b/doc/user/project/integrations/irker.md @@ -30,12 +30,12 @@ need to follow the firsts steps of the next section. 1. Click "Irker". 1. Select the "Active" checkbox. 1. Enter the server host address where `irkerd` runs (defaults to `localhost`) -in the `Server host` field on the Web page + in the `Server host` field on the Web page 1. Enter the server port of `irkerd` (e.g. defaults to 6659) in the -`Server port` field on the Web page. + `Server port` field on the Web page. 1. Optional: if `Default IRC URI` is set, it has to be in the format -`irc[s]://domain.name` and will be prepend to each and every channel provided -by the user which is not a full URI. + `irc[s]://domain.name` and will be prepend to each and every channel provided + by the user which is not a full URI. 1. Specify the recipients (e.g. #channel1, user1, etc.) 1. Save or optionally click "Test Settings". diff --git a/doc/user/project/integrations/redmine.md b/doc/user/project/integrations/redmine.md index 76a2617125e..8112aa21859 100644 --- a/doc/user/project/integrations/redmine.md +++ b/doc/user/project/integrations/redmine.md @@ -1,9 +1,9 @@ # Redmine Service 1. To enable the Redmine integration in a project, navigate to the -[Integrations page](project_services.md#accessing-the-project-services), click -the **Redmine** service, and fill in the required details on the page as described -in the table below. + [Integrations page](project_services.md#accessing-the-project-services), click + the **Redmine** service, and fill in the required details on the page as described + in the table below. | Field | Description | | ----- | ----------- | diff --git a/doc/user/project/integrations/webhooks.md b/doc/user/project/integrations/webhooks.md index cbf08a4f30a..c3fc6d4b859 100644 --- a/doc/user/project/integrations/webhooks.md +++ b/doc/user/project/integrations/webhooks.md @@ -48,9 +48,9 @@ Navigate to the webhooks page by going to your project's ## Use-cases - You can set up a webhook in GitLab to send a notification to -[Slack](https://api.slack.com/incoming-webhooks) every time a build fails, for example + [Slack](https://api.slack.com/incoming-webhooks) every time a build fails, for example - You can [integrate with Twilio to be notified via SMS](https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/) -every time an issue is created for a specific project or group within GitLab + every time an issue is created for a specific project or group within GitLab - You can use them to [automatically assign labels to merge requests](https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/). ## Webhook endpoint tips diff --git a/doc/user/project/issue_board.md b/doc/user/project/issue_board.md index 7962eeada5c..0bd565547c3 100644 --- a/doc/user/project/issue_board.md +++ b/doc/user/project/issue_board.md @@ -78,9 +78,9 @@ with labels, and from there organize and prioritize them with Issue Boards. For example, let's consider this simplified development workflow: 1. You have a repository hosting your app's codebase -and your team actively contributing to code + and your team actively contributing to code 1. Your **backend** team starts working a new -implementation, gathers feedback and approval, and pass it over to **frontend** + implementation, gathers feedback and approval, and pass it over to **frontend** 1. When frontend is complete, the new feature is deployed to **staging** to be tested 1. When successful, it is deployed to **production** @@ -88,7 +88,7 @@ If we have the labels "**backend**", "**frontend**", "**staging**", and "**production**", and an Issue Board with a list for each, we can: - Visualize the entire flow of implementations since the -beginning of the development lifecycle until deployed to production + beginning of the development lifecycle until deployed to production - Prioritize the issues in a list by moving them vertically - Move issues between lists to organize them according to the labels you've set - Add multiple issues to lists in the board by selecting one or more existing issues @@ -177,7 +177,7 @@ menu from where you can create another Issue Board and rename or delete the existing one. Using the search box at the top of the menu, you can filter the listed boards. -When you're revisiting an issue board in a project or group with multiple boards, +When you're revisiting an issue board in a project or group with multiple boards, GitLab will automatically load the last board you visited. NOTE: **Note:** @@ -234,7 +234,7 @@ group-level objects are available. NOTE: **Note:** Multiple group issue boards were originally introduced in [GitLab 10.0 Premium](https://about.gitlab.com/2017/09/22/gitlab-10-0-released/#group-issue-boards) and -one group issue board per group was made available in GitLab 10.6 Core. +one group issue board per group was made available in GitLab 10.6 Core.  diff --git a/doc/user/project/issues/automatic_issue_closing.md b/doc/user/project/issues/automatic_issue_closing.md index afb7d9ada5f..c3e06b219ff 100644 --- a/doc/user/project/issues/automatic_issue_closing.md +++ b/doc/user/project/issues/automatic_issue_closing.md @@ -1,6 +1,7 @@ # Automatic issue closing >**Notes:** +> > - This is the user docs. In order to change the default issue closing pattern, > follow the steps in the [administration docs]. > - For performance reasons, automatic issue closing is disabled for the very diff --git a/doc/user/project/issues/create_new_issue.md b/doc/user/project/issues/create_new_issue.md index 2bf4fa287e9..40040e44d64 100644 --- a/doc/user/project/issues/create_new_issue.md +++ b/doc/user/project/issues/create_new_issue.md @@ -79,6 +79,6 @@ in the same URL (since a description template just populates the description fie Follow these examples to form your new issue URL with prefilled fields. - For a new issue in the GitLab Community Edition project with a pre-entered title -and a pre-entered description, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issue[description]=Research%20idea` + and a pre-entered description, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issue[description]=Research%20idea` - For a new issue in the GitLab Community Edition project with a pre-entered title -and a pre-entered description template, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issuable_template=Research%20proposal` + and a pre-entered description template, the URL would be `https://gitlab.com/gitlab-org/gitlab-ce/issues/new?issue[title]=Validate%20new%20concept&issuable_template=Research%20proposal` diff --git a/doc/user/project/issues/due_dates.md b/doc/user/project/issues/due_dates.md index 93306437c6c..7972c14c1c4 100644 --- a/doc/user/project/issues/due_dates.md +++ b/doc/user/project/issues/due_dates.md @@ -42,6 +42,7 @@ server's timezone. Issues with due dates can also be exported as an iCalendar feed. The URL of the feed can be added to calendar applications. The feed is accessible by clicking on the _Subscribe to calendar_ button on the following pages: + - on the **Assigned Issues** page that is linked on the right-hand side of the GitLab header - on the **Project Issues** page diff --git a/doc/user/project/issues/issues_functionalities.md b/doc/user/project/issues/issues_functionalities.md index e4a3ff52e07..27b9dc51760 100644 --- a/doc/user/project/issues/issues_functionalities.md +++ b/doc/user/project/issues/issues_functionalities.md @@ -99,16 +99,16 @@ Learn more in the [Issue Weight documentation](https://docs.gitlab.com/ee/workfl #### 10. Notifications - Subscribe: if you are not a participant of the discussion on that issue, but -want to receive notifications on each new input, subscribe to it. + want to receive notifications on each new input, subscribe to it. - Unsubscribe: if you are receiving notifications on that issue but no -longer want to receive them, unsubscribe from it. + longer want to receive them, unsubscribe from it. Read more in the [notifications documentation](../../../workflow/notifications.md#issue--merge-request-events). #### 11. Reference - A quick "copy to clipboard" button for that issue's reference, `foo/bar#xxx`, where `foo` is the `username` or `groupname`, `bar` -is the `project-name`, and `xxx` is the issue number. + is the `project-name`, and `xxx` is the issue number. #### 12. Title and description @@ -138,7 +138,7 @@ interpreted as spam. #### 14. Related Merge Requests - Any merge requests mentioned in that issue's description -or in the issue discussion thread. + or in the issue discussion thread. #### 15. Award emoji @@ -152,8 +152,8 @@ know you like it without spamming them. #### 16. Thread - Comments: collaborate to that issue by posting comments in its thread. -These text fields also fully support -[GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm). + These text fields also fully support + [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm). #### 17. Comment, start a discussion, or comment and close @@ -166,7 +166,7 @@ Once you write a comment, you can either: #### 18. New Merge Request - Create a new merge request (with a new source branch named after the issue) in one action. -The merge request will automatically inherit the milestone and labels of the issue. The merge -request will automatically close that issue when it is merged. + The merge request will automatically inherit the milestone and labels of the issue. The merge + request will automatically close that issue when it is merged. - Optionally, you can just create a [new branch](../repository/web_editor.md#create-a-new-branch-from-an-issue) -named after that issue. + named after that issue. diff --git a/doc/user/project/operations/error_tracking.md b/doc/user/project/operations/error_tracking.md index 90bb92d2062..41aa5b91aa7 100644 --- a/doc/user/project/operations/error_tracking.md +++ b/doc/user/project/operations/error_tracking.md @@ -21,7 +21,7 @@ GitLab provides an easy way to connect Sentry to your project: 1. Sign up to Sentry.io or [deploy your own](#deploying-sentry) Sentry instance. 1. [Find or generate](https://docs.sentry.io/api/auth/) a Sentry auth token for your Sentry project. -Make sure to give the token at least the following scopes: `event:read` and `project:read`. + Make sure to give the token at least the following scopes: `event:read` and `project:read`. 1. Navigate to your project’s **Settings > Operations** and provide the Sentry API URL and auth token. 1. Ensure that the 'Active' checkbox is set. 1. Click **Save changes** for the changes to take effect. diff --git a/doc/user/project/pages/getting_started_part_four.md b/doc/user/project/pages/getting_started_part_four.md index e4ee2f7cdfa..05d5a2fd99a 100644 --- a/doc/user/project/pages/getting_started_part_four.md +++ b/doc/user/project/pages/getting_started_part_four.md @@ -376,11 +376,11 @@ manually in the past. Read through the to understand how to go even further on your scripts. - On this blog post, understand the concept of -[using GitLab CI `environments` to deploy your -web app to staging and production](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/). + [using GitLab CI `environments` to deploy your + web app to staging and production](https://about.gitlab.com/2016/08/26/ci-deployment-and-environments/). - On this post, learn [how to run jobs sequentially, -in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/) + in parallel, or build a custom pipeline](https://about.gitlab.com/2016/07/29/the-basics-of-gitlab-ci/) - On this blog post, we go through the process of -[pulling specific directories from different projects](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/) -to deploy this website you're looking at, docs.gitlab.com. + [pulling specific directories from different projects](https://about.gitlab.com/2016/12/07/building-a-new-gitlab-docs-site-with-nanoc-gitlab-ci-and-gitlab-pages/) + to deploy this website you're looking at, docs.gitlab.com. - On this blog post, we teach you [how to use GitLab Pages to produce a code coverage report](https://about.gitlab.com/2016/11/03/publish-code-coverage-report-with-gitlab-pages/). diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md index 595241b2cba..9a95fb70964 100644 --- a/doc/user/project/pages/getting_started_part_one.md +++ b/doc/user/project/pages/getting_started_part_one.md @@ -77,41 +77,41 @@ Learn more about [namespaces](../../group/index.md#namespaces). #### Project Websites - You created a project called `blog` under your username `john`, -therefore your project URL is `https://gitlab.com/john/blog/`. -Once you enable GitLab Pages for this project, and build your site, -it will be available under `https://john.gitlab.io/blog/`. + therefore your project URL is `https://gitlab.com/john/blog/`. + Once you enable GitLab Pages for this project, and build your site, + it will be available under `https://john.gitlab.io/blog/`. - You created a group for all your websites called `websites`, -and a project within this group is called `blog`. Your project -URL is `https://gitlab.com/websites/blog/`. Once you enable -GitLab Pages for this project, the site will live under -`https://websites.gitlab.io/blog/`. + and a project within this group is called `blog`. Your project + URL is `https://gitlab.com/websites/blog/`. Once you enable + GitLab Pages for this project, the site will live under + `https://websites.gitlab.io/blog/`. - You created a group for your engineering department called `engineering`, -a subgroup for all your documentation websites called `docs`, -and a project within this subgroup is called `workflows`. Your project -URL is `https://gitlab.com/engineering/docs/workflows/`. Once you enable -GitLab Pages for this project, the site will live under -`https://engineering.gitlab.io/docs/workflows`. + a subgroup for all your documentation websites called `docs`, + and a project within this subgroup is called `workflows`. Your project + URL is `https://gitlab.com/engineering/docs/workflows/`. Once you enable + GitLab Pages for this project, the site will live under + `https://engineering.gitlab.io/docs/workflows`. #### User and Group Websites - Under your username, `john`, you created a project called -`john.gitlab.io`. Your project URL will be `https://gitlab.com/john/john.gitlab.io`. -Once you enable GitLab Pages for your project, your website -will be published under `https://john.gitlab.io`. + `john.gitlab.io`. Your project URL will be `https://gitlab.com/john/john.gitlab.io`. + Once you enable GitLab Pages for your project, your website + will be published under `https://john.gitlab.io`. - Under your group `websites`, you created a project called -`websites.gitlab.io`. your project's URL will be `https://gitlab.com/websites/websites.gitlab.io`. -Once you enable GitLab Pages for your project, -your website will be published under `https://websites.gitlab.io`. + `websites.gitlab.io`. your project's URL will be `https://gitlab.com/websites/websites.gitlab.io`. + Once you enable GitLab Pages for your project, + your website will be published under `https://websites.gitlab.io`. > Support for subgroup project's websites was [introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) in GitLab 11.8. **General example:** - On GitLab.com, a project site will always be available under -`https://namespace.gitlab.io/project-name` + `https://namespace.gitlab.io/project-name` - On GitLab.com, a user or group website will be available under -`https://namespace.gitlab.io/` + `https://namespace.gitlab.io/` - On your GitLab instance, replace `gitlab.io` above with your -Pages server domain. Ask your sysadmin for this information. + Pages server domain. Ask your sysadmin for this information. _Read on about [Projects for GitLab Pages and URL structure](getting_started_part_two.md)._ diff --git a/doc/user/project/pages/getting_started_part_three.md b/doc/user/project/pages/getting_started_part_three.md index b2da1c85c62..daae2f4b5a3 100644 --- a/doc/user/project/pages/getting_started_part_three.md +++ b/doc/user/project/pages/getting_started_part_three.md @@ -19,7 +19,7 @@ To use one or more custom domain with your Pages site, there are two things you should consider first, which we'll cover in this guide: 1. Either if you're adding a **root domain** or a **subdomain**, for which -you'll need to set up [DNS records](#dns-records) + you'll need to set up [DNS records](#dns-records) 1. Whether you want to add an [SSL/TLS certificate](#ssl-tls-certificates) or not To finish the association, you need to [add your domain to your project's Pages settings](#add-your-custom-domain-to-gitlab-pages-settings). @@ -136,13 +136,13 @@ verify your domain's ownership with a TXT record: > **Notes**: > > - **Do not** use a CNAME record if you want to point your -`domain.com` to your GitLab Pages site. Use an `A` record instead. + `domain.com` to your GitLab Pages site. Use an `A` record instead. > - **Do not** add any special chars after the default Pages -domain. E.g., **do not** point your `subdomain.domain.com` to -`namespace.gitlab.io.` or `namespace.gitlab.io/`. + domain. E.g., **do not** point your `subdomain.domain.com` to + `namespace.gitlab.io.` or `namespace.gitlab.io/`. > - GitLab Pages IP on GitLab.com [was changed](https://about.gitlab.com/2017/03/06/we-are-changing-the-ip-of-gitlab-pages-on-gitlab-com/) in 2017 > - GitLab Pages IP on GitLab.com [has been changed](https://about.gitlab.com/2018/07/19/gcp-move-update/#gitlab-pages-and-custom-domains) -from `52.167.214.135` to `35.185.44.232` in 2018 + from `52.167.214.135` to `35.185.44.232` in 2018 ### Add your custom domain to GitLab Pages settings @@ -278,15 +278,15 @@ These fields are found under your **Project**'s **Settings** > **Pages** > **New ### What's what? - A PEM certificate is the certificate generated by the CA, -which needs to be added to the field **Certificate (PEM)**. + which needs to be added to the field **Certificate (PEM)**. - An [intermediate certificate](https://en.wikipedia.org/wiki/Intermediate_certificate_authority) (aka "root certificate") is -the part of the encryption keychain that identifies the CA. -Usually it's combined with the PEM certificate, but there are -some cases in which you need to add them manually. -[CloudFlare certs](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/) -are one of these cases. + the part of the encryption keychain that identifies the CA. + Usually it's combined with the PEM certificate, but there are + some cases in which you need to add them manually. + [CloudFlare certs](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/) + are one of these cases. - A private key is an encrypted key which validates -your PEM against your domain. + your PEM against your domain. ### Now what? @@ -295,9 +295,9 @@ of this, it's simple: - Your PEM certificate needs to be added to the first field - If your certificate is missing its intermediate, copy -and paste the root certificate (usually available from your CA website) -and paste it in the [same field as your PEM certificate](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/), -just jumping a line between them. + and paste the root certificate (usually available from your CA website) + and paste it in the [same field as your PEM certificate](https://about.gitlab.com/2017/02/07/setting-up-gitlab-pages-with-cloudflare-certificates/), + just jumping a line between them. - Copy your private key and paste it in the last field >**Note:** diff --git a/doc/user/project/pages/getting_started_part_two.md b/doc/user/project/pages/getting_started_part_two.md index c9081a6d72b..644a1c951d3 100644 --- a/doc/user/project/pages/getting_started_part_two.md +++ b/doc/user/project/pages/getting_started_part_two.md @@ -16,7 +16,7 @@ To get started with GitLab Pages, you need: 1. A project 1. A configuration file (`.gitlab-ci.yml`) to deploy your site 1. A specific `job` called `pages` in the configuration file -that will make GitLab aware that you are deploying a GitLab Pages website + that will make GitLab aware that you are deploying a GitLab Pages website 1. A `public` directory with the content of the website Optional Features: @@ -85,16 +85,16 @@ is useful for submitting merge requests to the upstream. ### Create a project from scratch 1. From your **Project**'s **[Dashboard](https://gitlab.com/dashboard/projects)**, -click **New project**, and name it considering the -[practical examples](getting_started_part_one.md#practical-examples). + click **New project**, and name it considering the + [practical examples](getting_started_part_one.md#practical-examples). 1. Clone it to your local computer, add your website -files to your project, add, commit and push to GitLab. + files to your project, add, commit and push to GitLab. 1. From the your **Project**'s page, click **Set up CI/CD**:  1. Choose one of the templates from the dropbox menu. -Pick up the template corresponding to the SSG you're using (or plain HTML). + Pick up the template corresponding to the SSG you're using (or plain HTML).  @@ -107,20 +107,20 @@ where you'll find its default URL. > **Notes:** > > - GitLab Pages [supports any SSG](https://about.gitlab.com/2016/06/17/ssg-overview-gitlab-pages-part-3-examples-ci/), but, -if you don't find yours among the templates, you'll need -to configure your own `.gitlab-ci.yml`. To do that, please -read through the article [Creating and Tweaking GitLab CI/CD for GitLab Pages](getting_started_part_four.md). New SSGs are very welcome among -the [example projects](https://gitlab.com/pages). If you set -up a new one, please -[contribute](https://gitlab.com/pages/pages.gitlab.io/blob/master/CONTRIBUTING.md) -to our examples. + if you don't find yours among the templates, you'll need + to configure your own `.gitlab-ci.yml`. To do that, please + read through the article [Creating and Tweaking GitLab CI/CD for GitLab Pages](getting_started_part_four.md). New SSGs are very welcome among + the [example projects](https://gitlab.com/pages). If you set + up a new one, please + [contribute](https://gitlab.com/pages/pages.gitlab.io/blob/master/CONTRIBUTING.md) + to our examples. > > - The second step _"Clone it to your local computer"_, can be done -differently, achieving the same results: instead of cloning the bare -repository to you local computer and moving your site files into it, -you can run `git init` in your local website directory, add the -remote URL: `git remote add origin git@gitlab.com:namespace/project-name.git`, -then add, commit, and push. + differently, achieving the same results: instead of cloning the bare + repository to you local computer and moving your site files into it, + you can run `git init` in your local website directory, add the + remote URL: `git remote add origin git@gitlab.com:namespace/project-name.git`, + then add, commit, and push. ## URLs and Baseurls diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md index 2de3fb7e080..e0b78753e21 100644 --- a/doc/user/project/pages/index.md +++ b/doc/user/project/pages/index.md @@ -91,13 +91,13 @@ site under the HTTPS protocol. ## Getting started -To get started with GitLab Pages, you can either [create a project from scratch](getting_started_part_two.md#create-a-project-from-scratch), +To get started with GitLab Pages, you can either [create a project from scratch](getting_started_part_two.md#create-a-project-from-scratch), use a [bundled template](getting_started_part_two.md#use-one-of-the-popular-pages-templates-bundled-with-gitlab), or copy any of our existing example projects: 1. Choose an [example project](https://gitlab.com/pages) to [fork](../../../gitlab-basics/fork-project.md#how-to-fork-a-project): by forking a project, you create a copy of the codebase you're forking from to start from a template instead of starting from scratch. 1. From the left sidebar, navigate to your project's **CI/CD > Pipelines** and click -**Run pipeline** so that GitLab CI/CD will build and deploy your site to the server. + **Run pipeline** so that GitLab CI/CD will build and deploy your site to the server. 1. Once the pipeline has finished successfully, find the link to visit your website from your project's **Settings > Pages**. @@ -164,7 +164,7 @@ with Pages, read through this series: ### GitLab Pages with SSL/TLS certificates -If you're using GitLab Pages default domain (`.gitlab.io`), your website will be +If you're using GitLab Pages default domain (`.gitlab.io`), your website will be automatically secure and available under HTTPS. If you're using your own domain, you can optionally secure it with SSL/TLS certificates. You can read the following tutorials to learn how to use these third-party certificates with GitLab Pages: diff --git a/doc/user/project/repository/index.md b/doc/user/project/repository/index.md index fac5975a0dc..22d912cd9d1 100644 --- a/doc/user/project/repository/index.md +++ b/doc/user/project/repository/index.md @@ -146,9 +146,9 @@ you are introducing those changes to your branch. Via command line, you can commit multiple times before pushing. - **Commit message:** -A commit message is important to identity what is being changed and, -more importantly, why. In GitLab, you can add keywords to the commit -message that will perform one of the actions below: + A commit message is important to identity what is being changed and, + more importantly, why. In GitLab, you can add keywords to the commit + message that will perform one of the actions below: - **Trigger a GitLab CI/CD pipeline:** If you have your project configured with [GitLab CI/CD](../../../ci/README.md), you will trigger a pipeline per push, not per commit. @@ -162,14 +162,14 @@ message that will perform one of the actions below: If you mention an issue or a merge request in a commit message, they will be shown on their respective thread. - **Cherry-pick a commit:** -In GitLab, you can -[cherry-pick a commit](../merge_requests/cherry_pick_changes.md#cherry-picking-a-commit) -right from the UI. + In GitLab, you can + [cherry-pick a commit](../merge_requests/cherry_pick_changes.md#cherry-picking-a-commit) + right from the UI. - **Revert a commit:** -Easily [revert a commit](../merge_requests/revert_changes.md#reverting-a-commit) -from the UI to a selected branch. + Easily [revert a commit](../merge_requests/revert_changes.md#reverting-a-commit) + from the UI to a selected branch. - **Sign a commit:** -Use GPG to [sign your commits](gpg_signed_commits/index.md). + Use GPG to [sign your commits](gpg_signed_commits/index.md). ## Repository size diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md index 3e85e97d7a5..46a1b2bc3aa 100644 --- a/doc/user/project/web_ide/index.md +++ b/doc/user/project/web_ide/index.md @@ -24,21 +24,21 @@ file path fragments to start seeing results. ## Syntax highlighting -As expected from an IDE, syntax highlighting for many languages within +As expected from an IDE, syntax highlighting for many languages within the Web IDE will make your direct editing even easier. The Web IDE currently provides: -- Basic syntax colorization for a variety of programming, scripting and markup -languages such as XML, PHP, C#, C++, Markdown, Java, VB, Batch, Python, Ruby -and Objective-C. -- IntelliSense and validation support (displaying errors and warnings, providing -smart completions, formatting, and outlining) for some languages. For example: -TypeScript, JavaScript, CSS, LESS, SCSS, JSON and HTML. +- Basic syntax colorization for a variety of programming, scripting and markup + languages such as XML, PHP, C#, C++, Markdown, Java, VB, Batch, Python, Ruby + and Objective-C. +- IntelliSense and validation support (displaying errors and warnings, providing + smart completions, formatting, and outlining) for some languages. For example: +TypeScript, JavaScript, CSS, LESS, SCSS, JSON and HTML. -Because the Web IDE is based on the [Monaco Editor](https://microsoft.github.io/monaco-editor/), -you can find a more complete list of supported languages in the -[Monaco languages](https://github.com/Microsoft/monaco-languages) repository. +Because the Web IDE is based on the [Monaco Editor](https://microsoft.github.io/monaco-editor/), +you can find a more complete list of supported languages in the +[Monaco languages](https://github.com/Microsoft/monaco-languages) repository. NOTE: **Note:** Single file editing is based on the [Ace Editor](https://ace.c9.io). diff --git a/doc/user/reserved_names.md b/doc/user/reserved_names.md index a14df6c8402..9aa81e33fc0 100644 --- a/doc/user/reserved_names.md +++ b/doc/user/reserved_names.md @@ -5,6 +5,7 @@ existing routes used by GitLab. For a list of words that are not allowed to be used as group or project names, see the [`path_regex.rb` file][reserved] under the `TOP_LEVEL_ROUTES`, `PROJECT_WILDCARD_ROUTES` and `GROUP_ROUTES` lists: + - `TOP_LEVEL_ROUTES`: are names that are reserved as usernames or top level groups - `PROJECT_WILDCARD_ROUTES`: are names that are reserved for child groups or projects. - `GROUP_ROUTES`: are names that are reserved for all groups or projects. diff --git a/doc/workflow/time_tracking.md b/doc/workflow/time_tracking.md index ad43189148c..e60b6819bf1 100644 --- a/doc/workflow/time_tracking.md +++ b/doc/workflow/time_tracking.md @@ -11,7 +11,7 @@ Time Tracking lets you: - Record the time spent working on an issue or a merge request. - Add an estimate of the amount of time needed to complete an issue or a merge -request. + request. You don't have to indicate an estimate to enter the time spent, and vice versa. |