Commit 4d4dd281 authored by Nick Gaskill's avatar Nick Gaskill

Merge branch 'selhorn-remove-whitespace' into 'master'

Removed trailing whitespaces

See merge request gitlab-org/gitlab!72308
parents 07cdce03 e34aed9b
......@@ -39,8 +39,8 @@ the LDAP server, or share email addresses.
### User deletion
Users deleted from the LDAP server are immediately blocked from signing in
to GitLab and [no longer consumes a
license](../../../user/admin_area/moderate_users.md).
to GitLab and [no longer consumes a
license](../../../user/admin_area/moderate_users.md).
However, there's an LDAP check cache time of one hour (which is
[configurable](#adjust-ldap-user-sync-schedule) for GitLab Premium users).
This means users already signed-in or who are using Git over SSH can access
......
......@@ -65,7 +65,7 @@ From left to right, the performance bar displays:
can be added by its full URL (authenticated as the current user), or by the value of
its `X-Request-Id` header.
- **Download**: a link to download the raw JSON used to generate the Performance Bar reports.
- **Flamegraph** with mode: a link to generate a [flamegraph](../../../development/profiling.md#speedscope-flamegraphs)
- **Flamegraph** with mode: a link to generate a [flamegraph](../../../development/profiling.md#speedscope-flamegraphs)
of the current URL with the selected [Stackprof mode](https://github.com/tmm1/stackprof#sampling):
- The **Wall** mode samples every *interval* of the time on a clock on a wall. The interval is set to `10100` microseconds.
- The **CPU** mode samples every *interval* of CPU activity. The interval is set to `10100` microseconds.
......
......@@ -20,7 +20,7 @@ file system performance, see
## Gitaly and NFS deprecation
Starting with GitLab version 14.0, support for NFS to store Git repository data will be deprecated. Technical customer support and engineering support will be available for the 14.x releases. Engineering will fix bugs and security vulnerabilities consistent with our [release and maintenance policy](../policy/maintenance.md#security-releases).
Starting with GitLab version 14.0, support for NFS to store Git repository data will be deprecated. Technical customer support and engineering support will be available for the 14.x releases. Engineering will fix bugs and security vulnerabilities consistent with our [release and maintenance policy](../policy/maintenance.md#security-releases).
At the end of the 14.12 milestone (tenatively June 22nd, 2022) technical and engineering support for using NFS to store Git repository data will be officially at end-of-life. There will be no product changes or troubleshooting provided via Engineering, Security or Paid Support channels.
......
......@@ -565,7 +565,7 @@ Removes a user from a group or project where the user has been explicitly assign
The user needs to be a group member to qualify for removal.
For example, if the user was added directly to a project within the group but not this
group explicitly, you cannot use this API to remove them. See
group explicitly, you cannot use this API to remove them. See
[Remove a billable member from a group](#remove-a-billable-member-from-a-group) for an alternative approach.
```plaintext
......
......@@ -415,7 +415,7 @@ Don't rely on these fields as they are slated for removal in a later release.
## Revoke a token
To revoke a token, use the `revoke` endpoint. The API returns a 200 response code and an empty
JSON hash to indicate success.
JSON hash to indicate success.
```ruby
parameters = 'client_id=APP_ID&client_secret=APP_SECRET&token=TOKEN'
......
......@@ -72,8 +72,8 @@ bundle exec rails db -e development
## Access the database with a GUI
Most GUIs (DataGrid, RubyMine, DBeaver) require a TCP connection to the database, but by default
the database runs on a UNIX socket. To be able to access the database from these tools, some steps
Most GUIs (DataGrid, RubyMine, DBeaver) require a TCP connection to the database, but by default
the database runs on a UNIX socket. To be able to access the database from these tools, some steps
are needed:
1. On the GDK root directory, run:
......
......@@ -132,7 +132,7 @@ and link to it from the merged merge request that introduced the documentation c
Circumstances, where a regular pre-merge Technical Writer review might be skipped, include:
- There is a short amount of time left before the milestone release. If less than three
- There is a short amount of time left before the milestone release. If less than three
days are remaining, seek a post-merge review and ping the writer via Slack to ensure the review is
completed as soon as possible.
- The size of the change is small and you have a high degree of confidence
......
......@@ -50,7 +50,7 @@ To help you estimate the scope of future upgrades, see the efforts required for
Before any upgrade, consider all audiences and targets, ordered by how immediately they are affected by Ruby upgrades:
1. **Developers.** We have many contributors to GitLab and related projects both inside and outside the company. Changing files such as `.ruby-version` affects everyone using tooling that interprets these files.
The developers are affected as soon as they pull from the repository containing the merged changes.
The developers are affected as soon as they pull from the repository containing the merged changes.
1. **GitLab CI/CD.** We heavily lean on CI/CD for code integration and testing. CI/CD jobs do not interpret files such as `.ruby-version`.
Instead, they use the Ruby installed in the Docker container they execute in, which is defined in `.gitlab-ci.yml`.
The container images used in these jobs are maintained in the [`gitlab-build-images`](https://gitlab.com/gitlab-org/gitlab-build-images) repository.
......@@ -58,8 +58,8 @@ When we merge an update to an image, CI/CD jobs are affected as soon as the [ima
1. **GitLab SaaS**. GitLab.com is deployed from customized Helm charts that use Docker images from [Cloud Native GitLab (CNG)](https://gitlab.com/gitlab-org/build/CNG).
Just like CI/CD, `.ruby-version` is meaningless in this environment. Instead, those Docker images must be patched to upgrade Ruby.
GitLab SaaS is affected with the next deployment.
1. **Self-managed GitLab.** Customers installing GitLab via [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) use none of the above.
Instead, their Ruby version is defined by the [Ruby software bundle](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/config/software/ruby.rb) in Omnibus.
1. **Self-managed GitLab.** Customers installing GitLab via [Omnibus](https://gitlab.com/gitlab-org/omnibus-gitlab) use none of the above.
Instead, their Ruby version is defined by the [Ruby software bundle](https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/config/software/ruby.rb) in Omnibus.
Self-managed customers are affected as soon as they upgrade to the release containing this change.
## Ruby upgrade approach
......@@ -115,7 +115,7 @@ All projects building against the same minor release automatically download the
- For [major and minor updates](https://gitlab.com/gitlab-org/gitlab-build-images/-/merge_requests/320), create a new set of Docker images that can be used side-by-side with existing images during the upgrade process. **Important:** Make sure to copy over all Ruby patch files
in the `/patches` directory to a new folder matching the Ruby version you upgrade to, or they aren't applied.
1. **[GitLab Development Kit (GDK)](https://gitlab.com/gitlab-org/gitlab-development-kit).**
Update GDK to add the new Ruby as an additional option for
Update GDK to add the new Ruby as an additional option for
developers to choose from. This typically only requires it to be appended to `.tool-versions` so `asdf`
users will benefit from this. Other users will have to install it manually
([example](https://gitlab.com/gitlab-org/gitlab-development-kit/-/merge_requests/2136).)
......@@ -166,7 +166,7 @@ we are certain that the main application test suite would catch regressions unde
NOTE:
Consult with the respective code owners whether it is acceptable to merge these changes ahead
of updating the GitLab application. It might be best to get the necessary approvals
but wait to merge the change until everything is ready.
but wait to merge the change until everything is ready.
### Prepare the GitLab application MR
......@@ -227,7 +227,7 @@ in the rollout plan.
### Create patch releases and backports for security patches
If the upgrade was a patch release and contains important security fixes, it should be released as a
If the upgrade was a patch release and contains important security fixes, it should be released as a
GitLab patch release to self-managed customers. Consult our [release managers](https://about.gitlab.com/community/release-managers/)
for how to proceed.
......@@ -252,7 +252,7 @@ We also log Ruby and Rails deprecation warnings to a dedicated log file, `log/de
(see [GitLab Developers Guide to Logging](logging.md) for where to find GitLab log files),
which can provide clues when there is code that is not adequately covered by tests and hence would slip past `DeprecationToolkitEnv`.
For GitLab SaaS, GitLab team members can inspect these log events in Kibana
For GitLab SaaS, GitLab team members can inspect these log events in Kibana
(`https://log.gprd.gitlab.net/goto/f7cebf1ff05038d901ba2c45925c7e01`).
## Recommendations
......
......@@ -283,9 +283,9 @@ end
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6763) in GitLab 14.4.
Jobs that declare either `:sticky` or `:delayed` data consistency
are eligible for database load-balancing.
In both cases, jobs are [scheduled in the future](#scheduling-jobs-in-the-future) with a short delay (1 second).
Jobs that declare either `:sticky` or `:delayed` data consistency
are eligible for database load-balancing.
In both cases, jobs are [scheduled in the future](#scheduling-jobs-in-the-future) with a short delay (1 second).
This minimizes the chance of replication lag after a write.
If you really want to deduplicate jobs eligible for load balancing,
......@@ -308,22 +308,22 @@ end
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69372) in GitLab 14.3.
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/338350) in GitLab 14.4.
The deduplication always take into account the latest binary replication pointer, not the first one.
This happens because we drop the same job scheduled for the second time and the Write-Ahead Log (WAL) is lost.
The deduplication always take into account the latest binary replication pointer, not the first one.
This happens because we drop the same job scheduled for the second time and the Write-Ahead Log (WAL) is lost.
This could lead to comparing the old WAL location and reading from a stale replica.
To support both deduplication and maintaining data consistency with load balancing,
we are preserving the latest WAL location for idempotent jobs in Redis.
This way we are always comparing the latest binary replication pointer,
To support both deduplication and maintaining data consistency with load balancing,
we are preserving the latest WAL location for idempotent jobs in Redis.
This way we are always comparing the latest binary replication pointer,
making sure that we read from the replica that is fully caught up.
FLAG:
On self-managed GitLab, by default this feature is not available.
To make it available,
On self-managed GitLab, by default this feature is not available.
To make it available,
ask an administrator to [enable the preserve_latest_wal_locations_for_idempotent_jobs flag](../administration/feature_flags.md).
FLAG:
On self-managed GitLab, by default this feature is not available.
To make it available,
On self-managed GitLab, by default this feature is not available.
To make it available,
ask an administrator to [enable the `preserve_latest_wal_locations_for_idempotent_jobs` flag](../administration/feature_flags.md).
This feature flag is related to GitLab development and is not intended to be used by GitLab administrators, though.
On GitLab.com, this feature is available but can be configured by GitLab.com administrators only.
......@@ -624,7 +624,7 @@ end
### Data consistency with idempotent jobs
For [idempotent jobs](#idempotent-jobs) that declare either `:sticky` or `:delayed` data consistency, we are
[preserving the latest WAL location](#preserve-the-latest-wal-location-for-idempotent-jobs) while deduplicating,
[preserving the latest WAL location](#preserve-the-latest-wal-location-for-idempotent-jobs) while deduplicating,
ensuring that we read from the replica that is fully caught up.
## Jobs with External Dependencies
......
......@@ -23,7 +23,7 @@ Tracking implementations must have an `action` and a `category`. You can provide
### Usage recommendations
- Use [data attributes](#implement-data-attribute-tracking) on HTML elements that emit `click`, `show.bs.dropdown`, or `hide.bs.dropdown` events.
- Use the [Vue mixin](#implement-vue-component-tracking) for tracking custom events, or if the supported events for data attributes are not propagating.
- Use the [Vue mixin](#implement-vue-component-tracking) for tracking custom events, or if the supported events for data attributes are not propagating.
- Use the [tracking class](#implement-raw-javascript-tracking) when tracking raw JavaScript files.
### Implement data attribute tracking
......@@ -86,13 +86,13 @@ Be careful, as this behavior can be confused with the `ActionView` helper method
### Implement Vue component tracking
For custom event tracking, use a Vue `mixin` in components. Vue `mixin` exposes the `Tracking.event` static method and the `track` method called from components or templates. You can specify tracking options in `data` or `computed`. These options override any defaults and allow the values to be dynamic from props or based on state.
For custom event tracking, use a Vue `mixin` in components. Vue `mixin` exposes the `Tracking.event` static method and the `track` method called from components or templates. You can specify tracking options in `data` or `computed`. These options override any defaults and allow the values to be dynamic from props or based on state.
Default options are passed when an event is tracked from the component. If you don't specify an option, the default `document.body.dataset.page` is used. The default options are:
Default options are passed when an event is tracked from the component. If you don't specify an option, the default `document.body.dataset.page` is used. The default options are:
- `category`
- `label`
- `property`
- `property`
- `value`
To implement Vue component tracking:
......@@ -128,7 +128,7 @@ To implement Vue component tracking:
};
```
1. To receive event data as a tracking object or computed property:
1. To receive event data as a tracking object or computed property:
- Declare it in the `data` function. Use a `tracking` object when default event properties are dynamic or provided at runtime:
```javascript
......@@ -223,7 +223,7 @@ describe('RightSidebar.vue', () => {
### Implement raw JavaScript tracking
To call custom event tracking and instrumentation directly from the JavaScript file, call the `Tracking.event` static function.
To call custom event tracking and instrumentation directly from the JavaScript file, call the `Tracking.event` static function.
The following example demonstrates tracking a click on a button by manually calling `Tracking.event`.
......
......@@ -184,7 +184,7 @@ in the pipeline:
- Fetches these source files from all test jobs.
- Generates and uploads the report to the `GCS` bucket `gitlab-qa-allure-report` under the project `gitlab-qa-resources`.
A common CI template for report uploading is stored in
A common CI template for report uploading is stored in
[`allure-report.yml`](https://gitlab.com/gitlab-org/quality/pipeline-common/-/blob/master/ci/allure-report.yml).
#### Merge requests
......
......@@ -783,7 +783,7 @@ often using fixtures to validate correct integration with the backend code.
### Use fixtures
To import a JSON fixture, `import` it using the `test_fixtures` alias.
To import a JSON fixture, `import` it using the `test_fixtures` alias.
```javascript
import responseBody from 'test_fixtures/some/fixture.json' // loads spec/frontend/fixtures/some/fixture.json
......
......@@ -25,7 +25,7 @@ Amazon provides a managed Kubernetes service offering known as [Amazon Elastic K
\*Cost calculations for actual implementations are a rough guideline with the following considerations:
- Actual choices about instance types should be based on GPT testing of your configuration.
- Actual choices about instance types should be based on GPT testing of your configuration.
- The first year of actual usage will reveal potential savings due to lower than expected usage, especially for ramping migrations where the full loading takes months, so be careful not to commit to savings plans too early or for too long.
- The cost estimates assume full scale of the Kubernetes cluster nodes 24 x 7 x 365. Savings due to 'idling scale-in' are not considered because they are highly dependent on the usage patterns of the specific implementation.
- Costs such as GitLab Runners, data egress and storage costs are not included as they are very dependent on the configuration of a specific implementation and on development behaviors (for example, frequency of committing or frequency of builds).
......
......@@ -102,7 +102,7 @@ When creating new applications, you can opt-out of expiry for backward compatibi
Existing:
- Applications can have expiring access tokens. Edit the application and select
**Expire access tokens** to enable them.
**Expire access tokens** to enable them.
- Tokens must be [revoked](../api/oauth2.md#revoke-a-token) or they don't expire.
## Authorized applications
......
......@@ -52,7 +52,7 @@ in your SAML IdP:
sudo -u git -H editor config/gitlab.yml
```
1. See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration) for initial settings.
1. To allow your users to use SAML to sign up without having to manually create
an account first, add the following values to your configuration:
......
......@@ -13,7 +13,7 @@ You don't need to install anything to use GitLab SaaS, you only need to
- [A license tier](https://about.gitlab.com/pricing/).
- [The number of seats you want](#how-seat-usage-is-determined).
All GitLab SaaS public projects, regardless of the subscription, get access to features in the **Ultimate** tier.
Qualifying open source projects also get 50,000 CI minutes and free access to the **Ultimate** tier
through the [GitLab for Open Source program](https://about.gitlab.com/solutions/open-source/).
......
......@@ -72,7 +72,7 @@ during the time period (including projects in any subgroups of the given group).
## Adoption over time
The **Adoption over time** chart in the **Overview** tab displays DevOps Adoption over time. The chart displays the total number of adopted features from the previous twelve months,
The **Adoption over time** chart in the **Overview** tab displays DevOps Adoption over time. The chart displays the total number of adopted features from the previous twelve months,
from when you enabled DevOps Adoption for the group.
The tooltip displays information about the features tracked for individual months.
......
......@@ -83,7 +83,7 @@ Kubernetes version to any supported version at any time:
[Adding support to other versions of Kubernetes is managed under this epic](https://gitlab.com/groups/gitlab-org/-/epics/4827).
Some GitLab features may support versions outside the range provided here.
Some GitLab features may support versions outside the range provided here.
## Cluster levels
......
......@@ -12,8 +12,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
The Composer package registry for GitLab is under development and isn't ready for production use due to
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6817) details the remaining
work and timelines to make it production ready.
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6817) details the remaining
work and timelines to make it production ready.
Publish [Composer](https://getcomposer.org/) packages in your project's Package Registry.
Then, install the packages whenever you need to use them as a dependency.
......
......@@ -11,8 +11,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
The Conan package registry for GitLab is under development and isn't ready for production use due to
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6816) details the remaining
work and timelines to make it production ready.
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6816) details the remaining
work and timelines to make it production ready.
Publish Conan packages in your project's Package Registry. Then install the
packages whenever you need to use them as a dependency.
......
......@@ -908,7 +908,7 @@ these steps:
### Troubleshoot as a GitLab server administrator
Troubleshooting the GitLab Container Registry, most of the times, requires
Troubleshooting the GitLab Container Registry, most of the times, requires
you to log in to GitLab server with the Administrator role.
[Read how to troubleshoot the Container Registry](../../../administration/packages/container_registry.md#troubleshooting).
......
......@@ -12,8 +12,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
The Debian package registry for GitLab is under development and isn't ready for production use due to
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6057) details the remaining
work and timelines to make it production ready.
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6057) details the remaining
work and timelines to make it production ready.
Publish Debian packages in your project's Package Registry. Then install the
packages whenever you need to use them as a dependency.
......
......@@ -14,8 +14,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
The Go package registry for GitLab is under development and isn't ready for production use due to
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/3043) details the remaining
work and timelines to make it production ready.
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/3043) details the remaining
work and timelines to make it production ready.
With the Go proxy for GitLab, every project in GitLab can be fetched with the
[Go proxy protocol](https://proxy.golang.org/).
......
......@@ -10,8 +10,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
The Helm chart registry for GitLab is under development and isn't ready for production use due to
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6366) details the remaining
work and timelines to make it production ready.
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/6366) details the remaining
work and timelines to make it production ready.
Publish Helm packages in your project's Package Registry. Then install the
packages whenever you need to use them as a dependency.
......
......@@ -10,8 +10,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
WARNING:
The Ruby gems package registry for GitLab is under development and isn't ready for production use due to
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/3200) details the remaining
work and timelines to make it production ready.
limited functionality. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/3200) details the remaining
work and timelines to make it production ready.
You can publish Ruby gems in your project's Package Registry, then install the packages when you
need to use them as a dependency. Although you can push gems to the registry, you cannot install
......
......@@ -192,6 +192,6 @@ branch](../protected_branches.md).
- The owner associated to a deploy key does not have [membership](../members/index.md) to the project of the protected branch.
- **No one** is selected in [the "Allowed to push" section](../protected_branches.md#configure-a-protected-branch) of the protected branch.
All deploy keys are associated to an account. Since the permissions for an account can change, this might lead to scenarios where a deploy key that was working is suddenly unable to push to a protected branch.
All deploy keys are associated to an account. Since the permissions for an account can change, this might lead to scenarios where a deploy key that was working is suddenly unable to push to a protected branch.
We recommend you create a service account, and associate a deploy key to the service account, for projects using deploy keys.
......@@ -18,7 +18,7 @@ Such problems can be detected with [git-sizer](https://github.com/github/git-siz
Rewriting a repository can remove unwanted history to make the repository smaller.
We **recommend [`git filter-repo`](https://github.com/newren/git-filter-repo/blob/main/README.md)**
over [`git filter-branch`](https://git-scm.com/docs/git-filter-branch) and
[BFG](https://rtyley.github.io/bfg-repo-cleaner/).
[BFG](https://rtyley.github.io/bfg-repo-cleaner/).
WARNING:
Rewriting repository history is a destructive operation. Make sure to back up your repository before
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment