- 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.
There seems to be several examples where service_account_token is blank
even in GitLab.com newly created kubernetes_namespaces . We have not
figured out why they are blank but this should hopefully fix some issues
similar to https://gitlab.com/gitlab-org/gitlab-ce/issues/55362
When this option is enabled, GitLab will create namespaces and service
accounts as usual. When disabled, GitLab wont create any project
specific kubernetes resources
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/56557
JIT resource creation blocks deployments if a user is
self-managing their cluster, as it will fail the build
if unable to create a namespace and service account.
Using a custom namespace and service account was previously
supported for project level clusters, so we should preserve
this functionality.
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27352
This brings support for untrusted regexp for 'only:refs:' when
enabled via feature flag: alllow_unsafe_ruby_regexp.
This is by default disabled, and should not be used in production
In order to implement https://gitlab.com/gitlab-org/gitlab-ee/issues/10179
we need several modifications on the CI config file. We are
adding a new ports section in the default Image object.
Each of these ports will accept: number, protocol and name.
By default this new configuration will be only enabled in
the Web IDE config file.
Instead of creating a Kubernetes namespace on every
cluster related to a project, only create one on the
cluster the project is about to be deployed to.
Builds that have deployments require Kubernetes resources
to be created before the build can be deployed. These
resources are no longer created when the cluster is
created, which allows us to only create the resources
required by each specific build.
Introduces the concept of Prerequisites for a CI build.
If a build has unmet prerequisites it will go through the
:preparing state before being made available to a runner.
There are no actual prerequisites yet, so current
behaviour is unchanged.
GitLab Bot
drew
dineshpanda
Tiger
Thong Kuah
Stan Hu
Dylan Griffith
Mayra Cabrera
Kamil Trzciński
Francisco Javier López
GitLab Release Tools Bot