report and record the actual booted kernel with test results

[Andy Whitcroft]

As we often have 2 or more kernels installed when testing the package list is not sufficient to tell us which kernel we intended to run. Nor indeed does having the intended kernel installed tell us we actually running it after the reboot. It would be nice to:

1) report the kernel version uname -rv style as the first action following a reboot, allowing us to confirm the actual version booted each time.

2) perhaps report the kernel version and other information in the results.tar, say in a sysinfo.yaml.

If we chose a .yaml for this info we could expand it later to include filesystem info for example.

[Martin Pitt (pitti)]

As discussed on IRC, we want something like this for 2:

>>> print(json.dumps({'kernel_version': '1.2', 'test_kernel_versions': [('test2', 'reboot_to_backport', '1.3~utopic')]}, indent=2))
{
  "kernel_version": "1.2",
  "test_kernel_versions": [
    [
      "test2",
      "reboot_to_backport",
      "1.3~utopic"
    ]
  ]
}

kernel_version is the version right after the initial testbed setup/dist-upgrade/reboot. Any test which triggers a reboot which ends up in a kernel != kernel_version will get an entry in that test_kernel_versions list. Any test/reboot which is not there can be assumed to use kernel_version. IOW, for pretty much all expected cases test_kernel_versions should be completely absent.

We use json instead of yaml as the latter requires an external Python module.

[Martin Pitt (pitti)]

test_kernel_versions → kernel_version_changes

[Martin Pitt (pitti)]

Also add the test triggers into that json file.

[Martin Pitt (pitti)]

Kernel is logged with http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=b0dd5d5c59 (rolled out to all runners)

[Martin Pitt (pitti)]

This is implemented in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=f5e719a4 now.
This needs some additional changes in autopkgtest-cloud to put the new file into result.tar.

[Martin Pitt (pitti)]

With https://git.launchpad.net/~ubuntu-release/+git/autopkgtest-cloud/commit/?id=64b1862d1 this should now be live.

[Martin Pitt (pitti)]

Pulled for now, causes

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/i386/o/open-iscsi/20150911_152523@/log.gz

[Martin Pitt (pitti)]

Fixed harder in http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=1ecab4be6 and rolled out. Seems to be working alright so far, e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-wily/wily/i386/liba/libaws/20150914_092637%40/result.tar

[Martin Pitt (pitti)]

With http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=b5963450b the triggers are now exposed in testinfo.json. As autopkgtest itself doesn't have a concept of "test trigger" this isn't a separate key, but it will be an ADT_TEST_TRIGGERS=srcpkgname entry in the "custom_environment" entry of testinfo.json.

[Launchpad Janitor (janitor)]

This bug was fixed in the package autopkgtest - 3.17.1

---------------
autopkgtest (3.17.1) unstable; urgency=medium

  * Add new private python modules to Makefile, to actually ship them.
  * tests/adt-run: Fix test regression when $ADT_TEST* are not set.

 -- Martin Pitt <email address hidden> Tue, 15 Sep 2015 08:38:54 +0200