Skaffold: Unable to use 2 or more deploy tools in 1 skaffold file

[kvokka]

Following k8s docs want to create secrets with kustomize and use kubectl for other configs.

Expected behavior

No error

Actual behavior

$ skaffold diagnose
FATA[0000] creating runner: invalid skaffold config: only one element in set deploy can be set. got HelmDeploy and KubectlDeploy

Information

• Skaffold version: v0.38.0
• Operating system: Mac Os 10.14.6
• Contents of skaffold.yaml:

apiVersion: skaffold/v1beta14
kind: Config
build:
  tagPolicy:
    envTemplate:
      template: "{{.RELEASE}}-{{.IMAGE_NAME}}"
  artifacts:
    - image: core
      context: core
      docker:
        dockerfile: docker/development/Dockerfile
    - image: pubsub_emulator
      context: ../pubsub_emulator
      docker:
        dockerfile: ../pubsub_emulator/Dockerfile
deploy:
  kubectl:
    manifests:
      - support/rbac/endpoints.yaml
      - support/pubsub_emulator/k8s.yaml
  kustomize:
    path: support/env_vars
  helm:
    releases:
      - name: core
        chartPath: core/charts/poker-core
        valuesFiles:
          - core/charts/core/values.yaml
          - core/charts/core/values.development.yaml

[nkubala]

hey @kvokka thanks for the issue. can you elaborate a little more on your use case? do you have separate deployments that are being create through a combination of kubectl/kustomize/helm? is there a particular reason why you're not trying to deploy them all using one deployer?

[kvokka]

Thank you, @nkubala, for the response.

At the moment I have existed application, which is already on GKE in production. Different components was created at different timeframes, so each of them you different tools (including self written).
Current goal is to move the development process to local cluster for ease integration testing. And i want to minimize the harts/manifests/configs changing as much as possible.

Been fair, IDK all the reasons, why each choice was made, since the application is very old.

In progress of this task was found, that, for example some secrets and configs were created in the past manually on GKE and app Helm charts does not have the requirements (since the services like postgresql are already in place). It is possible to add it to Helm charts, of course. But this charts are production configs and it does not feels right to change them in the context of local development sandbox creation. Some secrets could be created with manifest, some with kustomize, some with CLI command with custom tool.

I understand, that using of 1 tool only is more correct. But it is another improvement and another task (context).

With Skaffold i have to choose:

• Move all setting to 1 configuration tool (like Helm or kubectl)
• Create separate configs for the development

Both options does not feels right.

[balopat]

I think this is reasonable. To bump the priority, it would be great to have a bit more clarity on whether this would help other users as well, or not. It is a medium to large size change in the code, although absolutely possible.

[tigerquoll]

It would certainly help me as well. I have some kustomize, and some plain kubernetes manifests.

[martinhoefling]

I would like to combine helm, e.g. some ready made charts off the shelf with some custom parts (ingress resources or PVC). So far, I create dummy helm charts for those parts.

[kvokka]

@balopat any news? Unfortunately, this is still a blocker for me

[corneliusweig]

I would like to combine helm, e.g. some ready made charts off the shelf with some custom parts (ingress resources or PVC).

@martinhoefling Why exactly do you want to deploy off-the-shelf helm charts with Skaffold? The same could be achieved by deploying those resources separately, which should be a one-time thing.

[martinhoefling]

@corneliusweig, I have some helm charts that I modify and develop, some are really off-the-shelf. So maybe I was not precise enough, as I have three classes:

• off-the-shelf charts (unmodiefied)
• modified or custom developed charts
• resouces that I just pack into a chart so that they can be deployed via skaffold
  Does it make the use case more clear?