← Back to team overview

checkbox-dev team mailing list archive

Re: Update on the certification status meta-data / CEP-8

 

On Thu, Feb 5, 2015 at 9:08 PM, Daniel Manrique
<daniel.manrique@xxxxxxxxxxxxx> wrote:
> On Thu, Feb 5, 2015 at 1:42 PM, Zygmunt Krynicki

> <zygmunt.krynicki@xxxxxxxxxxxxx> wrote:
>> Hey.
>>
>> To refresh our usage of the mailing list I'd like to share the status
>> of where we are with the meta-data story. The point of the story is to
>> know the certification status of each job so that we can put it into
>> reports.
>
> Awesome, thanks for working on this! Later down the line we need to
> think how to model this on our server-side tools/database.

I'll change checkbox-support to understand the new attribute and just
expose it. I already wrote code for hexer to use that but I haven't
tested or touched it in months really (it's the same code I wrote in
Taipei). I think the general idea is that we want to put this on the
test model (not the result model) and that's about it.

>> The specification on how that should look like from the outside has
>> been merged to trunk earlier today. You can read it here [1].
>> (side-story, we should build all CEPs into nice documents along with
>> the rest of our documentation). The parts you may find especially
>> interesting are all the examples that show how this looks like inside
>> test plans and job units.
>
> The examples are very clear and pretty cool. Will both syntaxes be
> supported? At first glance I like:

The "APPLY value TO attribute" syntax has been supported for a good
while now (for category overrides). The new additions are to make that
syntax available to other attributes and to have the new syntax for
compact representation (the other example).

>
> apply blocker to job-1
>
> since it's very natural-languagey, however, that screams "parser" and
> a) we know parsers are painful, and b) a problem with natural language
> is that people tend to not treat them very seriously, "ah, it's
> natural language so it'll understand anything I throw at it" and we'll
> start seeing "set job-1 to blocker" or other things. Strict validation
> will be crucial here to help developers grok the new syntaxes.

This is parsed pretty strictly with down to this line and that column
mistake details. I think it's okay. It's SQL-like and people generally
have adopted that style of syntax without problems.

> The compact syntax is more strict in that respect which may be better
> or worse. The bottom line is that there's no silver bullet when we
> introduce new syntax and trying to validate and hand-hold developers
> will be important.

Both are useful depending on what you want to do. I suspect we'll see
more of the inline kind for now but we'll see.

>>  - I've made some changes to the exporter base and to the xml and html
>> classes so that we have this data and can surface it. I've just pushed
>> that code here [3]. I haven't actually tried using it much so feedback
>> is appreciated. I haven't spent any time on making the actual HTML
>> report look nice. I'm sure it's possible but given how friendly
>> (*cough*) XSLT is it'd rather do something else. Oh, tests pass as the
>> canned xml/html reports now differ. I didn't bother updating them
>> until we have an acceptable looking report.
>
> How's progress on decoupling HTML from XML/XSLT? I guess this will
> lessen the pain of doing what you describe, and I thought we'd decided
> not to touch the XSLT and focus on the decoupling/templated native
> HTML report instead.

Sylvain was working on the actual reporter and from what I saw it was
interesting but it's on hold now. I was working on a cleanup /
re-factoring of how exporters are detected / accessed and that was
practically done in the common case *except* in the case where you
have missing dependencies on stuff like xml or that python-excel
library. That complicates things and effectively undoes what I've
changed. I'll push that branch if anyone wants to look at it.

Eventually I'd like to see exporters as units. The code they execute
needs to be provided centrally (jinja can handle everything except for
office formats so I suspect two "engines" will be available) but
actual template and any customizations can move to providers.

Thanks
ZK


References