Skaffold: Feature request: allow skaffold build once and tag&push Image to multiple repos

Created on 24 May 2019  路  8Comments  路  Source: GoogleContainerTools/skaffold

I'd like to use Skaffold+Jib to build my container image and push it to both an in-house Nexus Docker Registry and also push to eu.gcr.io

Currently I'm having to rebuild the Image for each repository using skaffold profiles.
Could Jib build the image once and tag it with each repo name I need (same tag version) and then push it to each repo.

Benefit:
Build once, push to different repos. Then use skaffold profiles to do the deployment to the different environments.

arebuild areci-cd aretag fixit help wanted kinfeature-request prioritp2

Most helpful comment

The "build once & deploy multiple places" is an interesting use case for CI/CD.
We could implement it in a way that skaffold deploy / tagging / repushing is a separate phase.
If people are interested in this, please thumbs up.

All 8 comments

Unfortunately this isn't possible. Basically Skaffold+Jib ends up running something like

mvn prepare-package jib:build -Dimage=<skaffold-image>

Maven supports invoking plugin goals with different <execution> IDs, so I wondered if you could use the args field to add additional jib:build to that command-line (e.g., jib:build@id2). Unfortunately Jib treats command-line properties as over-riding those set in the pom, so the -Dimage=xxx will prevail.

Instead of Skaffold profiles, you could duplicate your artifact in your skaffold.yaml and just never reference the second artifact. For example:

build:
  artifacts:
  - image: gcr.io/project/image
    context: my-jib-project
    jibMaven: {}
  - image: local.nexus.host/project/image
    context: my-jib-project
    jibMaven: {}

Skaffold will warn:

WARN[0015] image [localhost:5000/foo] is not used by the deployment 

@briandealwis I tried with duplicate artifacts but only 1 image foo is passed to Maven:

$ VERSION=1.2.3 skaffold run -v debug 2>&1 | grep -i 'Running command'
"Running command: [mvn -Djib.console=plain --non-recursive prepare-package jib:build -Dimage=eu.gcr.io/project/foo:1.2.3]"
apiVersion: skaffold/v1beta10
kind: Config

build:
  tagPolicy:
    envTemplate:
      template: "{{.IMAGE_NAME}}:{{.VERSION}}"
  artifacts:
    - image: eu.gcr.io/project/foo
      context: ./app
      jibMaven: {}
    - image: local.nexus.host/bar
      context: ./app
      jibMaven: {}

Hmm it worked for me with skaffold dev

skaffold run from examples/jib works fine for me with the following change:

--- a/examples/jib/skaffold.yaml
+++ b/examples/jib/skaffold.yaml
@@ -4,6 +4,8 @@ build:
   artifacts:
   - image: gcr.io/k8s-skaffold/skaffold-jib
     jibMaven: {}
+  - image: localhost:5000/example
+    jibMaven: {}

 # optional profile to run the jib build on Google Cloud Build
 profiles:

Note that grepping for 'Running' as you're showing above will mask any build failures as I learned when trying to reproduce :-)

$ skaffold run -v debug 2>&1 | grep -i running.*mvn
time="2019-05-24T22:07:27-04:00" level=debug msg="Running command: [/Users/bsd/go/src/github.com/GoogleContainerTools/skaffold/examples/jib/mvnw -Djib.console=plain --non-recursive prepare-package jib:dockerBuild -Dimage=gcr.io/k8s-skaffold/skaffold-jib:v0.29.0-144-g90059f1e-dirty]"
time="2019-05-24T22:07:32-04:00" level=debug msg="Running command: [/Users/bsd/go/src/github.com/GoogleContainerTools/skaffold/examples/jib/mvnw -Djib.console=plain --non-recursive prepare-package jib:dockerBuild -Dimage=localhost:5000/example:v0.29.0-144-g90059f1e-dirty]"

And I see similar things when I build against a remote cluster with jib:build.

The "build once & deploy multiple places" is an interesting use case for CI/CD.
We could implement it in a way that skaffold deploy / tagging / repushing is a separate phase.
If people are interested in this, please thumbs up.

Adding an update because this has so many upvotes: I believe @nkubala tried to implement this a few weeks ago, but found it difficult to complete. I'll let him comment with the details.

I took a stab at addressing both this and #1269 in one go, which in retrospect was too much at once. for this issue the implementation would be a lot simpler if we just treated retagging/repushing as a separate phase, since builders like jib and kaniko build directly to the registry.

deploying to multiple clusters is a different beast entirely and i think out of scope for this issue.

Was this page helpful?
0 / 5 - 0 ratings