Building HammerDB for Docker from previous tagged versions will still build the latest release

[DGonzalezVillal]

Describe the bug
When trying to build old versions of hammerDB for Docker, the current Dockerfiles will still build the latest release.

To Reproduce

1. Clone the repository
2. Checkout the desired docker release (i.e. v4.11-docker)
3. Go into the Docker directory
4. Build the Docker image
5. Run docker image with bash
6. Check hammerDB version inside of the container. Latest version of hammerDB will be present and not the desired older version.

Expected behavior
Inside of the container we should see the checkout version of hammerDB

HammerDB Version (please complete the following information):

• Version: 4.12 and previous
• Build: Docker

HammerDB Interface (please complete the following information):

• UI: CLI

Operating System (please complete the following information):

• Server OS: Tested on RHEL 9.5

Additional context
I already brought up this issue in the Q&A:
#769 (reply in thread)

The current workaround is to modify the DockerFile to point to the desired hammerDB version on the docker repository.

[sm-shaw]

Issue is this line in the dockerfile pulls the latest base:
=> [internal] load metadata for docker.io/tpcorg/hammerdb:base

As a workaround, if you edit the Dockerfiles, so the main one has the first 2 lines as:

FROM  docker.io/tpcorg/hammerdb:v4.11 as oracle
FROM  docker.io/tpcorg/hammerdb:v4.11

and in the database specific directories it has this

FROM docker.io/tpcorg/hammerdb:v4.11 rather than hammerdb:base

it works but in the database specific builds it builds everything for hammerdb:v4.11 and therefore needs a solution to specify the v4.11 base instead.

@pooja-jain-17 and @grooverdan as you have updated the Dockerfiles before do you have any suggestions for how we can achieve this?

[grooverdan]

The Docker/base/Dockerfile has build argument of HAMMERDB_VERSION and the build version of it is define by this rather than the checked out github repo tag. If building locally, then this is an approach, or like @sm-shaw indicated that using an explicitly tagged FROM rather than hammerdb:base, or recreate hammerdb:base locally with a buildarg of HAMMERDB_VERSION=v4.something and then build for the desired DBs.

Previously there has been in https://hub.docker.com/r/tpcorg/hammerdb/tags tags like v4.10-mysql. To facilitate use cases like @DGonzalezVillal , I suggest continuing this naming convention.

With enforced with automation around releases this should be much more consistent. Github actions like https://github.com/redhat-actions/buildah-build triggered off tag pushes should facilitate this quite easily.

While hammerdb: base is a convenient building point for other containers is it useful as a distributed container? Pushing only derived containers will work and preserve the layering without giving the impression of a purposeful product.

Apart from automation in release and perhaps documenting the how to build a specific version locally, I'm not sure any other repo changes will make this resolvable.

If a build that corresponds to a the codebase is desired, a Dockerfile, like base, except with COPY {localdir} {containerdir} that achieves the same layout as RUN wget ... would facilitate local development, if that is the goal.

[sm-shaw]

Thank-you @grooverdan this should give us a good starting point to get this resolved for the next release.