Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

improve documentation #6282

Open
2 of 14 tasks
yosifkit opened this issue Jul 12, 2019 · 17 comments
Open
2 of 14 tasks

improve documentation #6282

yosifkit opened this issue Jul 12, 2019 · 17 comments

Comments

@yosifkit
Copy link
Member

yosifkit commented Jul 12, 2019

Creating a catch-all issue so we can list areas for improvement.

"Since every change of every image is reviewed by humans, one of the criteria is that new images are "reasonably popular" to be able to get the most out of the available time we have."

@tianon
Copy link
Member

tianon commented Sep 6, 2019

SharedTags: explain what they are and when they are used

https://github.com/docker-library/faq#whats-the-difference-between-shared-and-simple-tags !! 😄

explicit time-since-last-update limit?

I'm not sure this is something we can add a generic limit for -- for example, cirros doesn't get many upstream updates, hello-world only updates for Windows, etc.

@james-crowley

This comment has been minimized.

@tianon

This comment has been minimized.

@james-crowley

This comment has been minimized.

@tianon

This comment has been minimized.

@james-crowley

This comment has been minimized.

@tianon

This comment has been minimized.

@james-crowley

This comment has been minimized.

@samuelkarp
Copy link

Per offline conversation with @tianon: Another good thing to clarify in the documentation would be inclusion criteria (i.e., "Is $project a good fit to be included in the library?").

@Arkemlar
Copy link

Arkemlar commented Jul 3, 2023

Please take a look on this one to include that doc improvement docker-library/docs#2349

@kcrane3576
Copy link

Since this appears to be a catch-all, I would like to add a request for more transparency and a specific link that outlines requirements for ALL Official Docker Images. I just opened a support ticket because I was running into an issue pulling two very specific images that were either outdated and/or the path to them had changed (consul:1.15.4 and openjdk:21-windowsservercore-ltsc2022).

For awareness, per my support ticket, since 1.16 consul has updated the api path to manifests to be: hashicorp/consul. Also, openjdk:21-windowsservercore-ltsc2022 has been deprecated (on me).

The real issue for us here is that when these changes to how to retrieve Official Docker Images is implemented, how are teams made aware?

It seems like we are missing a significant piece of the documentation and over the past few months we have run into multiple issues obtaining this data. For most Official Docker Images, you update the ‘image’ to be ‘library/{image}’ in the path. We would just like to have access to the logic or map that dictates how we are supposed to construct our api calls.

I would greatly appreciate any help/insight here. Also, not looking for manual steps. If we need to add some logic to check ahead of time somewhere, that is fine.

@tianon
Copy link
Member

tianon commented Nov 30, 2023

@kcrane3576 I'm having a really hard time trying to understand what it is you're asking for, but it sounds like maybe you're having trouble understanding how to know if official images are deprecated / unsupported? Unfortunately, the best we can do with Docker Hub (where we publish our images) is a note on the image description.

(Either way, this probably isn't on-topic for this issue, which is more about documentation about the official images program in general, and we don't have any APIs directly.)

@kcrane3576
Copy link

kcrane3576 commented Nov 30, 2023 via email

@kcrane3576
Copy link

kcrane3576 commented Nov 30, 2023 via email

@whalelines
Copy link
Contributor

whalelines commented Nov 30, 2023

Thanks for the clarification @kcrane3576 , hopefully I can do the same for you.

The hashicorp/consul repository is not a Docker Official Image (DOI). The consul DOI has not moved to become hashicorp/consul, it has been deprecated and is no longer maintained. We retain the existing tags of the consul DOI so as to minimize the chance of breaking its users' existing workflows. But as the consul DOI page on Docker Hub states, that repository is deprecated and if people want recent versions of Hashicorp Consul, they should use the hashicorp/consul repository instead, which is maintained by Hashicorp, not Docker.

So when curling for information for DOI, you will always add the library namespace. If it is not under library, it is not DOI.

@kcrane3576
Copy link

kcrane3576 commented Nov 30, 2023

@whalelines If I am understanding correct, essentially consul will no longer a DOI after 1.16

  • For awareness that doesn't explain why I couldn't pull the 1.15 from a path with /library/ (fixed since my original thread)

Assuming I am correct, my question should be updated.

Are there any DOI that don't follow the pattern of requiring /library/ in the path?

  • If so, I would like ALL of that information to be available for customers.

Again, my main goal here is to always be able to pull the docker-content-digest or Digest (for DOI).

@kcrane3576
Copy link

So when curling for information for DOI, you will always add the library namespace. If it is not under library, it is not DOI.

I appreciate the clarification above. This was exactly the information I needed.

  • Not sure it was all working exactly that way yesterday, but it is today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants