Add sanity check on version in CMakeLists.txt file

[azeey]

It the version in the local CMakeLists.txt file doesn't match the intended release version, released.py currently starts the source job, which gives the false impression that everything is working well. However, the source job will fail and debbuilder jobs are never triggered. This patch adds a sanity check so that released.py fails if the release version doesn't match what's in CMakeLists.txt.

To test the script can parse versions correctly, I ran the following from the directory containing release.py:

for d in ~/ws/ionic/src/{gz-*,sdf*}; do echo -n "$d "; python3 -c "import release; print(release.get_version_from_cmake(\"$d/CMakeLists.txt\"))"; done

[scpeters]

out of curiosity, did you consider sanity checking against the package.xml version with https://github.com/gazebosim/gz-cmake/blob/gz-cmake4/tools/print_package_xml_version.py ?

[azeey]

did you consider sanity checking against the package.xml version with https://github.com/gazebosim/gz-cmake/blob/gz-cmake4/tools/print_package_xml_version.py ?

The main reason is that package.xml files are only available in Harmonic and later, but we'll be using release.py for Fortress for a while.

[scpeters]

did you consider sanity checking against the package.xml version with https://github.com/gazebosim/gz-cmake/blob/gz-cmake4/tools/print_package_xml_version.py ?

The main reason is that package.xml files are only available in Harmonic and later, but we'll be using release.py for Fortress for a while.

That's reasonable while we are still supporting Fortress. One other difference between the versions from cmake and package.xml is that package.xml doesn't have prerelease version suffixes. After Fortress, would we be happier parsing from package.xml? Can parse from both now (with this PR and a separate one for package.xml) and consider removing the cmake version parsing later?

[scpeters]

this check doesn't currently work with prereleases. To test, I added a dummy commit gazebo-release/gz-math8-release@249841b in branch scpeters/test_prerelease, locally modified gz-math from the gz-math8 branch:

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 7cd29693..bf77c4b9 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -3,7 +3,7 @@ cmake_minimum_required(VERSION 3.22.1 FATAL_ERROR)
 #============================================================================
 # Initialize the project
 #============================================================================
-project(gz-math8 VERSION 8.1.0)
+project(gz-math8 VERSION 8.2.0)
 
 #============================================================================
 # Find gz-cmake
@@ -18,7 +18,7 @@ set(GZ_CMAKE_VER ${gz-cmake4_VERSION_MAJOR})
 set(CMAKE_CXX_STANDARD 17)
 set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
-gz_configure_project(VERSION_SUFFIX)
+gz_configure_project(VERSION_SUFFIX pre1)
 
 #============================================================================
 # Set project-specific options

and ran the following command:

$ ~/clone/release-tools/release.py --dry-run gz-math8 8.2.0~pre1 -b scpeters/test_prerelease
Downloading releasing info for gz-math8
Linux distributions in the -release repository:
 + noble  ('amd64', 'armhf', 'arm64')
 + jammy  ('amd64', 'armhf', 'arm64')
Safety checks:
 + OK No underscore in package name
 + OK Package names in changelog and control
 + OK Package versions in changelog
 + OK Package release versions in changelog
 + OK sdformat version in proper sdformat package

 !! Error in package version. CMakeLists version: 8.2.0, provided version: 8.2.0~pre1

[azeey]

I've updated the script to support prereleases.

After Fortress, would we be happier parsing from package.xml?

As you said, this wouldn't work for prereleases, so I'd imagine we'd keep using the CMake version.

[scpeters]

I've updated the script to support prereleases.

After Fortress, would we be happier parsing from package.xml?

As you said, this wouldn't work for prereleases, so I'd imagine we'd keep using the CMake version.

I suppose we could replace the version_regex by reading from package.xml, though we'd still need the suffix_regex. Just an idea

[azeey]

I suppose we could replace the version_regex by reading from package.xml, though we'd still need the suffix_regex. Just an idea

If we're going to have the CMakeLists logic for two years (until Fortress is EOL), I'm not sure why we would add the extra code to handle package.xml. If we want to do a sanity check on the package.xml, that'd be be one thing, but that's handled by our CI when making version bump PRs in preparation for the release.

I'd like a ✅ from @j-rivero before merging since release.py is also used on Jenkins and I don't want this to break anything there.

[j-rivero]

I'd like a ✅ from @j-rivero before merging since release.py is also used on Jenkins and I don't want this to break anything there.

The current calls in Jenkins are related:

• release.py in the nightly scheduler: since we are excluding nightly explicitly in the code there should not be changes.
• release.py calls wrapped via _releasepy. These are restricted to use the --source-tarball-uri parameter.

[j-rivero]

args.source_repo_uri is designed to provide exact repository URI instead of retrieving it from the local github checkout. Nothing to do with the CMakeListst.txt bussiness I think.

You probably want to use here args.source_tarball_uri that represents an existing source stored out of the system. In that case the check for a local CMakeLists.txt file has less sense unless we download and unzip the tarball.

[j-rivero]

Fixed this in c783ff8

[j-rivero]

Works for me using ign-gazebo6 6.17.0