Feature #8416

Suggest better file archives passing from Core to Bridge

Added by Evgeny Novikov about 3 years ago. Updated almost 3 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
Published in build:


First thoughts on this topic were presented here. But even there the suggested method wasn't flexible enough. In particular it won't suit well for passing archives with coverage files in case of collecting total coverage for different correctness rules (#8353).

I suppose to use the following interface between Core and Bridge to flexibly pass file archives:
  1. File archive names shouldn't mean anything any more. This is because of it is hard to represent complicated data structures using just file names. That's why Bridge can receive a list of archives and it shouldn't infer anything from their names as it is done now.
  2. Support complicated structures for providing file archives (in each particular case there should be a straightforward format nevertheless). For instance, at some level of a report in JSON there can be something like this:
    "attr": {
      "subattr1": "subattr1/archive/name",
      "subattr2": ["subattr2/archive/name1", "subattr2/archive/name2", "subattr2/archive/name3"]
  3. In reports do not reference any concrete files from archives. Any way there are some contracts between Core and Bridge, say, how error traces and coverage are represented. So it will be better to always expect files with particular names if this is important at all (in ideal sanity checks at least of the top level should be performed). For instance:
    • archives with log files will always contain the only file log.txt,
    • archives with error traces will always contain file error trace.json and contain contain any number of referred source files perhaps placed into subdirectories,
    • archives with verifier input files can contain any files and Bridge likely shouldn't look into them at all,
    • and so on.

I suggest any notes and suggestions in comments to this issue. If there won't be any, Bridge and Core refactoring should be started ASAP, because of Klever 0.2 should support coverage better while this issue blocks some coverage related issues.


Feature #8417: Support more flexible file archives passingClosedVladimir Gratinskiy

Feature #8418: Support more flexible file archives passingClosedAlexey Polushkin


Related issues

Blocks Klever - Feature #8353: Calculate total code coverageClosed08/15/2017

Blocks Klever - Feature #8354: Visualize total code coverageClosed08/15/201710/09/2017

Blocks Klever - Feature #8441: Get input files of verifies by verification task identifiersClosed09/19/201709/21/2017




Updated by Evgeny Novikov about 3 years ago

  • Status changed from Feedback to Open

We already discussed the suggested interface with both Vladimir and Alexey.


Updated by Evgeny Novikov almost 3 years ago

  • Status changed from Open to Resolved

After I fixed numerous related issues as well as issues after recent huge Core improvements everything seems to work. Unfortunately, a lot of various bug fixes including these ones as well as features are too interconnected and they all are in branch multicoverage now.


Updated by Evgeny Novikov almost 3 years ago

  • Status changed from Resolved to Closed

I merged the branch that has this feature (multicoverage) to master in 37f0c082.

Also available in: Atom PDF