Issue

Previously, when we run main_hotfix CI build to create an image.
One of our users noticed that image still has previous version inside.

After quick investigation, I found the root cause:

We have hard-coded main branch inside the Dockerfile.

What I've done to fix this:

1. Added new argument BUILD_BRANCH with default main
2. Added this new argument both to ci-tag.yaml and ci.yaml
3. Used github.ref_name from Github actions default-environment-variables list which will give the short ref name of the branch or tag that triggered the workflow run and propagated as BUILD_BRANCH to the docker file.
   Details below:

flowchart TD
     id0(Triggered_build) --> id1(github.ref_name populated in Github action)  --> id2(BUILD_BRANCH provided as build-arg to the docker build) --> id3(default ARG is rewritten) --> id4(image build for the custom branch)

Test

I've tested locally the default and custom build argument propagation:
Default:

user@laptop:~/go/src/github.com/harmony-one/harmony/scripts/docker$ docker buildx build .
...
 => [builder 4/6] RUN git clone --branch main https://github.com/harmony-one/harmony.git harmony

user@laptop:~/go/src/github.com/harmony-one/harmony/scripts/docker$ docker buildx build --build-arg BUILD_BRANCH=dev 
...
 => [builder 4/6] RUN git clone --branch dev https://github.com/harmony-one/harmony.git harmony

End to end testing on my fork

Idea was to remove everything in CI around the changed github action and test the integration of ARG BUILD_BRANCH and github.ref_name - and value was passed though to the docker itself == test passed ✔️ :

https://github.com/mur-me/harmony/actions/runs/10092656255/job/27906739083#step:5:458

Unit Test Coverage

Test/Run Logs

Operational Checklist

1. Does this PR introduce backward-incompatible changes to the on-disk data structure and/or the over-the-wire protocol?. (If no, skip to question 8.)

   YES|NO

2. Describe the migration plan.. For each flag epoch, describe what changes take place at the flag epoch, the anticipated interactions between upgraded/non-upgraded nodes, and any special operational considerations for the migration.

3. Describe how the plan was tested.

4. How much minimum baking period after the last flag epoch should we allow on Pangaea before promotion onto mainnet?

5. What are the planned flag epoch numbers and their ETAs on Pangaea?

6. What are the planned flag epoch numbers and their ETAs on mainnet?

   Note that this must be enough to cover baking period on Pangaea.

7. What should node operators know about this planned change?

8. Does this PR introduce backward-incompatible changes NOT related to on-disk data structure and/or over-the-wire protocol? (If no, continue to question 11.)

   YES|NO

9. Does the existing node.sh continue to work with this change?

10. What should node operators know about this change?

11. Does this PR introduce significant changes to the operational requirements of the node software, such as >20% increase in CPU, memory, and/or disk usage?

TODO