Containerise dependencies required to run tasks in dev workflow

[banjoh]

• Add tasks to manage container dev environment
• Update documentation to reflect new list of requirements
• CI job to build and publish ghcr.io/replicatedhq/platform-examples/wg-easy-tools:latest image. The image is also tagged with sha-<commit>.

[chris-sanders]

I started to call out everywhere that there is 'docker' and then realized you've labeled that as 'to follow' so I stopped since that's still wip.

[chris-sanders]

We really shouldn't be using ttl.sh here, it's fine for development but it needs to be available somewhere else for the actual workflow. Is this currently just for you to test and you intend to move it later?

[banjoh]

This is currently for test until we decide on

• if we need to host this image. We need to weigh the need to host the image vs users needing to build the image which take a minute.
• what OCI registry - docker hub? replicated? all of the above?

[chris-sanders]

Can we build the image and have it pushed to ghcr.io right here on this repo?
I'm fine with starting with a local build and following up with the auto-build on ghcr or if it's easy enough just build it anytime the Containerfile changes on merge to main.

I added a podman based image build/push on troubleshoot-mcp-server which might be very close to what you would need. https://github.com/chris-sanders/troubleshoot-mcp-server/blob/main/.github/workflows/publish-container.yaml

[chris-sanders]

Why is this all one big RUN line?
Doesn't this mean that you're forcing the cache to be invalidated if any of these things change rather than only updating the one change? Is there a benefit to it b/c I only see a downside of breaking normal caching behavior.

[banjoh]

Since we are not specifying any tool versions, would any of these tools change, leading to the layer being recreated? To update the tool versions, wouldn't it require docker build --no-cache anyway?

One, though negligible difference is the overall image size. Its smaller when using one layer. 1.23GB vs 1.18GB

[chris-sanders]

The image size I believe is driven exclusively off the fact that you include && rm -rf /var/lib/apt/lists/* in the same RUN command as the apt install and that I'm aware of and fine with.

What I don't think you need to be doing is mixing apt and curl installs. Using all of the apt installs in a single RUN and ending it with the cleanup is good practice. Grouping independent curl commands inside of an apt RUN command is what I would break up here.

[banjoh]

I've split the RUN directives to separate debian package installs and downloading tools

[chris-sanders]

A few more comments / questions / changes

[chris-sanders]

I'm not following why can't this all just be in the "start" task? Task can call and require each other what does having an internal task buy you here if the real start task is just calling the internal one anyway?

[banjoh]

I've DRY'd this bit some more

[scottrigby]

a few more suggestions