Feature #7917
closedTake into account configuration to distinguish sub-jobs with the same modules and rule specifications
0%
Description
During creation of a sub-jobs for tests I got the following exception:
Traceback (most recent call last): File "/home/ubuntu/klever/core/core/core.py", line 74, in main job.decide(self.conf, self.mqs, {'build': multiprocessing.Manager().Lock()}, self.uploading_reports_process) File "/home/ubuntu/klever/core/core/utils.py", line 56, in callbacks_caller ret = attr(*args, **kwargs) File "/home/ubuntu/klever/core/core/job.py", line 79, in decide self.get_sub_jobs() File "/home/ubuntu/klever/core/core/utils.py", line 56, in callbacks_caller ret = attr(*args, **kwargs) File "/home/ubuntu/klever/core/core/job.py", line 332, in get_sub_jobs raise ValueError('Several sub-jobs have the same identifier "{0}"'.format(sub_job_id)) ValueError: Several sub-jobs have the same identifier "/tests/linux/kernel/sched/completion/bd63ce5/linux:kernel:sched:completion"
This is because of sub-job identifiers for job class "Testing rule specifications" is concatenation of a path to tests and hash sums of modules and rule specifications.
The issue isn't important since it can be easily workarounded.
Updated by Vitaly Mordan almost 8 years ago
How is it possible that hash "bd63ce5" is the same?
Updated by Evgeny Novikov almost 8 years ago
- Tracker changed from Bug to Feature
- Subject changed from Sub-jobs are broken to Take into configuration to distinguish sub-jobs with the same modules and rule specifications
- Description updated (diff)
- Category set to Infrastructure of Core
- Priority changed from Urgent to Normal
Updated by Vitaly Mordan almost 8 years ago
This is because of sub-job identifiers for job class "Testing rule specifications" is concatenation of a path to tests and hash sums of modules and rule specifications
Why it is not just unique? Today we need to add config to that hash sum, tomorrow some other parameter will be required.
This is yet another example of "poorly established code".
Updated by Evgeny Novikov about 7 years ago
- Subject changed from Take into configuration to distinguish sub-jobs with the same modules and rule specifications to Take into account configuration to distinguish sub-jobs with the same modules and rule specifications
- Status changed from New to Resolved
- Assignee set to Ilja Zakharov
- Priority changed from Normal to Urgent
- Target version set to 1.0
Ilja distinguished subjobs by their ordinal numbers in branch tests. This solves the issue in general rather than this particular case. Unfortunately a new approach breaks results comparison after adding new sub-jobs somewhere in the middle but I hope that this will result to inconveniences not so often.
Updated by Evgeny Novikov almost 7 years ago
- Status changed from Resolved to Closed
I merged branch tests to master in f96d83aa.