Right now, not all of the images are built with a non-root user. More testing/validation will have to be done to determine which images can run as non-root.

Images that have to run as root should have capabilities limited to the needed subset.

More to come.

This seems to be a more common issue now so bringing it up for input/discussion.

Go container builds seem to fail frequently due to net/http: TLS handshake timeout issues on ppc64le, s390x etc. platforms. The failure seems to be arbitrary as I am usually able to reach the timed out file via curl/browser without issue. The frustrating part is this only seems to happen on the less commonly used platforms.

Here is one of the failed runs: https://github.com/jauderho/dockerfiles/runs/3932654484?check_suite_focus=true#step:8:1456

Part of the original impetus of building images was the fact that most official builds appeared to lack builds other than amd64 & arm64. So I can either stop attempting ppc64le builds until the goproxy infrastructure improves or risk having to babysit failing builds until they sort themselves out.

See also moby/buildkit#2402

Since v0.2.1, gocannon container image exits just after startup with the following output:

standard_init_linux.go:211: exec user process caused "no such file or directory"

I've played around with a similar two-stage Dockerfile to the one that is in your repo and it seems that -buildmode=pie is the culprit. Below is a Dockerfile, with which I've managed to successfully build gocannon's image without the described issue:

FROM golang:1.15 AS builder
WORKDIR /go/src/github.com/kffl/gocannon/
COPY ./ ./
RUN go get ./
RUN CGO_ENABLED=0 GOARCH=amd64 GOOS=linux go build -v -ldflags="-s -w" -o gocannon .

FROM scratch

# SSL CA should be addressed here
WORKDIR /root/
COPY --from=builder /go/src/github.com/kffl/gocannon/gocannon .
ENTRYPOINT ["/root/gocannon"]
CMD ["--help"]

The timing of the commit, in which -buildmode=pie was added also checks out: f4298f1#diff-9e1d2765235f2c71a0b7315eff5f2d8ceb61386799c550662ee8bb64fe3c0996

yt-dlp What should I do if I want to add - cookies?

Remove hard-coded variables,
without its not possible to fork, update, test and create a PR for an update.
like this:

Hi 👋🏼 looks like you are doing the same thing the k8s @home community is doing. I just wanted to share this repo to see if you would gain any benefits to the way we do CI for the images we host.

Repo:
https://github.com/k8s-at-home/container-images

Workflow to look for new versions:
https://github.com/k8s-at-home/container-images/blob/main/.github/workflows/schedule.yaml

Workflow to build and push images:
https://github.com/k8s-at-home/container-images/blob/main/.github/workflows/release.yaml

These workflows keep the workflows DRY :)

yt-dlp provides nightly builds via https://github.com/yt-dlp/yt-dlp-nightly-builds/releases
As their release cycle seems to slow down, it might be preferable to have a nightly image that contains the latest build. It seems that the builds on their side, do go through the normal build cycle, so the binaries/scripts are functioning. At least to the extent of their tests.

It appears that "lxml" python package is needed for visidata, it should be added here although I don't know the version numbers that are appropriate. Would you mind adding this dependency? TIA!

ccache is a compiler cache for C code. I was trying to figure out if it was possible (and useful) to use ccache across multiple GHA runs in an attempt to lower compile times for nginx etc. builds.

I was playing around with https://github.com/jauderho/dockerfiles/blob/55906f659f6f5b8e95106e8071451c5fa587a859/.github/workflows/nginx.yml but was not able to successfully come with a config that uses both actions/cache and cache-from: type=gha

If anyone wants to take a run at this, it would be much appreciated.

It is unwieldy to manually update the matrix in 3 different locations in the workflow. This should be built by reading from a file and building up the matrix.

References:

• https://stackoverflow.com/questions/65056670/is-it-possible-to-have-a-dynamic-strategy-matrix-in-a-workflow-in-github-actions
• https://code.dblock.org/2021/09/03/generating-task-matrix-by-looping-over-repo-files-with-github-actions.html
• https://stackoverflow.com/questions/10234327/convert-bash-ls-output-to-json-array
• https://stackoverflow.com/questions/59977364/github-actions-how-use-strategy-matrix-with-script
• https://www.cynkra.com/blog/2020-12-23-dynamic-gha/

Something along the lines of cat IMAGES | jq -R -s 'split("\n")[:-1]' which then produces:

