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.
- Added Gitlab::Ci::Config::Entry::Rules and Gitlab::Ci::Config::Entry::Rules:Rule
to handle lists of Rule objects to be evalauted for job inclusion
- Added `if:` and `changes:` as available Rules::Rule::Clause classes
- Added Rules handling logic to Seed::Build#included? with extra specs
- Use DisallowedKeysValidator to mutually exclude rules: from only:/except: on job config
Kubernetes deployments on new clusters will now have
a separate namespace per project environment, instead
of sharing a single namespace for the project.
Behaviour of existing clusters is unchanged.
All new functionality is controlled by the
:kubernetes_namespace_per_environment feature flag,
which is safe to enable/disable at any time.
All deployments should have already their cluster_id filled in on
creation. Legacy deployments will not be retried as:-
* Ci::Build#retry calls `Ci::RetryBuildService`
* Ci::Pipeline#retry
calls `Ci::RetryPipelineService` which also calls
`Ci::RetryBuildService`
* `Ci::RetryBuildService` will clone a build to retry
It is also impossibly to backfill Deployment#cluster_id from
Project#deployment_platform correctly as clusters could have been
deleted, added or altered in the intervening time.
Previously this behaviour was only available to group
and instance-level clusters, as some project clusters
relied on Kubernetes credentials being passed through
to the runner instead of having their resources managed
by GitLab (which is not available when using JIT). These
clusters have been migrated to unmanaged, so resources
can be created on demand for the remaining managed clusters.
We are deprecating this service in favor of instance wide clusters.
Therefore we removed some code that is not anymore needed for a
readonly cluster and also we added some flags to allow for this
deprecation. These flags are to be removed in the next release when
we finally completelly remove KubernetesService.