Hi Andreas, On 08-04-2020 22:17, Andreas Tille wrote: >>> for all source packages (in the same way as for deepnano) which seems to >>> be no straightforward way. I wonder whether you could drop some easily >>> parsable file containing >>> >>> source architecture pass version version_that_has_passed_before >> >> You're missing the suite here. So, we already have that info, you just >> need to loop over suite/arch. It's really in the json I already >> mentioned: packages.json. Please use that. > > OK, I'm using that. Its way more close to what I need. I simply > started with your first hint. :-) Ok. > Do you see any chance to also mention blacklisted packages in > packages.json? Antonio, what do you think? If we expose the blacklist, I can also have britney consume it. > The json file contains the following values: > > 'run_id', > 'created_at', > 'updated_at', > 'suite', > 'arch', > 'package', ## that field will be named 'source' in UDD! > 'version', > 'trigger', > 'status', > 'requestor', > 'pin_packages', > 'worker', > 'date', > 'duration_seconds', > 'last_pass_date', > 'last_pass_version', > 'message', > 'previous_status', > 'duration_human', > 'blame', > > I would consider to simply take over all these values as columns. > Is there any documentation for these fields? Yes, but not entirely in one place (at least I couldn't easily spot it): https://ci.debian.net/doc/Debci/ > Would you consider this a sensible approach for an UDD gatherer? Yes. > May be you consider some fields as really restricted to some > special applications and nobody would ever consider querying > UDD for it? Yes, I wouldn't add blame (I don't think we add those anymore, it's legacy, I only found two occurrences on amd64), created_at and updated_at. I also don't think that worker and message are very useful, but one never knows. duration_seconds and duration_human feel double and the former is leaner for in a database. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature