Centralise Docker setup actions (qemu + buildx)

[JackPGreen]

The docker/setup-buildx-action@v3 with version: v0.5.1 is duplicated in 7 actions. The version used for the build system should be specified only once - extracted.

This action could have been externalised to docker-actions but seemed overengineered, instead access directly on master - but until merged, the builds will fail. Example execution when hardcoded to execute on this branch.

Note - this version is old which is what prompted centralising to make it easier to explore upgrading in future.

[nishaatr]

Good change but I think this should ideally go in docker-actions
I believe the end goal is to have all actions there and then have minimal business logic here
It will cause less confusion IMO

[JackPGreen]

Good change but I think this should ideally go in docker-actions I believe the end goal is to have all actions there and then have minimal business logic here It will cause less confusion IMO

I thought we thought we had to architect it like that to workaround GitHub issues, not that we wanted to - were a long way off having only Dockerfiles in this repo. I'd be open to @ldziedziul opinion though.

[nishaatr]

Good change but I think this should ideally go in docker-actions I believe the end goal is to have all actions there and then have minimal business logic here It will cause less confusion IMO

I thought we thought we had to architect it like that to workaround GitHub issues, not that we wanted to - were a long way off having only Dockerfiles in this repo. I'd be open to @ldziedziul opinion though.

Yes very true but @ldziedziul also made a compelling argument that having code in docker-actions also means we have physically one copy of actions as opposed to in hazelcast-docker where it gets copied over to all branches unnecessarily (and causing possible confusion). lets see what @ldziedziul says and then I will review

[ldziedziul]

I thought we thought we had to architect it like that to workaround GitHub issues, not that we wanted to - were a long way off having only Dockerfiles in this repo.

Our main goal is to avoid duplicating workflow logic. However, using bash scripts inside reusable workflows is problematic, as they're executed in the context of the current branch. That means we would need to explicitly check out additional scripts into a separate directory to make it work.

A better alternative is to wrap that logic in GitHub Actions. Actions are first-class citizens in GitHub workflows, and this brings several benefits:

• Reduced complexity in the workflow files themselves.

• Improved testability, since many scripts (and logic around it, I/O, validation etc) weren’t properly tested until they were used in a workflow.

• A separation of concerns between workflows (orchestration) and actions (implementation), which defines clean APIs and boundaries.

• (as @nishaatr pointed out), a single physical copy of each action, unlike in hazelcast-docker where the logic ends up duplicated across all branches which can lead to confusion and inconsistency.

• (ADDED): Most of these benefits one can achieve using actions in master branch, but then we bloat hazelcast-docker PRs with test workflows needed only when github actions are changed, which adds noise to otherwise unrelated changes.

• (ADDED): No need to re-tag released version when we fix logic in the workflows needed for automatic rebuilds

[ldziedziul]

We can extract it, it's a good direction, but we should consider moving this into docker-actions