chore(ci) cache httpbin docker image

[casimiro]

Also prevents dnsmasq from being started on installation.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.84180%. Comparing base (741b22a) to head (ed025a5).
Report is 2 commits behind head on main.

Additional details and impacted files

@@                 Coverage Diff                 @@
##                main        #620         +/-   ##
===================================================
- Coverage   90.85072%   90.84180%   -0.00892%     
===================================================
  Files             52          52                 
  Lines          11214       11214                 
===================================================
- Hits           10188       10187          -1     
- Misses          1026        1027          +1     

see 3 files with indirect coverage changes

Flag	Coverage Δ
unit	90.58023% <ø> (-0.01016%)	⬇️
valgrind	82.48898% <ø> (-0.01960%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

[thibaultcha]

Fantastic! Should we also cache and load the nginx image before the "Build httpbin-proxy image" step? This way we also avoid the FROM nginx step to pull it from the hub as well.

[casimiro]

Good idea! I'll include nginx image in the cache.

[casimiro]

On a second thought, docker/build-push-action is configured to cache its build environment which makes me conclude that it's already preventing nginx image from being pulled whenever the action setup-httpbin-server is ran.

Do you think it's worth caching nginx image regardless of that?

[thibaultcha]

Ah right! Is it possible to use the same docker/build-push-action to build the kennethreitz/httpbin and take care of the caching by itself then? It would simplify the caching process a lot.

[casimiro]

Yes, we could have an additional docker/build-push-action step and Dockerfile to build an image that simply encapsulates httpbin's. Although less verbose in the setup-httpbin-server action, this seems a too implicit approach for caching an image that's simply pulled.

Maybe the ideal approach would be moving the new caching steps from setup-httpbin-server to a separate action, e.g. cache-docker-image, and have setup-httpbin-server invoking it in a single step. That way setup-httpbin-server doesn't get too cluttered and cache-docker-image represents an explicit intent that we can reuse in our workflows (although there's no demand for reusing it now).

What do you think?

[thibaultcha]

Ok, let's do the separate action and encapsulate the httpbin image like we do the nginx one. Although let's name this separate action load-docker-image, because that seems to be the core usage of this new action: make an image available for use, and cache it as an implementation detail. Sounds good?

[casimiro]

Yes it does.

[thibaultcha]

Let's only use GHA-defined variables instead of ~; the list is: https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables.

[casimiro]

Good call!