whitelist ordering of jobs is not preserved by clients
Bug #1213893 reported by
Zygmunt Krynicki
This bug affects 2 people
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Checkbox |
Fix Released
|
High
|
Brendan Donegan |
Bug Description
Whitelists contain patterns of job names in sequential order, eg 'job1', 'job2', 'job3.*' . When clients utilize that whitelist the order of executed jobs (forgetting about dependencies for a second) is not as it was in the whitelist. Instead the order depends on how jobs are returned by job enumeration APIs.
Clients should iterate whitelist entries and match that to jobs, not enumerate jobs and match that to a whitelist.
NOTE: it is yet unknown how this should work when clients are faced with multiple whitelists
This bug affects:
1) The dbus-mini-client
2) The checkbox-ihv-ng GUI
3) plainbox run command
Related branches
lp:~zyga/checkbox/whitelist-ordering
- Daniel Manrique (community): Approve
-
Diff: 172 lines (+133/-3)2 files modifiedplainbox/plainbox/impl/secure/qualifiers.py (+92/-3)
plainbox/plainbox/impl/secure/test_qualifiers.py (+41/-0)
lp:~brendan-donegan/checkbox/gui_whitelist_ordering
- Zygmunt Krynicki (community): Approve
-
Diff: 200 lines (+46/-70)2 files modifiedcheckbox-gui/gui-engine/gui-engine.cpp (+44/-68)
checkbox-gui/gui-engine/gui-engine.h (+2/-2)
lp:~brendan-donegan/cdts/whitelist_ordering
- Zygmunt Krynicki (community): Approve
- Daniel Manrique (community): Needs Fixing
-
Diff: 200 lines (+46/-70)2 files modifiedplainbox-gui/gui-engine/gui-engine.cpp (+44/-68)
plainbox-gui/gui-engine/gui-engine.h (+2/-2)
Changed in checkbox-ihv-ng: | |
status: | New → Triaged |
Changed in checkbox: | |
status: | New → Triaged |
Changed in checkbox-ihv-ng: | |
milestone: | none → version1.2 |
Changed in checkbox-ihv-ng: | |
importance: | Undecided → Medium |
tags: | added: plainbox |
Changed in checkbox: | |
assignee: | nobody → Zygmunt Krynicki (zkrynicki) |
importance: | Undecided → High |
status: | Triaged → In Progress |
Changed in checkbox-ihv-ng: | |
milestone: | version1.2 → version1.3 |
Changed in checkbox-ihv-ng: | |
milestone: | version1.3 → version1.4 |
milestone: | version1.4 → version1.3 |
Changed in checkbox-ihv-ng: | |
status: | Triaged → In Progress |
Changed in checkbox-ihv-ng: | |
milestone: | version1.3 → version1.5 |
Changed in checkbox: | |
milestone: | none → plainbox-0.5 |
Changed in checkbox-ihv-ng: | |
status: | In Progress → Triaged |
Changed in checkbox: | |
milestone: | plainbox-0.5 → plainbox-0.5a1 |
Changed in checkbox-ihv-ng: | |
milestone: | version1.5 → version1.6 |
Changed in checkbox-ihv-ng: | |
milestone: | version1.6 → version1.7 |
Changed in checkbox: | |
milestone: | plainbox-0.5a1 → plainbox-0.5 |
Changed in checkbox-ihv-ng: | |
milestone: | version1.7 → version1.8 |
Changed in checkbox-ihv-ng: | |
importance: | Medium → High |
Changed in checkbox: | |
assignee: | Zygmunt Krynicki (zkrynicki) → nobody |
assignee: | nobody → Brendan Donegan (brendan-donegan) |
Changed in checkbox: | |
status: | In Progress → Fix Released |
status: | Fix Released → Fix Committed |
Changed in checkbox-ihv-ng: | |
importance: | High → Critical |
Changed in checkbox: | |
status: | Fix Committed → Fix Released |
Changed in checkbox-ihv-ng: | |
status: | Fix Committed → Fix Released |
To post a comment you must log in.
For more than whitelist I don't have a strong opinion, but a possible solution would be:
1) Run whitelists in alphabetical order
2) For each whitelist, use the classic ordering
3) If a test has been already added by a previous whitelist, don't add it again when generating the list of tests.
Again, I am flexible about several whitelists, as it is a new use case