Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tagging and versioning scheme #6

Open
ChristianHinge opened this issue May 29, 2023 · 1 comment
Open

Tagging and versioning scheme #6

ChristianHinge opened this issue May 29, 2023 · 1 comment

Comments

@ChristianHinge
Copy link
Collaborator

We should settle on a versioning scheme for the docker images and git commits. Things to consider:

  • In a production environment, there are three types of nodes/clients that have their own rh-node installation. Each of these must be able to communicate with one another. They are: the device using RHJob to submit a job, the manager in the cluster, and the particular ml tool packaged in rh-node. We should strive to rarely change the parts of rh-node code responsible for these dependencies. For instance, changing the URL endpoint for starting a job from "/job/start" to "/job/submit" would require one to update both the node, and the rh-node package on the client.
  • For each major version of rhnode, we could have a corresponding manager image; rhnode version 1.0.0 -> rhnode/manager:1.0.0
  • Each rhnode docker image contains two "versions" of interest - the rhnode version, and the version of the particular tool it encapsulates. HD-BET node tags could be: rhnode/hdbet:x1.x2.x3_y1.y2.y3, where x1.x2.x3 is the rhnode version and y1.y2.y3 is the tool version.
  • Docker image tags are not immutable like git commits. For instance, one could accidently push and overwrite an existing version of rhnode/hdbet:1.0.0 on dockerhub, simply by forgetting to update the tag in the compose file and doing docker compose push. Possible solution could be to have the "push" step run exclusively as a CI/CD tool on Github or similar.
  • An alternative solution could be to strictly write the git commit tags in Dockerfiles at each RUN git pull.... Then one could check this repository for older versions of the Dockerfiles in case of accidently overwriting a docker image.
@claesnl
Copy link
Contributor

claesnl commented Jun 15, 2023

We agreed on upgrades should increment the minor counter, or patch counter if needed between updates, with the name being major.minor.patch.
hdbet-v1.0.0 build with RHnode v1.1.1 must be named
rhbet-v1.0.0_rhnode1.1.1.

If build with alpha version of RHnode, e.g. v1.2.0-a.1, then the last hyphen must not be used, otherwise github actions currently breaks the name by that last hyphen rather than after the node name, so correct name would be
rhbet-v1.0.0_rhnode1.2.0a.1 rather than rhbet-v1.0.0_rhnode1.2.0-a.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants