we don't see the library versions of our osmo-*-master containers
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.
- 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.
### 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 18.104.22.168.9e37 amd64 Osmo codec library ii libosmocoding0:amd64 22.214.171.124.9e37 amd64 Osmo coding library ii libosmocore 126.96.36.199.9e37 amd64 Open Source MObile COMmunications CORE library (metapackage) ii libosmocore-dev:amd64 188.8.131.52.9e37 amd64 Development headers for Open Source MObile COMmunications CORE library ii libosmocore17:amd64 184.108.40.206.9e37 amd64 Osmo Core library ii libosmoctrl0:amd64 220.127.116.11.9e37 amd64 Osmo control library ii libosmogb12:amd64 18.104.22.168.9e37 amd64 Osmo GPRS GB library ii libosmogsm16:amd64 22.214.171.124.9e37 amd64 Osmo GSM utility library ii libosmonetif8:amd64 1.1.0 amd64 Common/shared code regarding network interface for OpenBSC ii libosmosim2:amd64 126.96.36.199.9e37 amd64 Osmo SIM library ii libosmotrau2:amd64 1.1.1 amd64 GSM trau handling ii libosmousb0:amd64 188.8.131.52.9e37 amd64 Osmo USB library ii libosmovty9:amd64 184.108.40.206.9e37 amd64 Osmo VTY library ii osmocom-nightly 220.127.116.11103110126 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