chore: migrate to docker org

[crazy-max]

Similar to docker/login-action#3

Make this action official and move it to docker org: docker/setup-docker-action.

cc @chris-crone @thaJeztah @neersighted

[thaJeztah]

SGTM

perhaps for a follow-up, we may want to add a bit more details to the README to explain why someone would use this (because Docker is also available by default), so perhaps we should include some scenarios where this action could help (and scenarios where users can "keep it simple" and use the default).

[neersighted]

There's several aspects of the existing code I'm not sure about; this is incomplete, but here's some that jump out:

• The release manifest is updated manually, and contains the GH release URL which is not very useful/relevant.
  • There are too many manual steps/points of failure here; this should either leverage existing infrastructure for discovery, or we should improve that infrastructure.
• The actual download URL is constructed on the fly from the version tag from the manifest, but also from a template.
  • What do you think about offering a manifest.json on download.docker.com/*/static to improve this?
• Inline PowerShell is pretty hard to maintain, and we should think about a better setup/OOBE for the Windows binaries.
  • What if we included the setup (PowerShell) script with the Windows static binaries?

[crazy-max]

The release manifest is updated manually, and contains the GH release URL which is not very useful/relevant.

This is automated by GHA (docker/actions-toolkit#166) but manually approved atm. We need this to avoid users being rate-limited by the GitHub API when checking releases anonymously so we just depend on raw.githubusercontent.com (see docker/buildx#1563).

But I agree that it would be better to rely on smth provided by download.docker.com.

What do you think about offering a manifest.json on download.docker.com/*/static to improve this?

Yes sounds good!

What if we included the setup (PowerShell) script with the Windows static binaries

Yes indeed that's pretty hacky atm in the toolkit for Windows. A contrib dir with scripts along the win binaries could work 👍.

[crazy-max]

perhaps for a follow-up, we may want to add a bit more details to the README to explain why someone would use this (because Docker is also available by default), so perhaps we should include some scenarios where this action could help (and scenarios where users can "keep it simple" and use the default).

Actions README are minimal and mostly technical. Use cases are on https://docs.docker.com/build/ci/github-actions/ but I agree we should have smth for this action there as well. This reminds me we should do smth for the metadata-action that has a pretty huge README.

[thaJeztah]

Yeah, it's mostly that I want to avoid users starting to use this action when they don't need to .. at all. So if we could have a short description "this is why you should use it (or not!)" would probably be a nice thing to have

(not a blocker, obviously)

[crazy-max]

Yeah, it's mostly that I want to avoid users starting to use this action when they don't need to .. at all. So if we could have a short description "this is why you should use it (or not!)" would probably be a nice thing to have

(not a blocker, obviously)

Added a note:

[thaJeztah]

I know the plan was to phase out the "CE" (and "Community Edition") term, so wondering if we should update these for "Docker Engine" (and "Docker CLI"), but honestly, don't know who's deciding on these things nowadays

[neersighted]

I'd find it much easier/preferred to keep the CE as people know what it is and it's proliferated everywhere. Community Edition and Desktop is not the worst thing ever, and we use Engine as a more Kleenex term.