This change updates the text of the pipeline widget that appears on the
merge request page. The text has been made more consistent between
different types of pipelines; this makes the front-end implementation
simpler and more maintainable.  In addition, the type of pipeline is
(i.e. regular pipeline, merge request pipeline, detached pipeline)
included in the text, making this type more obvious to the end user.

Some information has been removed from the widget as part of this
change; however, any information that was removed already appears
elsewhere on the merge request page.

Detect if pipeline runs for a GitHub pull request

When using a mirror for CI/CD only we register a pull_request
webhook. When a pull_request webhook is received, if the
source branch SHA matches the actual head of the branch in the
repository we create immediately a new pipeline for the
external pull request. Otherwise we store the
pull request info for when the push webhook is received.

When using "only/except: external_pull_requests" we can detect
if the pipeline has a open pull request on GitHub and create or
not the job based on that.

Since it is not possible to dynamically detect if a job is automatically
cancellable or not, a this new attribute is necessary. Moreover, it let
the maintainer of the repo to adjust the behaviour of the auto cancellation
feature to match exactly what he needs.

This commit adds pipeline.type key to PipelineEntity.
This key will be used in MR widget in the next iteration.

This is a port from EE changes where
we introduce a new limit for Plan model.

https://dev.gitlab.org/gitlab/gitlab-ee/merge_requests/1182

Ports changes from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/12343

This changes used worker from `BuildProcessWorker`
to `PipelineProcessWorker` to make pipeline
processing much simpler. We process `pipeline_id`,
based on some triggers.

This changes `needs:` from weak reference
to have a strong reference.

This means that job will not be created
unless all needs are present as part of
a pipeline.

This implements the support for `needs:` keyword
as part of GitLab CI. That makes some of the jobs
to be run out of order.

* Reword Project#latest_successful_build_for to
Project#latest_successful_build_for_ref
* Reword Ci::Pipeline#latest_successful_for to
Ci::Pipeline#latest_successful_build_for_ref

Adds ability to find builds by sha when only specifying a ref.

None of this code can be reached any more, so it can all be removed

Updates changed method names and fixes spec failures

Use the shared method in Ci::Pipeline

As we have a central domain for auto merge process today,
we should use a single worker for any auto merge process.

- Adds an endpoint on PipelinesController
- Adds a service that iterates over every build in a stage and
plays it.
- Includes 'play_manual' details on EntitySerializer
- Builds a new Stage state: PlayManual. An stage can take this status if
it has manual builds or an skipped, scheduled or manual status
- Includes FE modifications and specs

With Pipelines for Merge Requests feature, users cannout keep using
$CI_COMMIT_REF_NAME and _SLUG predefined variables for dynamic
environments. We fix this problem by explicitly looking at the source
ref.

This backports the changes from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/10452

This variable shows if the branch the runner is executing is protected
or not.
References: #50909

Used to get the variables via the API endpoint
`/projects/:id/pipelines/:pipeline_id/variables`

Signed-off-by: Agustin Henze <tin@redhat.com>

This is for merge request pipelines

By using `refs/merge-requests/:iid/head`

ok

ok

Improve naming nicely

Add nice tests

add nice tests

fix some more

revert

This avoids the case:

```
allow_ref_name_caching do
  allow_ref_name_caching do
    # using-feature
  end
end
```

For a given merge request, it's quite common to see duplicate FindCommit
Gitaly requests because the Gitaly CommitService caches the request by
the commit SHA, not by the ref name. However, most of the duplicate
requests use the ref name, so the cache is never actually used in
practice. This leads to unnecessary requests that slow performance.

This commit allows certain callers to bypass the ref name to
OID conversion in the cache. We don't do this by default because it's
possible the tip of the branch changes during the commit, which
would cause the caller to get stale data.

This commit also forces the Ci::Pipeline to use the full ref name
so that caching can work for merge requests.

Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/57083

Nathan Friend authored 5 years ago and Filipa Lacerda committed 5 years ago

This commit updates the pipeline block that appears on the merge request
page to include information that will be exposed by the API as part of
the post-merge pipeline feature.

Introduces a new status for builds between :created and :pending
that will be used when builds require one or more prerequisite
actions to be completed before being picked up by a runner
(such as creating Kubernetes resources before deploying).

The existing :created > :pending transition is unchanged, so
only builds that require preparation will use the :preparing
status.

Make it sane

Include merge ref head

Fix union

Improve a bit

Add spec

remove

add spec

Add changelog

fix coding offence

Apply suggestion to spec/models/merge_request_spec.rb

ok

ok

Fix

Fix spec

Fix spec

fix

Simplify the things

Memoize

OK

a

fix it ok

Fix

head pipeline

Fix

ok

Add spec

Fix

ok

Fix

Add changelog

Fix

Add memoization

a

fix

between Ci::Pipeline and Ci::Build

Add spec

Add more tests

ok