Upgrade dockerize script for github

[epag]

Currently the script we use to "dockerize" and create images based off our github is directly tied to there being a staging release created. This is obviously not ideal as it means in order to leverage this script to test changes in development we need to create a junk staging release and then delete it after we test.

Also as an aside we are leveraging wget to get the packages instead of leveraging the github api which is much quicker.

This task is complete when the following are achieved:

• Allow user to specify the commit they want to dockerize
• We need to persist the artifacts generated as part of the code check action now as well
• Swapping from using wget to using the github api

[HankHerr-NOAA]

There appears to be a disconnect between the version identified by the dockerizeGitHub.sh script and the tag associated with the pushed image.

With command line arguments, I forced these versions:

Core WRES binary zip version is 20240903-b1715d0-dev
WRES Worker shim binary zip version is 20240829-cae067a-dev
WRES Tasker binary zip version is 20240829-27f236d-dev
Primary docker image version is 20240903-b1715d0
Tasker docker image version is 20240903-b1715d0
Broker docker image version is 20240903-b1715d0-dev
Redis docker image version is 20240903-b1715d0-dev
WRES events broker docker image version is 20240903-b1715d0-dev
WRES vis binary zip version is 20240829-27f236d-dev
WRES graphics docker image version is 20240903-b1715d0
WRES writing docker image version is 20240829-27f236d-dev

However, when looking at the built images which were then pushed, the "-dev" does not show up for any of them:

Displaying most recent 20 docker images
REPOSITORY                                                       TAG                    IMAGE ID       CREATED         SIZE
wres/wres-writing                                                20240903-b1715d0       ca5d3749a55b   7 minutes ago   593MB
REGISTRY/wres/wres-writing                20240903-b1715d0       ca5d3749a55b   7 minutes ago   593MB
wres/wres-graphics                                               20240903-b1715d0       55bff039a5fa   7 minutes ago   561MB
REGISTRY/wres/wres-graphics               20240903-b1715d0       55bff039a5fa   7 minutes ago   561MB
wres/wres-tasker                                                 20240903-b1715d0       709f4fa33eff   7 minutes ago   546MB
REGISTRY/wres/wres-tasker                 20240903-b1715d0       709f4fa33eff   7 minutes ago   546MB
wres/wres-worker                                                 20240903-b1715d0       6e6e3338cf56   8 minutes ago   808MB
REGISTRY/wres/wres-worker                 20240903-b1715d0       6e6e3338cf56   8 minutes ago   808MB

That includes the persister, broker, and eventsbroker images, as well, though they are not shown above. I think a fix for this is likely a natural by product of the changes for this ticket.

Hank

[epag]

I am working through this today and I don't know if there is a great solution here. Some quirks with github:

• GitHub does not have any sort of constant address for downloaded artifacts from workflows. Instead you need to request a list of artifacts and a download link is dynamically assigned to it.
• You cannot pass in a workflow id into the api calls to get the download links specifically of that workflow

The two above basically means that we would need to pull down and page through all artifacts and parse the json responses to get the download link. Also to download commit artifacts we need to use the personal access token.

Creating a script for this use case seems a bit overkill as it would basically just be replacing downloading the artifact from the GUI and then SCP'ing them to where you want to use the normal dockerize script.

[epag]

Personally I think ticket gets closed out, especially as testing will be alot easier when we get the jenkins server deploying our staging code for us