When the owner of a pipelines schedule was either blocked or was removed
from the project, the pipeline schedular would still schedule the
pipeline.

This would than fail however, given the user had no access to the
project and it contents. However, a better way to handle it would be to
not schedule it at all. Furthermore, from now on, such schedules will be
deactivated so the schedule worker can ignore it on the next runs.

Allow numeric values in gitlab-ci.yml

Closes #30017

See merge request !10607

Fix adding defaults for concurrent column renames

See merge request !11335

Added balsamiq jasmine integration test

Closes #31889

See merge request !11257

add username field to push webhook

Closes #32136

See merge request !11272

Fix typo in code snippet to match text below

See merge request !11101

Fix the GitLab EE link

See merge request !11021

fix $CI_JOB_ID variable

See merge request !10966

Fetch commit deltas from Gitaly

Closes gitaly#199

See merge request !11122

Ensure schedule_form and schedules_index both utilize common_vue bundle

See merge request !11274

Closes gitaly#199

Backport New SystemHook: `repository_update`

Closes #26325

See merge request !11140

[ci skip]

[ci skip]

Wait for requests after each Spinach scenario instead of feature

See merge request !11349

[ci skip]

[ci skip]

Link to a case where we can't support MySQL

Closes #32181

See merge request !11334

Remove trailing comma in dependency linker to satisfy Rubocop

See merge request !11348

Add fixed positioning to top level navbar

Closes #30975

See merge request !10751

Relax rake backup regex to handle CE and EE RCs

See merge request !11345

Fix conflict resolution from corrupted upstream

Closes gitlab-ee#2128

See merge request !11298

New branch new mr docs

See merge request !11308

See http://rubular.com/r/uTDlT85zW1

I don't know why this happens exactly, but given an upstream and fork repository
from a customer, both of which required GC, resolving conflicts would corrupt
the fork so badly that it couldn't be cloned.

This isn't a perfect fix for that case, because the MR may still need to be
merged manually, but it does ensure that the repository is at least usable.

My best guess is that when we generate the index for the conflict
resolution (which we previously did in the target project), we obtain a
reference to an OID that doesn't exist in the source, even though we already
fetch the refs from the target into the source.

Explicitly setting the source project as the place to get the merge index from
seems to prevent repository corruption in this way.

Usage ping updates

Closes #31741 and #31453

See merge request !11231

Improve project list cache key

Closes #31863

See merge request !11325

Autolink package names in Gemfile

See merge request !11224