Skip to content

[Misc] Centralise version management using project.json

Niels Alexander Buegel requested to merge 944-where-and-how-do-we-specify-version-dependencies into main

Summary

  • Introduced a project.json file to keep track of package versions, build requirements, various variables that were otherwise scattered throughout the cmake files (catalogue versions), and provide sensible defaults for the dev environment. This allowed for the removal of several hardcoded values throughout numerous scripts.
  • Removed the versionlock.list file. This file is now generated on the fly where needed using the project.json
  • Removed the explicit BuildRequires from cta.spec.in. This part is now generated by cmake using the project.json
  • Replaced the cmake variables to keep track of the (supported) CTA catalogue versions in the CTA project (not the cta-catalogue-schema submodule) with the values in project.json
  • Updated the checks in check_catalogue_schema_version.sh to ensure consistency between the project.json and the rest of the project.
  • Added a schema.json for the project.json with a corresponding CI job to verify correctness.
  • Rely more on cta-release instead of copying the versionlock everywhere.
  • Various improvements and cleanup in the CI relating to the pipeline types and variable checks to allow for more flexible regression testing via the project.json
  • Updated the regression tests:
    • The regression tests are no longer tied to specifically EOS. It is now also possible to run a regression test against e.g. XRootD.
    • It is no longer mandatory specify all custom versions for a regression test; just specifying e.g. EOS or XRootD alone is sufficient.
    • The regression tests against a tag no longer update the runtime dependency of CTA; only the EOS version of the disk buffer will be updated. Reason being: we already test again main, and we would not be upgrading these runtime dependencies of an existing version anyway as we want to stick with the versionlock for that particular version in production.

Other minor things:

  • Fixed cmake setting of RPMTools_RPMBUILD_DIST
  • Removed the yum-* arguments from the Dockerfiles. In practice it is much easier and faster to e.g. create a new Dockerfile with what you need instead of struggling with this.
  • Renamed the renaming yum commands to dnf
  • Moved the jobs in the validation stage to analysis
  • Removed the release-cta-gitlab-* jobs as these were never used and incomplete functionality-wise
  • Renamed and reshuffled some variables around in .gitlab-ci.yml
  • Some formatting changes

Additional Required Actions

  • Requires manual tests in pre-production: NO
  • Requires a documentation update: YES

References

Closes #944 (closed) Closes #962 (closed)

Edited by Niels Alexander Buegel

Merge request reports