search

sonatype / nexus-public

Sonatype Nexus Repository Open-source codebase mirror
https://www.sonatype.com/products/repository-oss-download
Eclipse Public License 1.0
1.96k stars 576 forks source link

Support Docker buildx plugin or Google crane #297

Open aentwist opened 11 months ago

aentwist commented 11 months ago

add a new docker tag to an existing remote image without pulling and pushing the image

this should be possible with docker buildx, crane, or regctl

docker buildx imagetools create myregistry.com/myimage --tag myregistry.com/myimage:1.2.3 crane tag myregistry.com/myimage 1.2.3

examples tag a latest image with the additional tag 1.2.3

https://stackoverflow.com/a/70526615/9890027

no, although pulling and pushing still works of course

docker pull myregistry.com/myimage
docker tag myregistry.com/myimage myregistry.com/myimage:1.2.3
docker push --all-tags myregistry.com/myimage

faster ci

haven't looked into what the problem is other than verifying this works with pulling/pushing and doesn't with either buildx or crane

Sonatype Nexus Repository Manager OSS 3.29.2-02

I am not a sysadmin

I scanned the release notes for the releases since my version and didn't see anything on buildx.

buildx gives ERROR: myregistry.com/myimage:latest: not found

crane is a bit more detailed, giving the whole 404 Not Found page -

Error: fetching "myregistry.com/myimage": GET https://myregistry.com/v2/: unexpected status code 404 Not Found:
<!DOCTYPE html>
<html lang="en">
<head>
  <title>404 - Nexus Repository Manager</title>
  <!-- ...rest of not found page... -->

Is this project based on https://github.com/distribution/distribution/ or compliant?

mrprescott commented 11 months ago

Thanks for filing this, your request is clear. Can you help me understand when you're using this? I assume your example was hypothetical, in that you already know you've minted version 1.2.3 at the point you've cut it—or are you building and then doing some kind of evaluation to decide if the image should qualify as the official 1.2.3?

aentwist commented 11 months ago

Hmmm I'm not sure I understand. Especially minting and cutting. This example is actually very real, I will elaborate.

add a new docker tag to an existing remote image without pulling and pushing the image

There is a dev and a prod environment. There is a main branch and there are feature branches. The main branch is continuously deployed to dev. To deploy to prod, a "release" is designated by adding a git tag to the latest commit on the main branch. A docker image for the latest commit has already been built with tag "latest" (and deployed to dev) by a previous pipeline, so we do not rebuild it, we reuse the existing one. However, this image will soon be overwritten with a new "latest". We do not save dev images for obvious resource reasons, so to preserve the image tagged "latest" at the time of prod deployment (because we do save prod images), we add another tag to it named using the git tag. Apparently this is classically done by pulling, tagging, and pushing the image, but there is no reason that should be necessary - this is a capability buildx, crane, regctl recognize and implement. Note that we do not have the image already because it was built in a previous pipeline. The savings here is the time to pull the image; pushing checks hash equality and then doesn't actually push anything except the tag.

I wonder how crane, etc actually work. Since they should work on various container registries, I assume they use the container API I linked which docker seems to have standardized. Which parts of the API are used needs investigation. If you have to pick, I would focus on buildx first since it is the official docker solution (even if other tools are better).

I'm not sure if it fits your goals but in the long run you might consider implementing the standard.

aentwist commented 11 months ago

Just realized that we should probably have the capability to deploy things other than "latest"..... but the general idea should be the same. Maybe it isnt worth the effort, and we should just rebuild the already-built-at-some-point container..

Edit: Although we could have this by retaining all dev images and trying to autoexpire them after 2 weeks, I'm just going to rebuild the image for prod, meaning there will be no tags-only push. Close this if you want.