skaffold: deploy profile without build artifacts failing with "no tag provided for image"

Expected behavior

Able to deploy 3rd party software with dedicated profile skaffold deploy -p stg-infra

Actual behavior

Skaffold asking to set image artifact from top level build section

# skaffold deploy -p stg-infra
You either need to:
run [skaffold deploy] with [--images TAG] for each pre-built artifact
or [skaffold run] instead, to let Skaffold build, tag and deploy artifacts.
FATA[0000] no tag provided for image [myreponame] 

Information

  • Skaffold version: version 1.2.0, 0.40
  • Operating system: ubuntu 18.04
  • Contents of skaffold.yaml:
apiVersion: skaffold/v1beta13
kind: Config
build:
  artifacts:
    - image: myreponame
      context: ../.
      docker:
        dockerfile: ./Dockerfile
        noCache: true
  tagPolicy:
    gitCommit:
      variant: CommitSha
  local:
    push: true
deploy:
profiles:
  - name: stg-infra
    deploy:
      helm:
        releases:
          - name: redis-stg
            chartPath: stable/redis
            version: 8.0.17
            remote: true
            namespace: infra-stg
            setValues:
              image.pullPolicy: IfNotPresent
            wait: true
        flags:
          install:
            - --atomic
          upgrade:
            - --atomic

Steps to reproduce the behavior

  1. skaffold.yaml
  2. skaffold deploy -p stg-infra

I can deploy stg-infra profile if top level build section is empty. I tried to set an empty build section in the stg-infra profile without success. Also have no issues with this configuration on v0.37.1.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 10
  • Comments: 16 (6 by maintainers)

Most upvoted comments

In my opinion using Skaffold in the CICD pipeline was a mistake (hindsight 20/20).

One has to dance around Skaffold’s config and missing cmd line paramater parsing capabilities waaay too much.

Using the docker build, docker tag commands get things done waaay quicker.

It seems (I could be wrong), that the run and dev seems to be the most used options, hence the other options don’t get so much TLC.

Also, in hindsight, switching from docker-compose might have been an error, considering docker-compose now has “context” support and capability to talk to k8s

Hi @f84anton, I can see how this is unintuitive.

We should fix that tag validation logic to only run for artifacts that are referenced by deployments in the current profile. It doesn’t make sense to validate for tags on artifacts when the deployments won’t use them at all.

In the meantime as a workaround, you should be able to run it with --images= myreponame:dummytag. Does that work for you as a workaround?

@nkubala

I’m gonna lower the priority for this one since there’s a workaround.

On the contrary, I would increase the priority, because we have to change our pipeline everywhere to specify the desired image. Without this bug, all pipelines will be universal skaffold deploy-p profilename. And because of the bug, we have to add -t myrepo/serviceA:fake for each service etc. This is very inconvenient, breaks the flexibility.

@tejal29 you sure about --output? isn’t it --file-output?

@Avi612 were you able to attempt the suggestion by @tejal29?

skaffold build --file-output output.json
skaffold deploy -a output.json

I believe this should help for your use case

@Avi612 please use

  1. skaffold build --file-output output.json
  2. skaffold deploy -a output.json

And let us know if that help you.