question: Include jq in debug container?

[DarwinJS]

While I love minimal containers, ones that leave the package manager off make it difficult to work inside the container.

The GitLab example (thank you for that!) is an example where the job run inside the container - and with the package manager not present, it is challenging to add jq.

Since all the output of crane is json, would it be possible to install jq on the debug tag - or at least the os package manager so one can pull on their desired additional utils?

Thanks for any thoughts!

[imjasonh]

I'd be willing to consider it. jq is pretty small and generally pretty well trusted.

To do it, we'd have to build that base image to include jq, and I think if we were going to do that I'd probably want to use apko to do it declaratively, and build that every time the crane image is built and published.

[DarwinJS]

That would be fantastic - if apk was in there I could also pull git which is another frequent need - for git ops flows I have to commit updated manifests back.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Keep fresh with the 'lifecycle/frozen' label.

[developer-guy]

Kindly ping @imjasonh, it looks like a fantastic issue that can help to learn apko & melange projects to build an OCI image with the given packages, but can you give me a bit more context about what needs to be done? Where should we start?

[imjasonh]

Kindly ping @imjasonh, it looks like a fantastic issue that can help to learn apko & melange projects to build an OCI image with the given packages, but can you give me a bit more context about what needs to be done? Where should we start?

Sure thing. There's already a jq package for Wolfi (here), so it should be pretty easy to build a base image for it.

We can have the image release process build and push the base before building the crane container on top of it.

What else do we want in the debug base image? busybox, git, jq, anything else?

[developer-guy]

Sure thing. There's already a jq package for Wolfi (here), so it should be pretty easy to build a base image for it.

So, you mean that, instead of searching jq tool in the upstream alpine package repositories, we can look at the Wolfi OS repo to download it while using apko? Something like the following:

contents:
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
  repositories:
    - https://packages.wolfi.dev/os
  packages:
    - ca-certificates-bundle
    - build-base
    - busybox
    - git
    - jq
...

[imjasonh]

Yep, basically that! 👍

[developer-guy]

So here is the plan, wdyt?

• Create a melange.yaml file inside the crane repo.
• Add the packages above
• Add necessary GitHub Actions workflow to build the base package
  • • '@local /github/workspace/packages'
  • • crane-base@local
• Add apko.yaml file inside the crane repo
• Add crane-base@local package to the list
• Follow the example here to build the crane project
  • https://github.com/chainguard-dev/hello-melange-apko/tree/main/go

[imjasonh]

I don't think we even need to involve melange.

• add debug-base.yaml that includes the debug packages listed above
• during release, apko publish debug-base.yaml $REPO/debug-base
• update .ko/debug/.ko.yaml to specify defaultBaseImage: $REPO/debug-base
• still build and tag the debug image using ko, and KO_CONFIG_PATH=.ko/debug/.ko.yaml, like we do today.

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Keep fresh with the 'lifecycle/frozen' label.

[robross0606]

While I love containers being light weight, the fact that no package manager is available in these containers really hinders their further usage. I need both jq and curl in my GitLab pipeline job to do some tagging and then an API notification. I'd love to use the gcr.io/go-containerregistry/crane:debug image, but it is stripped of anything but busybox and dpkg which makes it nigh impossible to extend slightly and use. Instead I have to split them into multiple jobs which is actually slower than being able to extend this container and defeats the purpose of it being light weight.

[DarwinJS]

It seems likely that this would never be used in a microservices application - but that 99% of usage would be in CI? So maybe just give the entire thing a proper shell and package manager by basing it on the bash container?

Background for using a hefty container => I wrote this opinion post on why it is a Developer Productivity antipattern to make CI specific containers as hyper-minimalized as those that are used for "truly designed as microservices": When the pursuit of simplicity creates complexity in container-based CI pipelines

[github-actions[bot]]

This issue is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Keep fresh with the 'lifecycle/frozen' label.