8.9.1 docker image release contains 8.7.3 bins

[Fuma419]

Describe the bug The image released here may be mis labeled: https://hub.docker.com/layers/cardanocommunity/cardano-node/8.9.1/images/sha256-77899414b0f8935cd49359355a9aab43921255519c54e2dd76d1c8d1b2a47371?context=explore

in my testing this is a 8.7.3 release.

To Reproduce Steps to reproduce the behavior:

1. run 'docker pull cardanocommunity/cardano-node:8.9.1'
2. deploy containerized node on any network
3. docker exec -it cnode /bin/bash

4. cardano-node --version

   
   $ docker inspect --format='{{.Config.Image}}' cnode
   cardanocommunity/cardano-node:8.9.1
   $ docker exec -it m_relay_1a /bin/bash
   
   _____     _ __   __  ____                    __             
   / ___/_ __(_) /__/ / / __ \___  ___ _______ _/ /____  _______
   / (_ / // / / / _  / / /_/ / _ \/ -_) __/ _ `/ __/ _ \/ __(_-<
   \___/\_,_/_/_/\_,_/  \____/ .__/\__/_/  \_,_/\__/\___/_/ /___/
                        /_/ 

Availbles tools:

• cntools
• gLiveView
• cncli and cncli.sh

guild@98a58aeb246c:~$ cardano-node --version cardano-node 8.7.3 - linux-x86_64 - ghc-8.10 git rev a4a8119b59b1fbb9a69c79e1e6900e91292161e7

**Expected behavior**
see above

**Screenshots**
see above

**Version:**
 - OS: Ubuntu 22
 - Product version: [[e.g. CNTools 5.0.1]](https://hub.docker.com/layers/cardanocommunity/cardano-node/8.9.1/images/sha256-77899414b0f8935cd49359355a9aab43921255519c54e2dd76d1c8d1b2a47371?context=explore)
 - Cardano Node version: 8.7.3/8.9.1
 - Network you're connecting to: all

**Additional context**
Thank for all your tooling and efforts. 

[TrevorBenson]

@Fuma419

My suspicion is that a manual run against alpha branch was executed without the workflow dispatch having the input testing variable (boolean) set to True, leading to a container tag of 8.9.1 from alpha, but being built against master which is still using 8.7.3 for cardano-node-latest.txt. The intent is for only the master branch containers get pushed to docker hub, never alpha testing versions.

I suspect the workflow has an edge case where a container can still be bundling binaries from the master branch, but get tagged from the cardano-node-latest.txt of the branch that should be for testing only. I'll review the workflow and figure out where this edge case exists and submit a PR to resolve it so we no longer push containers tagged with a testing (alpha) node version.

[Fuma419]

Ah I see. Reviewing the alpha commit timestamped just prior to this dockerhub deployment may offer some clues.

[Fuma419]

can this hub.docker release be pulled back or deleted? Other users will be waisting time/efforts using it to update to 8.9.1.

[Fuma419]

Ah I see. Reviewing the alpha commit timestamped just prior to this dockerhub deployment may offer some clues.

wait, you said manual run. disregard

[TrevorBenson]

can this hub.docker release be pulled back or deleted? Other users will be waisting time/efforts using it to update to 8.9.1.

Right after my response I requested the contributors with login access to delete the tag for 8.9.1 and latest. I'll recreate latest after that pointing back to the image w/ 8.7.3 as the tag.

[TrevorBenson]

I believe I found the edge case. I suspect during initial testing that the files/docker/releases/cardano-node-version.txt file contained an identical version for both master and alpha branches which made it easy to overlook the checkout was still using the workflow branch, and not the GUILD_DEPLOY_BRANCH.

I haven't tested this, but looking at the Actions workflow summary am pretty confident I know the reproduction scenario. Given default branch is alpha this is how it could occur:

1. The workflow is manually executed using Run Workflow
2. The Use workflow from is left on the alpha branch
3. The Branch to deploy input is left as master (used as variable guild_deploy_branch)
4. The Testing workflow is unchecked/False (used as variable testing)
5. The checkout action pulls the repo from alpha
6. The CNVERSION variable assignment gets the value of cardano-node-version.txt from alpha.
7. The guild_deploy_branch == "master" and testing == False causing a push to docker hub of the image.

• In the case that alpha merges into master the CNVERSION value will be identical. This causes an automatic execution of the workflow and the container pushed to docker hub will always have the correct tag.
• When alpha updates the file and before any merge into master syncs them a manual workflow can be initiated where the CNVERSION does not match the bundled binary versions coming from the master branch.