An official docker image that contains the binary & nothing else is probably all that is needed & should be very straight forward to include in your existing release pipelines.

I'm sorry; it must be that I don't understand container-based CI workflows. How is fetching an official docker image that contains the gh binary during a CI job better than fetching our own official gh binary and executing it on the host system during the same CI run, without aid of containerized architecture?

Surely if a CI workflow can fetch docker containers and execute binaries within them, it can also fetch a tarball (which is already available) and execute a binary extracted from one?

I'm sorry; it must be that I don't understand container-based CI workflows. How is fetching an official docker image that contains the gh binary during a CI job better than fetching our own official gh binary and executing it on the host system during the same CI run, without aid of containerized architecture?

It's way more convenient:
Pod definition (I'm taking k8s as an example since it's quite common) (I didn't test, syntax might be a little off but that's enough for illustration purposes)

fetching an official docker image that contains the gh binary during a CI job:

containers:
- image: github/cli
  args: # command array

fetching our own official gh binary and executing it on the host system during the same CI run

initContainers:
- image: rancher/curl # or any other curl image
  args: "curl -L https://official-url-of-bynary.com -o /opt/bin/gh"
  volumeMounts:
  - name: gh-bin
    mountPath: /opt/bin
containers:
- image: base-image-with-git
  entrypoint: /opt/bin/gh
  args: # command array
  volumeMounts:
  - name: gh-bin
    mountPath: /opt/bin
 volumes:
    - name: gh-bin
      emptyDir: {}

If you want persistence of the gh binary to avoid re-downloading each time, that's still a bit more. If the binary is in an archive, you need the extra steps to decompress (you get all those things for free when using a container image)

Overall, everyone working with CI in containers with gh is gonna either make their own Dockerfile or trust someone's else, because doing this (my second yaml file) basically ignores all the ease of your CI infrastructure to redo it yourselves.

It's basically for tooling uniformity

The example above is also complicated by the fact that I don't see any easy way to make that download the latest version (possibly by semver), whereas it'd be great to be able to just point at github/gh:2 or github/gh:latest as my container in a CI step.

A lot of the complications listed in #3698 (reply in thread) are not issues in a containerized CI environment, where the pipeline runner takes care of mounting a home directory across steps and injecting environment variables and credentials.

I think it'd be awesome to have an official container image.

I also want to put in a vote for having an official gh Docker image. Like others, my use-case is for CI: in particular I want to make an automated commit and open a PR for human review. I could do this using GitHub's API and curl, but using gh would be easier.

An advantage to providing gh in an image instead of downloading it as part of the CI job is that the image can be cached. Downloading gh as part of the job means this download will happen every time the job runs, wasting time and resources.

To clarify, I don't think an official gh Docker image will replace the CLI, and I don't think anyone else here is saying that. Providing a Docker image will just better support a particular class of use-cases, and it should be up to the user to understand that some features---e.g. opening something in a browser---are not designed to work in a container.

I could see an official, minimalist container image being useful especially with Kubernetes 1.25 introducing ephemeral debugging containers. I'm curious what other GitHub engineers do for troubleshooting GitHub API within containers. 🤔

The big question is whether the image would be distroless or not as Alpine is currently unsupported / community driven.

No problem :-)

Happy I can help!