[
  "FiloSottile/age",
  "nakabonne/ali",
  "ansible/ansible",
  "OWASP/amass",
  "jauderho/bl3auto",
  "psf/black",
  "jauderho/cf-warp",
  "cloudflare/cloudflared",
  "coredns/coredns",
  "StackExchange/dnscontrol",
  "DNSCrypt/dnscrypt-proxy",
  "cloudskiff/driftctl",
  "moncho/dry",
  "multiprocessio/dsq",
  "wader/fq",
  "osrg/gobgp",
  "kffl/gocannon",
  "buger/goreplay",
  "juanfont/headscale",
  "nojima/httpie-go",
  "projectdiscovery/httpx",
  "go-acme/lego",
  "fullhunt/log4j-scan",
  "0xInfection/logmepwn",
  "johnkerl/miller",
  "slackhq/nebula",
  "gravitl/netmaker",
  "binwiederhier/ntfy",
  "cube2222/octosql",
  "aramperes/onetun",
  "prettier/prettier",
  "cilium/pwru",
  "rclone/rclone",
  "authzed/spicedb",
  "jtesta/ssh-audit",
  "nabla-c0d3/sslyze",
  "projectdiscovery/subfinder",
  "tailscale/tailscale",
  "hashicorp/terraform",
  "drwetter/testssl.sh",
  "shopify/toxiproxy",
  "tsenart/vegeta",
  "saulpw/visidata",
  "yggdrasil-network/yggdrasil-go",
  "ytdl-org/youtube-dl",
  "yt-dlp/yt-dlp",
  "getzola/zola"
]

There were a couple of bugfixes to docker-autocompose by Red5d, which might want to be included

Have RPi4B, Raspbian 64bit and cannot build with Dockerfile:

[+] Building 15.8s (7/7) FINISHED
 => [internal] load build definition from Dockerfile                                                   0.0s
 => => transferring dockerfile: 1.29kB                                                                 0.0s
 => [internal] load .dockerignore                                                                      0.0s
 => => transferring context: 2B                                                                        0.0s
 => [internal] load metadata for docker.io/library/alpine:3.16.0@sha256:686d8c9dfa6f3ccfc8230bc3178d2  1.1s
 => [1/4] FROM docker.io/library/alpine:3.16.0@sha256:686d8c9dfa6f3ccfc8230bc3178d23f84eeaf7e457f36f2  0.0s
 => => resolve docker.io/library/alpine:3.16.0@sha256:686d8c9dfa6f3ccfc8230bc3178d23f84eeaf7e457f36f2  0.0s
 => => sha256:686d8c9dfa6f3ccfc8230bc3178d23f84eeaf7e457f36f271ab1acc53015037c 1.64kB / 1.64kB         0.0s
 => => sha256:c3c58223e2af75154c4a7852d6924b4cc51a00c821553bbd9b3319481131b2e0 528B / 528B             0.0s
 => => sha256:6e30ab57aeeef1ebca8ac5a6ea05b5dd39d54990be94e7be18bb969a02d10a3f 1.49kB / 1.49kB         0.0s
 => [2/4] RUN set -x  && apk update   && apk add --no-cache         ca-certificates         curl      13.6s
 => [3/4] WORKDIR /downloads                                                                           0.1s
 => ERROR [4/4] RUN dumb-init yt-dlp --version                                                         0.8s
------
 > [4/4] RUN dumb-init yt-dlp --version:
#0 0.723 [dumb-init] yt-dlp: Exec format error
------
failed to solve: executor failed running [/bin/sh -c dumb-init yt-dlp --version]: exit code: 2

Any workaround from there? :/

[+] Running 1/0
 ✔ Container zola-web-1  Created                                                                                                                                        0.0s
Attaching to zola-web-1
zola-web-1  | exec /usr/local/bin/zola: no such file or directory
zola-web-1 exited with code 1

How does yt-dlp call aria2 in another container? I use this image: https://github.com/P3TERX/Aria2-Pro-Docker

Hey,

I would like to embed thumbnails in my audio files. yt-dlp relies on mutagen for the thumbnail processing, which seems to be missing in the current build. Could you include it?

Error message when running yt-dlp with --embed-thumbnail option:

ERROR: Postprocessing: module mutagen was not found. Please install using `python -m pip install mutagen`

Best regards

The official build has a number of packages for debug purposes such as vim. Figure out which packages can be safely removed for normal usage.

Best practice is to refer to container image by the image digest.

Should we refer to images with the tag along with the image digest

FROM alpine:3.15.0@sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300

or

just by the digest?

FROM alpine@sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300

I'm open to pros vs. cons.

and build the REPO list out of the workflow files or a separate config file with all data about the program and the version,
so the workflow files can be unchanged and the separate config data
make it possible to fork, update, test and create a PR for an update.