Add column for "Untested files"

[yarikoptic]

ATM we are opening only .nwb files. I would like to know

• how many files were not tested for the tests
• the total size of those files
• what are those files - have an {dandiset}/untested.md with list of
  • reference to those files in the archive (URLs to API server I guess so it would produce correct content-disposition etc happen I decided to look at)
  • size of the file
  • output of file and file --mime-type on those files

[jwodder]

@yarikoptic Wouldn't it make more sense to store all that information in status.yaml instead of a Markdown file?

[yarikoptic]

{dandiset}/status.yaml sounds good but we are hitting the same aspect discussed in https://github.com/dandi/dandisets-healthstatus/issues/12#issuecomment-1369836893 -- inability to hyperlink into a specific portion of that yaml. So let's

• do just store it in status.yaml
• decouple running of tests from generation of top level README.md, so generation of README.md involves reading of all those status.yaml files and working on that data structure (aspect which was brought up here)
• use line numbers to corresponding sections in status.yaml. https://stackoverflow.com/questions/13319067/parsing-yaml-return-with-line-number seems to have suggested solutions for that -- sound quite feasible

[jwodder]

@yarikoptic Is this "Untested files" column for the first table in the README or the second table? What exactly should be linked to line(s) in status.yaml?

Also, how should information like file size and MIME type be handled for Zarr assets? Or should they just be omitted from this report?

reference to those files in the archive (URLs to API server

Exactly which URL/endpoint should be used for this?

[yarikoptic]

@yarikoptic Is this "Untested files" column for the first table in the README or the second table?

Eventually I think it might appear in both but let's start from the 2nd (per dandiset).

Also, how should information like file size and MIME type be handled for Zarr assets? Or should they just be omitted from this report?

can just do not special case them at all for now and just whatever file returns for them.

❯ file  .
.: setgid, directory
❯ file --mime-type .
.: inode/directory

What exactly should be linked to line(s) in status.yaml? ...

reference to those files in the archive (URLs to API server

Exactly which URL/endpoint should be used for this?

every reference you already have to status.yaml or will gain (e.g. for each dandiset in 2nd table) should become more specific and point to specific line in the .yaml file. So e.g. for the first line in the 2nd table it would become

Dandiset	pynwb_open_load_ns	matnwb_nwbRead	Untested
000003	101 passed, 0 failed, 0 timed out	6 passed, 6 failed, 89 timed out	whatevernumber

NB relative links would not work here within issue

The goal -- to make it easy to jump to specific listing of files to be troubleshooted.

[jwodder]

@yarikoptic Do you want the info on untested assets in status.yaml to include API URLs for those assets or not? If you do want it, exactly which URL should be used?

[yarikoptic]

I did not see the "need" for URLs in status.yaml - only listing of paths. Those files already could be large/hard to navigate, adding additional fields with urls might be "too much", and untested are nohow special really and we are not providing urls for ok/nok assets either ATM. (some greedy one might decide to add urls in # comments for each path, but I do not see immediate need ATM)