Project

General

Profile

Actions

Feature #7917

closed

Take into account configuration to distinguish sub-jobs with the same modules and rule specifications

Added by Vitaly Mordan almost 8 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Urgent
Assignee:
Category:
Infrastructure of Core
Target version:
Start date:
01/26/2017
Due date:
% Done:

0%

Estimated time:
Published in build:

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.


Related issues 1 (1 open0 closed)

Blocks Klever - Feature #7911: Add test cases for linux:kernel:locking:* rule specifications when CONFIG_LOCKDEP is unsetNew01/25/2017

Actions
Actions #1

Updated by Vitaly Mordan almost 8 years ago

How is it possible that hash "bd63ce5" is the same?

Actions #2

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
Actions #3

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".

Actions #4

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.

Actions #5

Updated by Evgeny Novikov about 7 years ago

  • Status changed from Resolved to Closed

I merged branch tests to master in f96d83aa.

Actions

Also available in: Atom PDF