fix changelog MR reference

add non-HEAD builds finder and add `created` pipelines to scope

add spec for auto-cancel non-HEAD pipelines and refactor create_pipeline_service_spec

more refactoring for spec

adds option for auto-cancel into CI/CD settings

fix spec to new configuration

fix rubocop

fix schema.rb

fix schema.rb

replace Gitlab 9.0 with 9.1 in doc

change wording on pipeline settings

added auto_canceled_by field as identifier of autocancel subject

remove unnecessary index

replace service with retry_lock

replace auto_cancel_pending_pipelines boolean setting with integer (and enum in model)

fix schema.rb

fix schema.rb

remove projekt attribute and clean up spec

clean up spec withcouple of shared examples

added spec for "It does not cancel current pipeline" scenario

add some specs to auto-cancel

add spec for another branch pipelines

1. Never send a pipeline email to anyone other than the user who created
   the pipeline.
2. Only send pipeline success emails to people with the custom
   notification setting for enabled. Watchers and participants will
   never receive this.
3. When custom settings are unset (for new settings and legacy ones),
   act as if failed_pipeline is set.

From Bullet failures in !10263

This reverts commit e00fb2bdc2090e9cabeb1eb35a2672a882cc96e9.

# Conflicts:
#	.rubocop.yml
#	.rubocop_todo.yml
#	lib/gitlab/ci/config/entry/global.rb
#	lib/gitlab/ci/config/entry/jobs.rb
#	spec/lib/gitlab/ci/config/entry/factory_spec.rb
#	spec/lib/gitlab/ci/config/entry/global_spec.rb
#	spec/lib/gitlab/ci/config/entry/job_spec.rb
#	spec/lib/gitlab/ci/status/build/factory_spec.rb
#	spec/lib/gitlab/incoming_email_spec.rb

This reverts commit cb10b725c8929b8b4460f89c9d96c773af39ba6b.

Since we already know which ref we want, we could filter it out first.

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/issues/26570#note_23423376

Closes #26570

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8286#note_20461082

This reverts merge request !8286

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/8286/diffs#note_20433402

The name latest implies that it's reverse chronological,
and we did expect it that way.

https://gitlab.com/gitlab-org/gitlab-ce/issues/25993#note_20429761


> ok, I think markglenfletchera is correct in
> https://gitlab.com/gitlab-com/support-forum/issues/1394#note_20399939
> that `Project#latest_successful_builds_for` is giving oldest pipeline
> rather than latest pipeline. This is a ~regression introduced by !7333
> where `order(id: :desc)` was removed causing this. The offending change
> was:
> https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7333/diffs#b22732e5f39e176c7c719fe485847d0fb0564275_92_108
>
> The confusion was caused by the `latest` name implication, which
> actually didn't order anything, and I think we should add `order(id:
> :desc)` to `Ci::Pipeline.latest` otherwise it's confusing that it's not
> actually ordered.


Closes #25993

[ci skip]

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7333#note_20058743

Feedback:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/7333#note_20003268