- 06 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 04 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 03 Dec, 2019 1 commit
-
-
GitLab Bot authored
-
- 19 Nov, 2019 1 commit
-
-
GitLab Bot authored
-
- 18 Nov, 2019 1 commit
-
-
GitLab Bot authored
-
- 16 Nov, 2019 1 commit
-
-
GitLab Bot authored
-
- 13 Nov, 2019 1 commit
-
-
GitLab Bot authored
-
- 08 Nov, 2019 2 commits
-
-
GitLab Bot authored
-
GitLab Bot authored
-
- 01 Nov, 2019 1 commit
-
-
GitLab Bot authored
-
- 30 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 26 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 24 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 22 Oct, 2019 1 commit
-
-
GitLab Bot authored
-
- 23 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 17 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 13 Sep, 2019 1 commit
-
-
GitLab Bot authored
-
- 04 Sep, 2019 1 commit
-
-
João Cunha authored
- We're also improving specs to avoid this could happen again
-
- 30 Aug, 2019 1 commit
-
-
Tiger authored
Feature flag has been defaulting to `true` since 12.2
-
- 29 Aug, 2019 1 commit
-
-
João Cunha authored
Extract duplicated code from two similar classes into a parent one.
-
- 28 Aug, 2019 1 commit
-
-
Tiger authored
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
-
- 07 Aug, 2019 1 commit
-
-
Tiger Watson authored
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.
-
- 29 Jul, 2019 1 commit
-
-
Tiger authored
Also removes all logic from ClusterConfigureWorker and ClusterProjectConfigureWorker, which are also no longer used.
-
- 16 Jul, 2019 1 commit
-
-
João Cunha authored
- Set as uninstallable app - Update docs - Adjust specs
-
- 11 Jul, 2019 2 commits
-
-
Hordur Freyr Yngvason authored
GitLab uses a kubernetes service account to perform deployments. For serverless deployments to work as expected with externally created clusters with their own knative installations (e.g. via Cloud Run), this account requires additional permissions in the serving.knative.dev API group.
-
Dylan Griffith authored
The current approach requires catching exceptions to handle these errors and callers are already handling model validations so it seems more appropriate. Also it seemed to convoluted to add this logic directly to the model since the model needs to check too many possible associations to determine whether or not there are more than one cluster since the model doesn't know what it's being created on. Additionally we only wanted to validate during create to avoid the risk of existing models becoming invalid by many different edge cases.
-
- 21 Jun, 2019 1 commit
-
-
Dylan Griffith authored
Since Kubernetes is creating the Secret and token asynchronously it is necessary that we implement some delay or retrying logic to avoid a race condition where we fetch a Secret before the token is even set. There does not appear to be any way for us to force it to be set with any synchronous API call so retrying seems to be the only option.
-
- 18 Jun, 2019 1 commit
-
-
Tiger authored
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.
-
- 05 Jun, 2019 1 commit
-
-
Amit Rathi authored
-
- 17 May, 2019 1 commit
-
-
Tiger authored
Immediate configuration is not ideal for group and instance level clusters as projects that may never be deployed would still have Kubernetes namespaces and service accounts created for them. As of https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/25586 we now create only the resources that are required for the project being deployed, at the time of deployment.
-
- 06 May, 2019 1 commit
-
-
James Fargher authored
Instance level clusters were already mostly supported, this change adds admin area controllers for cluster CRUD
-
- 03 May, 2019 1 commit
-
-
Mayra Cabrera authored
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
-
- 30 Apr, 2019 8 commits
-
-
Dylan Griffith authored
-
Dylan Griffith authored
-
Dylan Griffith authored
-
Dylan Griffith authored
These builder methods are using user provided input inside a public_send but this is safe to do in this instance because before they are called we check before calling them that they match an expected application name.
-
Dylan Griffith authored
-
Thong Kuah authored
Add endpoint to delete/uninstall a cluster application
-
Thong Kuah authored
Rescue and put into :uninstall_errored if something goes wrong while destroying, which can happen. I think it is safe to expose the full error message from the destroy error. Remove the :uninstalled state as no longer used.
-
Thong Kuah authored
+ to monitor progress of uninstallation pod
-