A runnable dockerized container for github cli

[maniator]

I found myself utilizing github cli in my CI process and I felt it would be useful to share it -- as it was very useful to me and I hope can be useful to others!

Please let me know how I can improve it, and what else can be added for it to be better :-)

https://hub.docker.com/r/maniator/gh
https://github.com/serveside/gh

[maniator]

@mislav @samcoe

Anything I can add to the readme?

I know for sure a link back to this repo and the docs would probably be a good add.

[mislav]

@brad-jones Sure, that specific use-case would work from within a container as long as you set GH_TOKEN. But a lot of other modes of operation of gh will not be available or equivalent when running in containerized mode. There is no incentive for us to package a version of gh that has only a subset of features of the full GitHub CLI. Instead, we will continue publishing a full-featured build of GitHub CLI, and it's up to users (like you) to package a subset of CLI's features for their own needs.

[jglick]

that specific use-case

…is the stated original justification for this RFE:

I found myself utilizing github cli in my CI process

There is no need for an image for interactive use. What is needed is just an official, up-to-date image containing the gh binary, which you could run from a CI pipeline with GITHUB_TOKEN defined in order to script GitHub operations more easily that you can with curl or the like. People already do this—we just need to publish our own image, which is tedious to maintain, or pick up an image from some unknown party, which is obviously risky.

[mislav]

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?

[VannTen]

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

[tilgovi]

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.