icinga2
icinga2 copied to clipboard
Icinga
Override v2.13.0-555-g11e37a0bd from git describe with v2.13.6
CC @julianbrost
Before
[root@localhost ~]# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: r2.13.0-1)
After
RPM
[root@localhost ~]# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.0-556-ga1fd8e465)
.deb
No improved. What the heck is happening here?
Windows
PS C:\Users\aklimov> & 'C:\Program Files\ICINGA2\sbin\icinga2.exe' --version
icinga2.exe - The Icinga 2 network monitoring daemon (version: v2.13.0-556-ga1fd8e465)
Ah, here we go:
https://git.icinga.com/packages/icinga2/-/blob/9281beaddea263041f2fafe7944c26abc0236f41/debian/rules#L70
TODO
- [ ] https://git.icinga.com/packages/icinga2/-/merge_requests/4
It unlocks these changes to take effect:
root@c75443973575:/# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.0-556-ga1fd8e465)
We just had a discussion on this which I'll try to summarize here:
The package tooling was recently changed to generate versions like 2.13.6+573.g2ea866248-1675163600 for snapshot packages (note the .6 instead of .0 as it would be produced by git describe). The suggestion we came up with to make package versions and --version output somewhat consistent was to base the non-release versions on a hardcoded version string (should be 2.13.6 now and has to be updated in master as part of the release workflow) and augment it with the commit hash for telling the exact version. The number of commits in between is removed as it's mostly relevant for ordering different versions required by package managers, should not be a big deal if this misses in --version.
My suggestion would be to take this as an opportunity to entirely replace the current ICINGA2_VERSION file which seems to be a leftover from when the rpm spec file was still part of this repository and the version number was parsed from there. Instead, I would add a file like version.cmake that just sets a variable to the hardcoded version and another one to the commit placeholder.
Additionally, the CMake files have to be updated to also use that information instead of git describe when building directly from a git checkout.
As an additional feature, it would be nice if the commit date was included in icinga2 --version as this provides a simple way for the average user to judge how old a version is.
From a quick look at the code, this doesn't seem to do what we discussed earlier, i.e. it still uses git describe. If there's a reason for this, please explain it.
It includes commits count and commit hash in the version so it's formatted similar to the packages.
Windows
https://git.icinga.com/packaging/windows-icinga2/-/pipelines/28960
PS C:\Users\aklimov> & 'C:\Program Files\ICINGA2\sbin\icinga2.exe' --version
icinga2.exe - The Icinga 2 network monitoring daemon (version: v2.13.42-645-g3abc7a704)
Debian
root@3fde8a90b3c0:/i2# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.42-645-g3abc7a704)
CentOS 7
[root@3b254eab9e9f /]# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: [=[v2.13.0-645-g3abc7a704]=])
😅
Do you still think CMakeficating the ~version~ git archive version file is a good idea?
(version: [=[v2.13.0-645-g3abc7a704]=])
What's going on here? Is that [=[ syntax (which I haven't seen before by the way) only supported by newer versions of CMake or something like that?
Do you still think CMakeficating the ~version~ git archive version file is a good idea?
Would there be anything wrong with just using regular " for the string literal? Neither " nor ]=] should ever show up in a version number.
(version: v2.13.42-645-g3abc7a704)
Also, where does this 42 come from?
(version: [=[v2.13.0-645-g3abc7a704]=])What's going on here? Is that
[=[syntax (which I haven't seen before by the way) only supported by newer versions of CMake or something like that?
Seems so.
Do you still think CMakeficating the ~version~ git archive version file is a good idea?
Would there be anything wrong with just using regular
"for the string literal? Neither"nor]=]should ever show up in a version number.
But then we had $ inside " ". A variable expansion.
(version: v2.13.42-645-g3abc7a704)Also, where does this 42 come from?
My version file bump for PoC sake.
TIL: we're actually still using CMake < 3.0 anywhere (that is 2.8.12 on CentOS 7 (and therefore probably also RHEL 7 but I haven't checked explicitly)). Then doing it inside of CMake files would be pretty annoying, so extra files it is.
TODO
- [x] test https://git.icinga.com/packages/icinga2/-/pipelines/28993
- [x] test https://git.icinga.com/packaging/windows-icinga2/-/pipelines/28992
Debian
still has problems. But this PR does what it shall do.
Setting up icinga2-bin (2.13.0+643.ge85b82934-1+debian11) ...
enabling default icinga2 features
Enabling feature checker. Make sure to restart Icinga 2 for these changes to take effect.
Enabling feature notification. Make sure to restart Icinga 2 for these changes to take effect.
Enabling feature mainlog. Make sure to restart Icinga 2 for these changes to take effect.
Processing triggers for libc-bin (2.31-13+deb11u5) ...
Processing triggers for ca-certificates (20210119) ...
Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.
root@0e8a6aa0b46b:/# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.42-643-ge85b82934)
CentOS
same.
Installed:
icinga2.x86_64 0:2.13.0+643.ge85b82934-1.el7
Dependency Installed:
boost169-chrono.x86_64 0:1.69.0-2.el7 boost169-context.x86_64 0:1.69.0-2.el7
boost169-coroutine.x86_64 0:1.69.0-2.el7 boost169-date-time.x86_64 0:1.69.0-2.el7
boost169-filesystem.x86_64 0:1.69.0-2.el7 boost169-iostreams.x86_64 0:1.69.0-2.el7
boost169-program-options.x86_64 0:1.69.0-2.el7 boost169-regex.x86_64 0:1.69.0-2.el7
boost169-system.x86_64 0:1.69.0-2.el7 boost169-thread.x86_64 0:1.69.0-2.el7
icinga2-bin.x86_64 0:2.13.0+643.ge85b82934-1.el7 icinga2-common.x86_64 0:2.13.0+643.ge85b82934-1.el7
libedit.x86_64 0:3.0-12.20121213cvs.el7 libicu.x86_64 0:50.2-4.el7_7
Complete!
[root@c94b14ea13af /]# icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.42-643-ge85b82934)
openSUSE
Surprise, surprise...
(48/48) Installing: icinga2-ido-pgsql-2.13.0+643.ge85b82934-1.x86_64 ..........................................................[done]
Created symlink /etc/systemd/system/default.target.wants/ca-certificates.path -> /usr/lib/systemd/system/ca-certificates.path.
Created symlink /etc/systemd/system/getty.target.wants/[email protected] -> /usr/lib/systemd/system/[email protected].
Created symlink /etc/systemd/system/multi-user.target.wants/kbdsettings.service -> /usr/lib/systemd/system/kbdsettings.service.
Created symlink /etc/systemd/system/multi-user.target.wants/remote-fs.target -> /usr/lib/systemd/system/remote-fs.target.
Created symlink /etc/systemd/user/timers.target.wants/systemd-tmpfiles-clean.timer -> /usr/lib/systemd/user/systemd-tmpfiles-clean.timer.
Created symlink /etc/systemd/user/basic.target.wants/systemd-tmpfiles-setup.service -> /usr/lib/systemd/user/systemd-tmpfiles-setup.service.
Executing %posttrans scripts ..................................................................................................[done]
fc6ee6cc9f1b:/ # icinga2 --version
icinga2 - The Icinga 2 network monitoring daemon (version: v2.13.42-643-ge85b82934)
If we build all products' packages from one system, wouldn't it be smarter that the version is overridden only at one place – that one system? I.e. it assembles the version as needed and places it in a PRODUCT_VERSION file (literally) into the source. CMake reads it and compiles it in, Go go:embeds it and PHP... does its PHP things. This way we wouldn’t have to cherry-pick the version files.
If we build all products' packages from one system
Which we don't do, prime example: docker images. Also doesn't hurt to have proper version information in local development builds or in externally maintained packages.
- Oh, our images could do the same as packages.
- Forget local development builds. We know what we do.
- If you mean e.g. the BSD ports with external, well, IMAO it's their task to get things as they desire.
If we build all products' packages from one system, wouldn't it be smarter that the version is overridden only at one place – that one system? I.e. it assembles the version as needed and places it in a PRODUCT_VERSION file (literally) into the source. CMake reads it and compiles it in, Go go:embeds it and PHP... does its PHP things. This way we wouldn’t have to cherry-pick the version files.
I'd like too keep version files for the moment instead of changing everything.
Then what's your plan on getting the package version right? (See my three comments starting with https://github.com/Icinga/icinga2/pull/9649#issuecomment-1443390268 ) Lookup the latest tag in GitLab CI and merge like I did here?
@julianbrost Do you agree with me that we shall first get the package versions right in GitLab and then continue here with fixing icinga2 --version?
What would you change there? At the moment, it generates version numbers like 2.13.7+654.g41065e30c which looks fine.
