aboutsummaryrefslogtreecommitdiff
path: root/linux-user
diff options
context:
space:
mode:
authorFabiano Rosas <farosas@suse.de>2024-01-18 13:49:50 -0300
committerPeter Xu <peterx@redhat.com>2024-01-29 11:02:12 +0800
commit94766edb35946e36cd6c9a070ae013cc09e411f0 (patch)
tree2f903771f01b059b3d76a0dc5449d4c6b0bfa97b /linux-user
parent434b8adcf34dd43f19a4ec851eab33c8722d4877 (diff)
downloadqemu-94766edb35946e36cd6c9a070ae013cc09e411f0.zip
qemu-94766edb35946e36cd6c9a070ae013cc09e411f0.tar.gz
qemu-94766edb35946e36cd6c9a070ae013cc09e411f0.tar.bz2
ci: Add a migration compatibility test job
The migration tests have support for being passed two QEMU binaries to test migration compatibility. Add a CI job that builds the lastest release of QEMU and another job that uses that version plus an already present build of the current version and run the migration tests with the two, both as source and destination. I.e.: old QEMU (n-1) -> current QEMU (development tree) current QEMU (development tree) -> old QEMU (n-1) The purpose of this CI job is to ensure the code we're about to merge will not cause a migration compatibility problem when migrating the next release (which will contain that code) to/from the previous release. The version of migration-test used will be the one matching the older QEMU. That way we can avoid special-casing new tests that wouldn't be compatible with the older QEMU. Note: for user forks, the version tags need to be pushed to gitlab otherwise it won't be able to checkout a different version. Signed-off-by: Fabiano Rosas <farosas@suse.de> Link: https://lore.kernel.org/r/20240118164951.30350-3-farosas@suse.de Signed-off-by: Peter Xu <peterx@redhat.com>
Diffstat (limited to 'linux-user')
0 files changed, 0 insertions, 0 deletions