Project

General

Profile

Actions

Feature #8437

closed

Feature #8434: Get rid of job classes

Get rid of job classes

Added by Evgeny Novikov over 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
Urgent
Category:
Bridge
Target version:
Start date:
09/18/2017
Due date:
12/14/2017
% Done:

100%

Estimated time:
Published in build:

Description

A long ago I assumed that we will have a lot of job classes for various types of target programs, and for each such class Bridge should provide specific means for setting corresponding verification jobs and for visualization of their verification results. The former won't be most likely implemented ever. For the latter we suppose to use specific visualization for specific data reports, i.e. information how to treat data reports should be incorporated within them rather than to come from knowledge of job classes or component names.


Files

Screenshot.png (123 KB) Screenshot.png Evgeny Novikov, 06/01/2018 09:50 AM

Related issues 2 (0 open2 closed)

Related to Klever - Bug #8980: Jobs comparison is brokenClosedVladimir Gratinskiy06/20/2018

Actions
Blocks Klever - Feature #8648: Allow to download/upload job subtreesClosedVladimir Gratinskiy12/27/201701/17/2018

Actions
Actions #1

Updated by Vladimir Gratinskiy over 6 years ago

  • % Done changed from 0 to 100
  • Due date set to 12/14/2017
  • Status changed from New to Resolved

Implemented in branch "feature_8437".

Actions #2

Updated by Evgeny Novikov over 6 years ago

But how did you overcome former bindings of job classes with, say, comparison attributes and specific data report visualization? As far as I understand, you need some additional knowledge from Core to make things working as it was before.

Actions #3

Updated by Vladimir Gratinskiy over 6 years ago

Evgeny Novikov wrote:

But how did you overcome former bindings of job classes with, say, comparison attributes and specific data report visualization? As far as I understand, you need some additional knowledge from Core to make things working as it was before.

Comparison attributes are the same now for both classes and reports can be compared even if some attributes are not found. Data report visualization depends on data format. See comment in ReportData.html leading to function where format is checked.

Actions #4

Updated by Vladimir Gratinskiy about 6 years ago

  • Blocks Feature #8648: Allow to download/upload job subtrees added
Actions #5

Updated by Evgeny Novikov almost 6 years ago

  • Target version changed from 2.0 to 1.0

This issue was implemented together with issues for Klever 1.0.

Actions #6

Updated by Evgeny Novikov almost 6 years ago

Ilja noticed a bug (see the attached screenshot) that is most likely related with this feature implementation. But perhaps the issue is in Core which doesn't report some required data in advance.

Actions #7

Updated by Vladimir Gratinskiy almost 6 years ago

Evgeny Novikov wrote:

Ilja noticed a bug (see the attached screenshot) that is most likely related with this feature implementation. But perhaps the issue is in Core which doesn't report some required data in advance.

The problem is with data. For non-validation jobs "before fix" key is pointless as "after fix" doesn't exist. So the format should be like this:

{<key>: {'ideal verdict': <val>, 'verdict': <val>, 'comment': <val>}}

Comment here is not required. You can change this behavior in reports.utils.ReportData.__get_type().

Actions #8

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Open to Resolved

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Ilja noticed a bug (see the attached screenshot) that is most likely related with this feature implementation. But perhaps the issue is in Core which doesn't report some required data in advance.

The problem is with data. For non-validation jobs "before fix" key is pointless as "after fix" doesn't exist. So the format should be like this:

{<key>: {'ideal verdict': <val>, 'verdict': <val>, 'comment': <val>}}

Comment here is not required. You can change this behavior in reports.utils.ReportData.__get_type().

Actually, for validation for any row in the table there may be either "before fix" or "after fix" or they both, why not?.. During deciding a validation job table cells are fulfilled step by step. But even after finishing a validation job decision there still can be empty cells. I fixed the mentioned function appropriately in 8d59ad69 to branch new-report-data.

BTW, this all is a first step towards #8436. When it will be implemented we will have another way to visualize various verification results.

Actions #9

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Resolved to Open

An unexpected consequence is that I couldn't upload any verification job archive without specifying parent identifier. I hope that this can be trivially fixed.

Actions #10

Updated by Evgeny Novikov almost 6 years ago

Evgeny Novikov wrote:

An unexpected consequence is that I couldn't upload any verification job archive without specifying parent identifier. I hope that this can be trivially fixed.

Ditto for archives of verification job trees.

Actions #11

Updated by Vladimir Gratinskiy almost 6 years ago

Evgeny Novikov wrote:

Evgeny Novikov wrote:

An unexpected consequence is that I couldn't upload any verification job archive without specifying parent identifier. I hope that this can be trivially fixed.

Ditto for archives of verification job trees.

Fixed.

Actions #12

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Open to Resolved

Works perfectly for archives of both jobs and job trees. I could even move verification jobs to the root level when editing them.

Actions #13

Updated by Evgeny Novikov almost 6 years ago

  • Status changed from Resolved to Closed

I merged the branch to master in 4339da97 as a part of branch core-new-formats.

Actions #14

Updated by Evgeny Novikov almost 6 years ago

  • Related to Bug #8980: Jobs comparison is broken added
Actions

Also available in: Atom PDF