**app/mailers/emails/pipelines.rb:**

Make notification email subject more concise.

**app/views/notify/pipeline_failed_email.html.haml:**
**app/views/notify/pipeline_failed_email.text.erb:**
**app/views/notify/pipeline_fixed_email.html.haml:**
**app/views/notify/pipeline_fixed_email.text.erb:**
**app/views/notify/pipeline_success_email.html.haml:**
**app/views/notify/pipeline_success_email.text.erb:**

Make notification title more concise.

**spec/mailers/emails/pipelines_spec.rb:**
**spec/views/notify/pipeline_failed_email.html.haml_spec.rb:**
**spec/views/notify/pipeline_failed_email.text.erb_spec.rb:**
**spec/views/notify/pipeline_fixed_email.html.haml_spec.rb:**
**spec/views/notify/pipeline_fixed_email.text.erb_spec.rb:**
**spec/views/notify/pipeline_success_email.html.haml_spec.rb:**
**spec/views/notify/pipeline_success_email.text.erb_spec.rb:**

Update tests.

Change type of CiJob.needs [RUN AS-IF-FOSS]

See merge request gitlab-org/gitlab!50192

Add CI config validation message on editor

See merge request gitlab-org/gitlab!50507

Fix Dependency Scanning

See merge request gitlab-org/gitlab!50780

This reverts commit ebf5c7ab2d9aee0aced21334eaab6eccac90b7d0.

Fix a typo in Dependency Scanning docs

See merge request gitlab-org/gitlab!50733

Expand on use of separate name attributes in LDAP

See merge request gitlab-org/gitlab!50594

The `name` attribute in LDAP fetches the user's visible name in profiles
but often the ideal value for this is split between two different fields
that are configurable via  the use of `first_name` and `last_name`.

The docs were not very clear on how to force use of the latter (split)
configuration over `name`, doable by intentionally setting it to
something non-existent.

Clarify that Pages domain should be pointing at Pages's IP

See merge request gitlab-org/gitlab!50613

Fix source link in Usage Ping documentation

See merge request gitlab-org/gitlab!50982

This changes the type of `CiJob.needs` from `JobType.connection_type`
to `BuildNeedType.connection_type`. This is because `Build#needs` does
not return a relation of builds, but one of `Ci::BuildNeed`.

This change is a backwards compatible bug-fix.
Any query that works now will continue to work.

This change adds a validation message similar to the one found in the
blo viewer to validate the CI config as the user modifies it.

Add a trial status sidebar widget behind feature flag

See merge request gitlab-org/gitlab!50090

- Add new experiment definition
- Add YAML definition for new feature flag
- Add a bunch of helper methods related specifically to trials on groups
- Test those new helper methods
- Add translation keys

Remove unwrapArrayOfJobs function

See merge request gitlab-org/gitlab!50944

Remove duplicate JSON schema matcher

See merge request gitlab-org/gitlab!50727

Delete unused images

See merge request gitlab-org/gitlab!50932

Make Vlad to be DRI for Cloud Native Pages

See merge request gitlab-org/gitlab!50832

Block confidential quick action for test cases

See merge request gitlab-org/gitlab!50460

Change gitlab-ci.yaml to gitlab-ci.yml docs

See merge request gitlab-org/gitlab!50901

Correct extension from 'yaml' to 'yml'.

Tweak list indentation

See merge request gitlab-org/gitlab!50931

This line in the Usage Ping documentation was correct when written,
but the referenced file changed location. This updates the reference
to refer to the new subdirectory, to fix the link in a way that matches
the convention on this documentation page.

Drop temporary index on ci builds

See merge request gitlab-org/gitlab!50961

Hide /confidential quick action
for issues with test case type

We had three JSON schema matchers:

1. `match_schema` - takes a data structure and a path to a schema file.
2. `match_response_schema` - takes a response object and a path to a
   schema file.
3. `according_to_schema` - chained matcher on `be_valid_json`, takes a
   schema literal.

The reason for this is that we wanted to operate on various axes:

1. Are we validating a parsed data structure, or a potentially-JSON
   string?
2. Are we providing a path to a schema file, or a literal data structure
   representing a schema?

Happily, the library we're using already solves problem 1 for us.
https://github.com/ruby-json-schema/json-schema#validation says:

> All methods take two arguments, which can be either a JSON string, a
> file containing JSON, or a Ruby object representing JSON data.

So we just needed to solve concern 2, and we handle that by assuming
that if the schema argument is a string, it's not a JSON string
representing the schema, but a path to a schema file.

To handle the chaining that `according_to_schema` had, we can just use
RSpec's `and` method:

    be_valid_json.and match_schema(build_info_payload_schema)

Adds Tier section to feature proposal

See merge request gitlab-org/gitlab!50835

Relates to https://gitlab.com/gitlab-org/gitlab/-/issues/295477

Update Gitaly version

See merge request gitlab-org/gitlab!50953

Clean up second Gitaly process in tests

See merge request gitlab-org/gitlab!50855

Try to find elements before waiting for requests

See merge request gitlab-org/gitlab!50919

Upgrade acts-on-taggable to v7.0.0

See merge request gitlab-org/gitlab!50717

Convert incident_management_list.scss into page specific bundle

See merge request gitlab-org/gitlab!50769

Update Gitaly version

See merge request gitlab-org/gitlab!50942

ci: Only keep relevant files after installing tests dependencies

See merge request gitlab-org/gitlab!49014