ability to set default repo from profile

[saturnism]

currently, the default repo can be associated w/ a kubecontext and is stored in $HOME/.skaffold/config. It would be useful if the default repo is configured from skaffold profile.

[balopat]

cc @tejal29

[saturnism]

quick ping on this one. We are starting a new project, and the global default repo is not helping us to expand easily.

[zhuzeng]

Yes the global default repo is definitely causing us some debugging time and only find out it's not any mis-configurations in the project itself.

[tejal29]

Thanks @saturnism. This is on our team's radar. Bumping priority to p1.

[dgageot]

This is still on the roadmap!

[MarlonGamez]

Hi! It's been a while since we've updated on this. Recently we've been talking about what we want to do with default-repo, as its functionality is currently confusing for a lot of users. I believe we're trying to hammer out those issues before we prioritize this, but we're definitely still looking into this :)

[yhrn]

Any updates on this? Being able to control this via profiles would be very beneficial for us.

We have multi artifact cases where artifact A needs to go to repo 1 for profile dev/repo 2 for profile prod and artifact B needs to go to repo 3 for profile dev/repo 4 for profile prod. In these cases the command line arg won't work and I can't come up with a reasonably good workaround at all.

[tejal29]

Currently, we don't have plans to support this in v1, v2 skaffold config. However, the team is in midst of re-designing v3 skaffold and this is an interesting use case

[tejal29]

Refer https://github.com/GoogleContainerTools/skaffold/issues/5857 for v3 config tracking issue

[dhodun]

Interested in this as well. We recently removed the need for namespaces in our app which gave us a lot of flexibility to point skaffold at per-developer and per-PR namespaces. Would be cool to have the same flexibility at the project / cluster / gcr level.

[tejal29]

Thanks @dhodun We will definitely share stuff internally once we have v3 schema ready

[damlys]

Totally agree. It would be very useful:

build:
  artifacts:
    - image: myapp
      docker:
        dockerfile: build/myapp/Dockerfile
profiles:
  - name: dev
    deploy:
      defaultRepo: 127.0.0.1:5000             <---
      kubeContext: minikube
      kustomize:
        defaultNamespace: default
        paths:
          - deploy/myapp/overlays/dev

[theodiem]

Missing the mentioned funcionality and please include at least multi-level-repo also. Allows to:

build:
  artifacts:
    - image: myapp/frontend
      docker:
        dockerfile: build/myapp/Dockerfile.frontend
    - image: myapp/backend
      docker:
        dockerfile: build/myapp/Dockerfile.backend
profiles:
  - name: dev
    deploy:
      multi-level-repo: true                       <---
      defaultRepo: 127.0.0.1:5000             <---

I find very odd that there's global options that you can't configure in a config file and have the globals as an override instead (similar to env vars).

[GeertJohan]

If we can get to a good design / specs I'd be happy to work on an implementation. @tejal29 @briandealwis

Approach 1: Profile only

I suggest to introduce a field profiles[].defaultRepo.

Order of precedence would be:

• --default-repo flag
• SKAFFOLD_DEFAULT_REPO env var
• profile override (the new feature)
• ~/.skaffold/config

We need to decide on what should happen when two or more profiles set a defaultRepo value. I think the safest thing to do would be to disallow this (exit with an error). The user would then need to split up / redefine profiles so that only one profile ever sets the defaultRepo.

Approach 2: Build setting

Add a new setting build.defaultRepo, which a profile can override with profiles[].build.defaultRepo.

The order of precedence would be roughly the same as approach 1.

[GeertJohan]

Also: should we consider renaming it repo or repository instead of defaultRepo?

[jamesloosli]

chiming in because I could really use setting multiLevelRepo for all artifacts rather than pasting it everywhere.

[gsquared94]

In Skaffold v2.2.0, you can now set SKAFFOLD_DEFAULT_REPO=<repository> in a skaffold.env file in the project root. Does this work for your usecase @GeertJohan @jamesloosli ?

[jamesloosli]

I don't have an issue setting the default repo, I have an issue having to put multiLevelRepo in every artifact declaration everywhere in my monorepo.

[GeertJohan]

@gsquared94 Sorry for the late reply! I understand correctly that an actual env var SKAFFOLD_DEFAULT_REPO would override the one in the skaffold.env file? I guess that would work, yes! I'm just wondering why it was chosen to keep this setting as env var though, why not a skaffold.yaml settings with profile overrides, like so many other settings?

[jjorissen52]

We'd love to see the "default repository" feature reimagined to be implemented within profiles.

The thing is, the concept of a global "default repository" for all skaffold projects on one computer never really made sense. That's already acknowledged by 1) detecting docker-desktop and pushing to the correct registry in that case and 2) the ability to set default-repo at for each kube context in your ~/.skaffold/config file. But other developers working on this project on other machines don't have my ~/.skaffold/config file, so I need to carefully document or walk them through how to correctly set the repositories for each project and make sure they know to manually change the kubectx as well (and then hopefully we all remember to change the kubecontext instead of accidentally deploying the dev profile to the staging or prod cluster). Skaffold does a good job of taking complexity out of k8s deployments, but the repository situation requires developers to be much more comfortable with kubectl and related tooling than should really be necessary; simply having a skaffold.yaml as a result of cloning the respository should suffice.

I have many skaffold projects at this point, and none of them share the same repository. And within those projects, I have several profiles which each need to push to different repositories (sometimes targeting different k8s clusters as well), because we have a pattern where we like to have different kustomize overlays for dev/staging/prod which each push to different registries (and/or clusters as the situation demands). This helps us keep each of those environments in different stages of the release cycle, and by having a different registry for each, there can be no confusion about what version of the build is deployed where at any given time.

If you are deploying to Cloud Run (and I assume other targets in the future), you don't even have the option to specify a kubectx, your only option is to invoke skaffold run and set the default repository manually. That looks something like this:

SKAFFOLD_DEFAULT_REPO=really.long-difficult-to.us-central1.io/remember-name-dev skaffold run -p dev SKAFFOLD_DEFAULT_REPO=really.long-difficult-to.us-central1.io/remember-name-prod skaffold run -p prod

The problem with this is that I (and anyone else I pass this project off on to) needs to remember to set the environment variable or use the --default-repo flag appropriately. How can I enforce that they are choosing the right environment variable so they don't accidentally try to push dev images to the prod registry? Custom tooling, docs, shell scripts, etc, are error prone, time consuming (particularly when I need this to work for a mix of developers using UNIX and Windows!) and still require users to remember to do them.

Even just allowing me to manually specify the artifact as a patch would be a great improvement:

apiVersion: skaffold/v4beta6
kind: Config

build:
  artifacts:
    - image: app
      context: .
      
manifests:
  kustomize:
    paths:
      - .cloudrun/overlays/dev


profiles:
  - name: dev
  - name: staging
    patches:
      - op: replace
        path: /manifests/kustomize/paths/0
        value: .cloudrun/overlays/staging
        # allow me to manually specify the artifact!
      - op: replace
        path: /build/artifacts/0/image
        value: really.long-difficult-to.us-central1.io/remember-name/app

[jrj-d]

Hi everyone, thanks for the discussion on this topic! I'm chiming in to say that we would also greatly benefit from being able to specify a default repository per profile. Right now my team is doing like @jjorissen52 says:

SKAFFOLD_DEFAULT_REPO=really.long-difficult-to.us-central1.io/remember-name-prod skaffold run -p prod

Is there another, perhaps more elegant workaround to this limitation?