Skip to content

This page describes how to mechanically make releases of DiracX and extensions. See the reference documentation for more details about how releases are made.

How to make a new DiracX release

Execute the following points in the presented order.

  1. Find the release-please pull request for your release. If you can't find it, it means that the currently existing latest release includes already all code changes.

  2. Review the release number and the content of the changelog

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

  3. Merge the release-please PR

  4. Check the deployment action

  5. When the above will be finished, check that the CI in diracx-charts is successful

At this stage, there is a new diracx and diracx-chart release.

How to make a new DiracX-Web release

Execute the following points in the presented order.

  1. Find the release-please pull request for your release. If you can't find it, it means that the currently existing latest release includes already all code changes.

  2. Review the release number and the content of the changelog

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

  3. Merge the release-please PR

  4. Check the deployment action

  5. When the above is finished, check that the CI in diracx-charts is successful

At this stage, there is a new diracx-web release and diracx-chart release.

Making the extension release

Making a release of an extension depends on how the extension has been set up. Below are recommended workflows:

  1. Ensure any desired merge requests have been merged.
  2. Ensure the pyproject.toml contains the desired DiracX dependency
    • If it does not, run the pipeline schedule to run renovate, which should trigger a merge request to update the version.
    • Merge the renovate-generated MR.
  3. Create tag (and optionally release) for your extension
  4. Updates to extension's "charts" repo will be pushed automatically or via merge requests depending on your setup.
  • The LHCb installation follows the "Generic GitLab" workflow.
  • The renovate job runs every Monday at 22:10 UTC. It can be manually triggered here.
  • The LHCb certification set up is updated automatically, see here for the pipelines.
  • The LHCb production setup is deployed automatically when the associated merge request is merged. See here for the pending updates.