Feature #5091
closedwe don't see the library versions of our osmo-*-master containers
100%
Description
while looking at the jenkins log file it is currently impossible to see which exact libosmo* was used for this test run.
If the given build job doesn't rebuld the osmo-pcu-master container, we will not see the log lines of package installation and hence not know what is installed.
I think it would be best to add some kind of step like "dpkg -l | grep osmo" (and a similar "rpm -qi" analogy) before starting the related container.
Adding a CMD/ENTRYPOINT for that doesn't really make a lot of sense to me. Maybe we can somehow generalize this int he jenkins.sh? First start the container once to obtain that information (and terminte), and then start a second time to actually run the IUT?
Another more controversial alternative would of course be to discover this at runtime from within the program (e.g. some "show" command, or printing it at start-up). That would have the advantage that it would also help our users (or us in debugging) in that they would have an easy, distribution/packaging independent way of reporting the exact version of all osmocom libraries and the application when sending bug reports. The problem is that there's no straight-forward way to do that latter part. We would either have to compile the version into the library, so it can be obtained as a global symbol, or we would have to do some extremly clumsy fork()+system() with a dpkg/rpm call, or one to "pkg-config --modversion libosmocore" etc.
If we'd go for any of those "runtime" approaches, then IIRC it would be best to include the version into the compiled library, similar to what we do in the actual application programs. The libraries could then in some constructor register themselves into a global linked list (maintained by libosmocore) containing library name + version number. That list could then be traversed by a "show" command.
Updated by osmith almost 3 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 90
I've implemented it in docker_images_require, which gets called by all ttcn3-*/jenkins.sh scripts.
https://gerrit.osmocom.org/c/docker-playground/+/23664
Example output:
### Installed Osmocom packages in: osmo-mgw-master ### ii libosmo-abis-dev:amd64 1.1.1 amd64 Development headers for A-bis interface ii libosmo-netif-dev:amd64 1.1.0 amd64 Development headers for Osmocom network interface ii libosmo-sccp-dev:amd64 1.4.0 amd64 Development files for libsccp, libmtp and libxua ii libosmoabis10:amd64 1.1.1 amd64 GSM A-bis handling ii libosmocodec0:amd64 1.5.1.23.9e37 amd64 Osmo codec library ii libosmocoding0:amd64 1.5.1.23.9e37 amd64 Osmo coding library ii libosmocore 1.5.1.23.9e37 amd64 Open Source MObile COMmunications CORE library (metapackage) ii libosmocore-dev:amd64 1.5.1.23.9e37 amd64 Development headers for Open Source MObile COMmunications CORE library ii libosmocore17:amd64 1.5.1.23.9e37 amd64 Osmo Core library ii libosmoctrl0:amd64 1.5.1.23.9e37 amd64 Osmo control library ii libosmogb12:amd64 1.5.1.23.9e37 amd64 Osmo GPRS GB library ii libosmogsm16:amd64 1.5.1.23.9e37 amd64 Osmo GSM utility library ii libosmonetif8:amd64 1.1.0 amd64 Common/shared code regarding network interface for OpenBSC ii libosmosim2:amd64 1.5.1.23.9e37 amd64 Osmo SIM library ii libosmotrau2:amd64 1.1.1 amd64 GSM trau handling ii libosmousb0:amd64 1.5.1.23.9e37 amd64 Osmo USB library ii libosmovty9:amd64 1.5.1.23.9e37 amd64 Osmo VTY library ii osmocom-nightly 1.0.0.202103110126 amd64 Dummy package, which conflicts with: osmocom-latest osmocom-next
### Installed Osmocom packages in: osmo-mgw-latest-centos8 ### osmocom-latest-1.0.0-2.2.x86_64 libosmogsm16-1.5.1-2.2.x86_64 libosmoabis10-1.1.1-2.2.x86_64 libosmonetif8-1.1.0-2.2.x86_64 libosmotrau2-1.1.1-2.2.x86_64 libosmocore17-1.5.1-2.2.x86_64 libosmovty9-1.5.1-2.2.x86_64 libosmoctrl0-1.5.1-2.2.x86_64 osmo-mgw-1.8.1-2.2.x86_64
Updated by osmith almost 3 years ago
- Status changed from In Progress to Resolved
- % Done changed from 90 to 100