Added default multi-platform builds for amd64 and arm64 docker images.

[kron-spar]

The way this branch currently works is that there are two default platforms it will build; both ARM64 and AMD64 images. The platforms argument may be omitted from the parent job that calls this composite action and it will still generate those images.

[aelkiss]

Let's see if we can get the github-script, checkout, & login actions updated so they don't give deprecation warnings.

[aelkiss]

For multi-platform builds let's see how well the caching works - if it's pretty quick to build both platforms assuming that only the repository (and not dependencies) have changed then I think it makes sense to enable by default

[aelkiss]

Would like to see the dependencies updated but otherwise looks good, and we can see about caching speedups for multiplatform builds.

[aelkiss]

I took a look at the runs from https://github.com/hathitrust/ht_indexer/actions and there are a few things I'd like to try:

• The run at https://github.com/hathitrust/ht_indexer/actions/runs/8053393423 still uses the deprecated node version; it looks like that's been addressed here, but I'd like to see an example of a run that uses this version to verify we don't get any deprecation warnings & that everything works as expected

• Likewise in https://github.com/hathitrust/ht_indexer/actions/runs/8053393423/job/21995701014 it ran so quickly not because it was taking advantage of the cache but because the output image tag already existed (https://github.com/hathitrust/ht_indexer/actions/runs/8053393423/job/21995701014#step:3:248). I'd like to see a run of the action that exercises the cache functionality.

Also looking at that same run, I would suggest a couple of other changes:

• do docker/login-action@v3 before checking if the image exists - I think if it's a private image then it will always say it does not exist if we do docker manifest inspect without logging in or otherwise might have issues
• add if: ${{ steps.image_check.outputs.image_exists != 'true' }} for setup-qemu-action and setup-buildx-action since we only need to do that if we're actually going to build an image.

[aelkiss]

Makes sense to me as we discussed, although we should hold off on merging this until:

1. we're happy with how this looks like when it gets called
2. we're certain (esp. with the changes in tagging) whether it's backwards-compatible or needs a new version

[aelkiss]

Moving the logic here looks good & with the test cases @Ronster2018 mentioned (might might be worth putting a link here) these should be ready to go.

[kron-spar]

Test Cases:

• Trigger build from Run Tests workflow ✅

  • Builds w/ or without Latest ✅ (Depends on workflow)
    • On push event tests.yml
    • Listening for success from build.yaml

• Trigger manual build

  • rebuild ✅ (Adds tags to the image but doesn't remove them. Is that needed?)
  • Build w/ latest tag✅
  • Build w/ unstable tag ✅
  • Build w/ latest or unstable tag & an additional tag like v1.0.0 ✅