Add k3s specs
Remove unused k3s_hostname method
Remove :requires_admin tag from k8s spec
Always set allow local requests before and after

Add confidential attribute to notes

See merge request gitlab-org/gitlab!25784

Docs: Add missing serial commas to text

See merge request gitlab-org/gitlab!26031

Remove refreshData function logic from issue.js

See merge request gitlab-org/gitlab!21409

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/21409

The pages included in this commit all had missing Oxford (serial)
commas. In most cases, I added the comma but took no other action;
a few pages required slight rewording.

Update security release template for the new setup

See merge request gitlab-org/gitlab!25901

Jestodus lib utils common utils

See merge request gitlab-org/gitlab!25676

- Keeps specs that require browser environment in a new `browser_spec`
- https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25676

Convert dashboard keys (e.g. panel_groups) to camel case

See merge request gitlab-org/gitlab!25522

Remove project_path key in environments entity

See merge request gitlab-org/gitlab!25365

Add project and group to feature flag check

See merge request gitlab-org/gitlab!25894

- group page
- project page

Scope name uniqueness of approval rules to type

See merge request gitlab-org/gitlab!25875

Add file path validator to custom validations module

Closes #33768

See merge request gitlab-org/gitlab!24223

Removing Bronze Plan from Repository size limit

See merge request gitlab-org/gitlab!25787

Refactor vulnerability-details component for better reusability

See merge request gitlab-org/gitlab!25830

Update babel to latest version (7.7.5 -> 7.8.5)

See merge request gitlab-org/gitlab!25964

https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25964

Add storage consideration

Closes #35641

See merge request gitlab-org/gitlab!24479

This extends Definition of Done to add storage consideration when
dealing with temporary and persistent storage.

Include Separation of Duties in compliance docs

See merge request gitlab-org/gitlab!24110

Docs: Fix style issues on applications page

See merge request gitlab-org/gitlab!25653

The WAF portion of the Applications page needed some minor style
fixes, and also contained the remnant of an incomplete merge. This
merge request corrects these style issues.

Don't parse undefined severity confidence from reports

See merge request gitlab-org/gitlab!25884

Return commits by author

See merge request gitlab-org/gitlab!25597

- Fix ESLint errors
- Update gitlab.pot translations
- Use optional chaining
- Make template prettier
- Extract `find` helper in specs
- [Use refs][1] instead of legacy `js-` classes for component testing

And last but not least: import used `expand-button` component.

It turns out the original creation of this component wasn't perfect,
done in 18d13bf7, as it didn't bring
over the `expand-button` component from the parent modal from which it
was extracted.

Still, this went unnoticed for around 10 months, so I'm not convinced
`instances` are often - or ever - present in vulnerabilities/findings.

The snapshot test has been updated to include it as well.

[1]: https://docs.gitlab.com/ce/development/testing_guide/frontend_testing.html#how-to-query-dom-elements

This completely removes the old `vulnerability-details` component and
replaces it with the new one.

Now that the bulk of snapshots have served their purpose, they have been
removed, along with now-unsued mocks.

This modifies the modal component to use the new `vulnerability-details`
component, and removes now-unused store mutations and state.

This also:

- moves the `modal.data.project` store state to `modal.project`
- removes an unused `project_id` field from the modal, since it was
  guaranteed to always be `undefined`, and was not consumed by any child
  component

Now that the details are rendered explicitly, the markup had a lot of
duplication. This abstracts that duplication into a functional
component.

This refactors the new `vulnerability-details` component to explicitly
render the markup for the various details of the vulnerability, without
going through an unnecessary transformation stage.

This is preferable (though more verbose) because different details are
rendered in different ways. Before, the template resembled the
[loop-switch sequence][2] anti-pattern, and adding special cases was
awkward.

The snapshot changes in this commit are simply whitespace changes and
added/missing HTML comments, resulting from the different conditional
rendering logic.

This addresses [issue 32039][1].

[1]: https://gitlab.com/gitlab-org/gitlab/issues/32039
[2]: https://en.wikipedia.org/wiki/Loop-switch_sequence

This swaps out the component factory functions which rendered the old
`vulnerability-details` component, in each of the MR and Security
Dashboard contexts, with a new factory function that renders only the
new version of the component.

The snapshot changes in this commit correspond to the expected changes:

- the MR context now includes (if available):
  - the project the vulnerability belongs to
  - the report type of the vulnerability
  - the line number information for the `file`
- the Security Dashboard context now includes (if available):
  - the method in which the vulnerability was detected

This ports the existing tests for the old `vulnerability-details`
component to the new one, since it now accepts a `vulnerability` prop
rather than a `details` prop.

This duplicates the existing `vulnerability-details` component, and
replaces its `details` prop  with a `vulnerability` prop.

To achieve this, the data transformations which turned a `vulnerability`
object into a `details` object have been naively copied into this new
component.

The main data transformation is copied mostly verbatim from the
[SET_MODAL_DATA mutation][1] in the Security Dashboard store, rather
than from [SET_ISSUE_MODAL_DATA][2] mutation in the security reports
store in the Merge Request page. This is because the former is slightly
more complete than the latter:

- it includes the project the vulnerability belongs to
- it includes the report type of the vulnerability
- it includes line number information for the `file`, if it exists

The latter, however, includes the method in which the vulnerability was
detected, if it exists.

All this is to say that in addition to rendering everything the old
component did, the new component:

- in the MR context:
  - includes the project the vulnerability belongs to (if available)
  - includes the report type of the vulnerability (if available)
  - includes line number information for the `file` (if available)
- in the Security Dashboard context:
  - includes the method in which the vulnerability was detected (if
    available)

The [secondary transformation `valuedFields`][3] is copied almost
verbatim from the containing modal.

[1]: https://gitlab.com/gitlab-org/gitlab/blob/v12.8.1-ee/ee/app/assets/javascripts/security_dashboard/store/modules/vulnerabilities/mutations.js#L76-158
[2]: https://gitlab.com/gitlab-org/gitlab/blob/v12.8.1-ee/ee/app/assets/javascripts/vue_shared/security_reports/store/mutations.js#L135-172
[3]: https://gitlab.com/gitlab-org/gitlab/blob/v12.8.1-ee/ee/app/assets/javascripts/vue_shared/security_reports/components/modal.vue#L123-138

This adds snapshot tests for the `vulnerability-details` component as it
currently exists in the two main contexts it appears in:

- in Merge Requests
- any Security Dashboard

Snapshots for both contexts are created, because the data is processed
in slightly (though very similar) ways in each.

A relatively wide selection of real vulnerability findings is used in
both contexts to ensure good coverage.

The purpose is to establish a baseline to facilitate refactoring the
component, and the data paths in both contexts, without changing the
final rendered output.

Ensure temp export data is removed if Group/Project export failed

See merge request gitlab-org/gitlab!25828

Use available? method for Elastic Stack availability

See merge request gitlab-org/gitlab!25615