Making and deploying releases

The versioning of DIRAC, DIRACCommon, diracx, diracx-charts and all the extensions are very linked to one another.

Dependencies between diracx, DIRAC and DIRACCommon

Both DIRAC and diracx depend on DIRACCommon. However, DIRACCommon is in the same repository as DIRAC, and versioned together. This means that if we need to move code from DIRAC to DIRACCommon such that it is usable by diracx, we need first a new release of DIRAC and DIRACCommon just moving the code, before being able to use it in diracx.

The releases of DIRAC and DIRACCommon are managed as they have always been, and are described in the DIRAC documentation

Dependencies between diracx and diracx-charts

diracx-charts has a version number, as well as an appversion, which corresponds to the diracx version. This means that a new release of diracx requires a new diracx-charts release, which will update:

• the diracx-charts version
• the AppVersion
• the container versions

The update-charts CI job in diracx pushes a new commit in diracx-charts, which results in a new diracx-charts release.

Dependencies between diracx, diracx-web and diracx-charts

The diracx-web version is only very loosely coupled with the diracx version. A new diracx-web release will trigger a new diracx-charts updating:

• the chart version
• the container versions
• NOT the AppVersion

diracx release

Releases are managed by ReleasePlease. The token used to perform it belongs to diracbot github user

A new release creates:

• a github release
• a pypi release
• new docker images

Force version number

You can force a specific version number following the doc

git commit --allow-empty -m "chore: release 0.0.3" -m "Release-As: v0.0.3"
git push upstream HEAD:main

diracx-charts releases

Every commit in master triggers a new release. The releases are published on a helm repo