Using Jfrog to create and update a build with docker images corresponding to the environment. (dev|staging|prod)

66 views Asked by At

I am using Gitlab for CI/CD and using Artifactory as animage repository. I am trying to get a better understanding of how to correctly use the Jfrog CLI and Artifactory (AF) to create a build and update it through the project's environment promotion.

These are the current steps I'm taking for pushing the images to AF. For example I am using "myproj" for the build name and "1234" for the build number.

dev:

  • docker build :dev-1234
  • jfrog rt docker push
  • jfrog rt bce
  • jfrog rt bag
  • jfrog rt bp

staging:

  • jfrog docker pull
  • docker tag :staging-1234
  • jfrog rt docker push
  • jfrog rt bp
  • jfrog rt build-promote --status=staging

prod:

  • jfrog docker pull
  • docker tag :prod-1234
  • jfrog rt docker push
  • docker tag :latest
  • jfrog rt docker push
  • jfrog rt bp
  • jfrog rt build-promote --status=prod

At the end I have 3 builds within AF and each build contains :latest :prod-1234 :staging-1234

What I'd like to do is have 1 build that contains all 4 images. If I remove the build-publish command I can retain a single AF build that has updated status through each stage. However, at the end of the pipeline it is showing a status=prod while only referencing the :dev image. All 4 images are being created and stored in the expected repo so I know they're at least making it into AF.

Am I misunderstanding what the intent is behind AF builds? Or is this user error?

1

There are 1 answers

4
DHummel On BEST ANSWER

If I understand your question correctly, you want to have 1 build that references all your (4) docker images, but instead you have 3 builds that references 3 separate docker images. It is a bit difficult to understand your point without code formatting text.

JFrog CLI works in the way that, as soon as you specify --build-name and --build-number arguments to any command, it will start to collect build information.

This build information exists as a JSON file in a temporary directory while you are collecting build info.

Any subsequent commands that specify the --build-name and --build-number arguments will append to the existing, temporary, build info.

The temporary build info JSON file will be deleted, when:

  • You manually delete it
  • Upload the build info with the jf rt bp command.

So you can do three things:

  • Either you collect all build information for all your containers before uploading it. This obviously have to be done on the same physical machine, due to how JFrog CLI works. This will not work on a pipeline where you build your containers on different build agents.
  • Or you can use the jf rt build-append command. This command will create a "master" build that references all appended builds.
  • Skip "build promotion" entirely, and use Release Bundles V2

Build promotion has many oversights and issues. (for example you can't promote aggregated build info). Release Bundles V2 seems to solve many of the shortcomings of Build Promotion.

I hope this helps you out.