| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
These services aren't specific to GCP, and will be used for AWS
as part of https://gitlab.com/gitlab-org/gitlab-ce/issues/46686
|
|
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.
|
|
Refactor Deployment#cluster to #deployment_platform_cluster
See merge request gitlab-org/gitlab-ce!29961
|
|
We will introduce #cluster at a later stage.
Also deprecate this method
|
|
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
|
|
Instead of attempting to create or update a Kubernetes
namespace on every deploy, only do so when we know it
doesn't exist yet.
|
|
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.
|
