Package: octomy-common
About  commonThis pypi package contains common  files  for  octomy  python  projectsCommon  isavailable  on  gitlab.Common  isavailable  in  PyPI.#  Clone  git  repositorygitclonegit@gitlab.com:octomy/common.git#  Install  package  into  your  current  Python  environmentpipinstalloctomy-commonVersioningIn this section the versioning scheme used for all octomy codebases will be explained.First of, we strive to followsemveras far as possible, so any details pertaining to the actual version numbers themselves is better explained in the semver spec. This documentation refers to how we store, change and update the version number in the project itself, and how that version number is propagated from source to build artifacts such as PyPi packages, Docker images and more.Source of version numberThe source of the version number shall be a one line, plain-text file in the root of the project simply calledVERSIONThis should contain the full version number on semver format and nothing else. Example versions are:0.0.10.1.31.0.02.2.12NOTE: There should not be any prefixes or postfixes in this version. No "rc", "beta" as this is handled by the logic as described below.git branchesWe will operate with 3 protected git branches. The rules that govern them are as follows:BranchDescriptionproductionThis corresponds to what is in production right now. Using CI/CD, anything merged to this branch will immediately be built and deployed in production, replacing whatever was in production beforebetaThis corresponds to what is in the beta environment right now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the beta environment, replacing whatever was in that environment before. Beta means an almost ready "next version" that is ready to preview for a selection of customers.stage-XXXThis corresponds to what is in the stage environment labelledXXXright now. Using CI/CD, anything merged to this branch will immediately be built and deployed into the  stage-XXXenvironment, replacing whatever was in that environment before. Please note that theXXXcould be any string, you may have several stage environments labelled as you see fit. Typically you will have a stage set up for a private presentation to a select client, or for internal testing.*Any other branch is considered unprotected and may be built and tested using CI/CD, but will not be considered for any automatic deployment. When built and deployed manually, these branches will havetest-prepended to them for easy identification.PyPi packagesPyPi package names are on the formproject_name-versionThe branch name is omitted entirely and it is expected that PyPi packages are deployed only for the production branch.Docker imagesDocker images are namedproject_nameand tagged withbranch_name-version. The branch name is omitted for "production" giving simplyversionin that case. Further, any branch name starting withstage-will have thestage-part removed. And finally, any branch that is not production, beta or stage-X will havetest-prepended to the branch name itself, so it becomesversion-test-branch_name.ExamplesExample project name:my_projectExample version:1.2.3Example stage name:my_presentationgit branch nameDocker imagePyPi packageproductionmy_project:1.2.3my_project-1.2.3betamy_project:1.2.3-betaN/Astage-my_presentationmy_project:1.2.3-my_presentationN/Asilly_branchmy_project:1.2.3-test-silly_branchN/AImplementationTo maintain this versioning, we depend on a few tools for the logic:bashmakesetup.py (Python)Each octomy project will have aMakefilein the root of the project that has targets for building and pushing pypi and/or Docker images. Itspecifies bash as the shellto use, and usebash string manipulation and conditionsto generate the correct version string following the rules above for Docker tags. Further, the rules are implemented as a function in setup.py to satisfy the rules when building pypi package.The Makefile targets are named as follows:make targetDescriptiondocker-buildBuild the docker image with correct version tagsdocker-pushPush the docker image with correct version tags to registrypypi-buildBuild the pypi package with correct versionpypi-pushPush the pypi package with correct version to PyPi repository. NOTE: Should only be called for production branchExample implementationThis octomy-common project will follow the rules above and will contain the Makefile targets that can be used as a reference for other projects.