Re: [PATCH i-g-t v3 5/5] runner/resultgen: Insert attachments list into results.json

[Gustavo Sousa <gustavo.sousa@intel.com>]

Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> writes:

> On Wed, Apr 15, 2026 at 01:20:42PM -0300, Gustavo Sousa wrote:
>
> <cut>
>
>> >> 
>> >> >
>> >> > For attachments case imo allowing recursive creation from hooks scripts
>> >> > is an overkill.
>> >> 
>> >> The hook mechanism is not something created for exclusive use by CI. It
>> >> is a tool for developers to use are they see fit.  That was my original
>> >> intention when I first developed the hooks infrastructure.
>> >> 
>> >> I don't like the fact that we are making assumptions of how the hooks
>> >> will behave here.
>> >> 
>> >> If CI wants a flat structure, that's fine: let CI provide hooks that
>> >> generate files in a flat hierarchy.  I just think that it is not right
>> >> to assume that all hooks will behave like that.
>> >
>> > Executing hooks out of igt_runner won't provide results.json, right?
>> > So all that recursive removal / etc doesn't makes sense when you execute
>> > tests standalone.
>> 
>> My comment above is not about running igt_runner vs standalone tests;
>> it is about the users having their own custom hook scripts, which could
>> be used as part of an igt_runner call.
>> 
>> By the way, did we reach an agreement about whether we should or not be
>> adding the attachments to the results.json?  I remember Ryszard had his
>> doubts.  I might have missed some conversation about it.
>
> Yes. We got some offline discussion about this and Ryszard requirement
> was we should pack only attachment filenames to results.json. No content
> should land into this file because it is already big and adding content
> packed via base64 will only make it bigger.

Ah, this makes it simpler then: just an array of paths relative to the
result dir and no need to recreate the hirerarchy in the JSON.  That
would solve my requirement as well.

>
> If you don't mind I would like to provide minimalistic solution which
> will provide guc logs first. I suppose you have your own setup which
> likely uses hooks much, but at the moment I would like to solve problem
> with valid guc logs for failing tests. We may try to satisfy your
> workflow in a followup series, but I would like not to loose my primary
> goal from the radar.

Okay.

>
> --
> Zbigniew
>
>
>> 
>> --
>> Gustavo Sousa
>> 
>> >
>> > --
>> > Zbigniew
>> >
>> >
>> >> 
>> >> --
>> >> Gustavo Sousa
>> >> 
>> >> >
>> >> > --
>> >> > Zbigniew
>> >> >
>> >> >> 
>> >> >> --
>> >> >> Gustavo Sousa
>> >> >> 
>> >> >> > +	fchdir(dirfd(currdir));
>> >> >> > +
>> >> >> > +	return ret ? false : true;
>> >> >> > +}
>> >> >> > +
>> >> >> >  static const char *result_from_exitcode(int exitcode)
>> >> >> >  {
>> >> >> >  	switch (exitcode) {
>> >> >> > @@ -2244,6 +2304,9 @@ static bool parse_test_directory(int dirfd,
>> >> >> >  		fprintf(stderr, "Error parsing output files (dmesg.txt)\n");
>> >> >> >  	}
>> >> >> >  
>> >> >> > +	if (!fill_from_attachments(dirfd, results->tests))
>> >> >> > +		fprintf(stderr, "Error parsing attachments directory\n");
>> >> >> > +
>> >> >> >  	override_results(entry->binary, &subtests, results->tests);
>> >> >> >  	prune_subtests(settings, entry, &subtests, results->tests);
>> >> >> >  
>> >> >> > -- 
>> >> >> > 2.43.0