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

[f84anton]

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.

[balopat]

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?

[f84anton]

Thank you. I have tried to set images for stable/redis but not myreponame. I can now run deploy with --images=myreponame:nonexistingtag for profile stg-infra.

# skaffold deploy -p stg-infra --images=myreponame:dymmytag
Tags used in deployment:
 - myreponame -> myreponame:dymmytag
Starting deploy...

[shantanugadgil]

The above workaround doesn't work for me as I have default-repo set in the global config.
So the AWS ECR + imagename + tag is my complete "image name".

The cmdline I wish would work is like below:

skaffold deploy --namespace $NAMESPACE --profile my_app --images=xxxxx.dkr.ecr.myregion.amazonaws.com/my_app:working-master

The docker image xxxxx.dkr.ecr.myregion.amazonaws.com/my_app:working-master has been built and pushed to ECR in a separate "skaffold build" step, probably from a a different machine altogether.

Seems related to #3765

[nkubala]

@shantanugadgil spot on, you're running into the issue in #3765 and it is a real issue, but a different one than this.

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

[yolkov]

@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.

[AmetDevops]

I also started to migrate our old 0.30 skaffold to the 1.12.0, everything works fine except this with images addition. Thank you for prioritizing.

[shantanugadgil]

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

[tejal29]

Keeping the priority same as this added to our next milestone.