| `db_load_balancing_hosts` | Gauge | [12.3](https://gitlab.com/gitlab-org/gitlab/-/issues/13630) | Current number of load balancing hosts | |
| `sidekiq_load_balancing_count` | Counter | 13.11 | Sidekiq jobs using load balancing with data consistency set to :sticky or :delayed | `queue`, `boundary`, `external_dependencies`, `feature_category`, `job_status`, `urgency`, `data_consistency`, `database_chosen` |
#### Providing Rails form fields to Vue applications
When composing a form with Rails, the `name`, `id`, and `value` attributes of form inputs are generated
to match the backend. It can be helpful to have access to these generated attributes when converting
to match the backend. It can be helpful to have access to these generated attributes when converting
a Rails form to Vue, or when [integrating components (datepicker, project selector, etc)](https://gitlab.com/gitlab-org/gitlab/-/blob/8956ad767d522f37a96e03840595c767de030968/app/assets/javascripts/access_tokens/index.js#L15) into it.
The [`parseRailsFormFields`](https://gitlab.com/gitlab-org/gitlab/-/blob/fe88797f682c7ff0b13f2c2223a3ff45ada751c1/app/assets/javascripts/lib/utils/forms.js#L107) utility can be used to parse the generated form input attributes so they can be passed to the Vue application.
The [`parseRailsFormFields`](https://gitlab.com/gitlab-org/gitlab/-/blob/fe88797f682c7ff0b13f2c2223a3ff45ada751c1/app/assets/javascripts/lib/utils/forms.js#L107) utility can be used to parse the generated form input attributes so they can be passed to the Vue application.
This allows us to easily integrate Vue components without changing how the form submits.
```haml
...
...
@@ -116,7 +116,7 @@ This allows us to easily integrate Vue components without changing how the form
```
> The `js_name` data attribute is used as the key in the resulting JavaScript object.
For example `= form.text_field :email, data: { js_name: 'fooBarBaz' }` would be translated
For example `= form.text_field :email, data: { js_name: 'fooBarBaz' }` would be translated
@@ -436,7 +436,7 @@ This mapping is currently generated using a combination of test coverage tracing
In the `detect-tests` job, we use this mapping to identify the minimal tests needed for the current Merge Request.
In this experiment, each `rspec` job is accompanied with a `minimal` version.
For example, `rspec unit` job has a corresponding `rspec unit minimal` job.
For example, `rspec unit` job has a corresponding `rspec unit minimal` job.
During the experiment, each Merge Request pipeline will contain both versions of the job, running in parallel.
To illustrate this:
...
...
@@ -462,7 +462,7 @@ graph LR
```
The result of both set of jobs in the pipeline is then compared to identify any false positive.
A list of such pipeline can be found in [Sisense](https://app.periscopedata.com/app/gitlab/496118/Engineering-Productivity-Sandbox?widget=10492739&udv=833427).
A list of such pipeline can be found in [Sisense](https://app.periscopedata.com/app/gitlab/496118/Engineering-Productivity-Sandbox?widget=10492739&udv=833427).
A false positive is defined as a pipeline where the `minimal` jobs passed, but the non-`minimal` jobs failed.
This indicates that the changeset resulted in a test failure, which was not detected by the `minimal` jobs.
@@ -841,6 +841,6 @@ If you see this page when trying to set a password via the web interface, make s
### Some job logs are not uploaded to object storage
When the GitLab deployment is scaled up to more than one node, some job logs may not be uploaded to [object storage](../../administration/object_storage.md) properly. [Incremental logging is required](../../administration/object_storage.md#incremental-logging-is-required-for-ci-to-use-object-storage) for CI to use object storage.
When the GitLab deployment is scaled up to more than one node, some job logs may not be uploaded to [object storage](../../administration/object_storage.md) properly. [Incremental logging is required](../../administration/object_storage.md#incremental-logging-is-required-for-ci-to-use-object-storage) for CI to use object storage.
Enable [incremental logging](../../administration/job_logs.md#enabling-incremental-logging) if it has not already been enabled.
Enable [incremental logging](../../administration/job_logs.md#enabling-incremental-logging) if it has not already been enabled.
@@ -1157,7 +1157,7 @@ For OpenAPI specifications that are generated automatically validation errors ar
-`OpenAPI 2.0 schema validation error ...`
-`OpenAPI 3.0.x schema validation error ...`
**Solution**
**Solution**
**For generated OpenAPI specifications**
...
...
@@ -1183,7 +1183,7 @@ The API Fuzzing engine outputs an error message when it cannot establish a conne
- In [GitLab 13.11 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/323939), `Failed to start scanner session (version header not found).`
- In GitLab 13.10 and earlier, `API Security version header not found. Are you sure that you are connecting to the API Security server?`.
**Solution**
**Solution**
- Remove the `FUZZAPI_API` variable from the `.gitlab-ci.yml` file. The value will be inherited from the API Fuzzing CI/CD template. We recommend this method instead of manually setting a value.
- If removing the variable is not possible, check to see if this value has changed in the latest version of the [API Fuzzing CI/CD template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/API-Fuzzing.gitlab-ci.yml). If so, update the value in the `.gitlab-ci.yml` file.
@@ -948,11 +948,11 @@ A site profile contains the following:
-**Excluded URLs**: A comma-separated list of URLs to exclude from the scan.
-**Request headers**: A comma-separated list of HTTP request headers, including names and values. These headers are added to every request made by DAST.
-**Authentication**:
-**Authenticated URL**: The URL of the page containing the sign-in HTML form on the target website. The username and password are submitted with the login form to create an authenticated scan.
-**Authenticated URL**: The URL of the page containing the sign-in HTML form on the target website. The username and password are submitted with the login form to create an authenticated scan.
-**Username**: The username used to authenticate to the website.
-**Password**: The password used to authenticate to the website.
-**Username form field**: The name of username field at the sign-in HTML form.
-**Password form field**: The name of password field at the sign-in HTML form.
-**Username form field**: The name of username field at the sign-in HTML form.
-**Password form field**: The name of password field at the sign-in HTML form.