#398: depcheck is sometimes scheduled as noarch
---------------------+------------------------
Reporter: kparal | Owner:
Type: defect | Status: new
Priority: minor | Milestone: Hot issues
Component: tests | Keywords:
Blocked By: | Blocking:
---------------------+------------------------
Generally the koji-bodhi watcher schedules both i386 and x86_64
architectures of depcheck:
{{{
# autoqa post-bodhi-update-batch --targettag f16-updates --arch x86_64
--arch i386 openssl-1.0.0f-1.fc16 --dryrun
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*noarch -f /tmp/autoqa-control.le3exd post-bodhi-update-
batch:upgradepath.noarch
Keeping /tmp/autoqa-control.le3exd at user request
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*x86_64 -d fc16 -f /tmp/autoqa-control.FscGAS post-bodhi-update-
batch:depcheck.x86_64
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*i386 -d fc16 -f /tmp/autoqa-control._QiAVV post-bodhi-update-
batch:depcheck.i386
Keeping /tmp/autoqa-control._QiAVV at user request
}}}
But sometimes it might happen that the only new updated package is a
noarch package. Then the watcher "optimized" the arguments by leaving out
"--arch i386" and "--arch x86_64", therefore using the argument "--arch
noarch" that is implied by default:
{{{
# autoqa post-bodhi-update-batch --targettag f16-updates
rpmlint-1.0.0f-1.fc16 --dryrun
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*noarch -f /tmp/autoqa-control.mlUFRG post-bodhi-update-
batch:upgradepath.noarch
Keeping /tmp/autoqa-control.mlUFRG at user request
/usr/bin/atest job create --reboot_before=never --reboot_after=never -m
*noarch -d fc16 -f /tmp/autoqa-control.zpet6Z post-bodhi-update-
batch:depcheck.noarch
Keeping /tmp/autoqa-control.zpet6Z at user request
}}}
Unfortunately this doesn't work for depcheck. Depcheck is then scheduled
as noarch test, therefore run on arbitrary machine, and the test result is
also reported as "depcheck on noarch" into Bodhi.
We need to study this problem in detail and decide whether we should
change the watcher (schedule both architectures?) or implement new
features in the scheduling process (create a way for depcheck's
control.autoqa to insist on running both architectures every time?).
This is not super-critical because even though we provide some invalid
comments in Bodhi, we will probably schedule correct depcheck tests in the
following runs and test the package again. But it is unpleasant
nevertheless.
--
Ticket URL: <https://fedorahosted.org/autoqa/ticket/398>
AutoQA <http://autoqa.fedorahosted.org>
Automated QA project
_______________________________________________
autoqa-devel mailing list
[email protected]
https://fedorahosted.org/mailman/listinfo/autoqa-devel
