### Summary When a job has `only: kubernetes: active` strategy, the job is only executed when the project has **an** enabled Kubernetes instance (`Platform::Kubernetes` or `KubernetesService`). Here is [the document](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-complex). --- > See the example below. Job is going to be created only when pipeline has been scheduled or runs for a master branch, and only if kubernetes service is active in the project. ``` job: only: refs: - master - schedules kubernetes: active ``` --- And recently, we implemented [multiple Kubernetes cluster per project](https://gitlab.com/gitlab-org/gitlab-ee/issues/3734). We can have **multiple** Kubernetes instances in a project. Each instance belongs to each environment. But today `kubernetes: active` just checks if the project has *any* clusters. This could make a slight edge case. For example, --- 1. A project has a cluster with `review/*` environment scope. gitlab-ci.yml ``` deploy to production: environment: name: production only: kubernetes: active ``` --- The job will be executed, because the project has a cluster, but the corresponding cluster doesn't exist, thus this job will fail or cause unexpected behavior. ### Solution Check `environment:name` when `kubernetes: active` strategy exists. e.g. 1. If `kubernetes: active` exists and `environment:name` exists, we check the activeness of the corresponding cluster. 1. If `kubernetes: active` exists and `environment:name` does not exist, we check if any clusters exist. ### Possible workaround For the workaround, users would need to create a cluster with a wildcard scope (*) for now. IIRC our `gitlab-org/gitlab` project does the same workaround for the same reason. ### Related - https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3603#note_50150076 - https://gitlab.com/gitlab-org/gitlab-ee/issues/3734 /cc @bikebilly @ayufan @grzesiek