Add timestamp to HTML report
Closed this issue · 12 comments
The compliance checker HTML report is really nice! But it'd be even more helpful if it included an eyeball-friendly run-time timestamp. iso8601 would be fine. That should be easy to add, and it'd help users who (like me) are looking at saved, older versions of the report.
While I'm at it, I'd also suggest adding a link (say, in the header) to the compliance checker web site, https://github.com/ioos/compliance-checker. It should be trivially easy, and non-obtrusive
run-time timestamp
While a timestamp would be helpful I wonder what really means a report change? A new version of cc? Changes in the data?
Maybe that timestamp should also have the cc version, if not already, and/or a data hash to ensure that the run was performed on the same data or on a new set.
PS: the hash may be tricky and slow. I'm not 100% sold on that idea.
While a timestamp would be helpful I wonder what really means a report change? A new version of cc? Changes in the data?
To me, it's just a reference to when the report was generated. It may not be helpful to many users, but at least to the person testing compliance over some extended period of time (days, weeks), it's really handy to see it there.
Maybe that timestamp should also have the cc version, if not already,
It's not there. I totally agree that adding the cc version would be great, and is very much complementary to the timestamp.
and/or a data hash to ensure that the run was performed on the same data or on a new set.
PS: the hash may be tricky and slow. I'm not 100% sold on that idea.
Looks like you're going well beyond my original limited scope, and thinking about the ability to compare two cc runs. That could be great, but I think it's a different beast than simply adding run-time timestamp and cc version, which should be very easy additions.
As someone who relies on the checker for use with a lot of files, I would also really appreciate a timestamp and a version number in the html header. We routinely capture both the html output and the standard error for tests run for each file in batches of files for later review.
Standard error gives us a little more info about the run (and the version number in case of an exception if "-v" parameters are passed): i.e.
`Downloading cf-standard-names table version latest from: http://cfconventions.org/Data/cf-standard-names/72/src/cf-standard-name-table.xml
Running Compliance Checker on the datasets from: ['A0141.currents.adcp.merged.nc']
Using packaged standard name table v72
WARNING: The following exceptions occured during the cf:1.7 checker (possibly indicate compliance checker issues):
cf:1.7.check_data_types: type object 'str' has no attribute 'kind'
File "c:\apps\anaconda3\envs\cc-test-dev\lib\site-packages\compliance_checker-4.3.3rc2+64.g71a4228-py3.8.egg\compliance_checker\cf\cf.py", line 1326, in check_data_types
if v.dtype.kind != "S" and all(`
Program exceptions are not seen in the html output, otherwise and with a batch of files run under script control can easily go unnoticed.
The other piece of information that would be useful somewhere in the output for those of us who might save output for later review would be the parameter list passed to the compliance checker -- it lets you know if strict checking was invoked, if a standard name vocabulary other than the default used, or if the cf: enable-appendix-checks options was invoked for example.
I realize this might be a boutique application and I might be the only one that finds this useful but I thought I'd put it out there.
In the spirit of my initial request being both useful and (hopefully) easy to implement, I add a 👍 to this:
The other piece of information that would be useful somewhere in the output for those of us who might save output for later review would be the parameter list passed to the compliance checker -- it lets you know if strict checking was invoked, if a standard name vocabulary other than the default used, or if the cf: enable-appendix-checks options was invoked for example.
@emiliom, @ocefpaf and @ancillary, thank you for your input! We will be looking into this shortly
Hi all, just revisiting this now. The timestamp is the easiest and quickest to implement. I might have a quick solution:
--------------------------------------------------------------------------------
IOOS Compliance Checker Report
Report generated 2020-06-12T14:28:54.033854
acdd:1.3
http://wiki.esipfed.org/index.php?title=Category:Attribute_Conventions_Dataset_Discovery
--------------------------------------------------------------------------------
Corrective Actions
and for the HTML output:
Would that suit your needs?
Probably can round to nearest second, microsecond resolution a bit overkill
That definitely covers the timestamp. I'd only add a timezone / UTC offset / Z indicator; it's not a big deal, at least for me, but it'd make the timestamp more universally helpful. Thanks!
Adding the cc version would be great too. I understand if that would be a separate issue.
I think I got it:
and text output:
--------------------------------------------------------------------------------
IOOS Compliance Checker Report
Version 4.3.3+0.g71a4228.dirty
Report generated 2020-06-12T15:05:35Z
acdd:1.3
http://wiki.esipfed.org/index.php?title=Category:Attribute_Conventions_Dataset_Discovery
--------------------------------------------------------------------------------
Perfect!!
For tracking, this is addressed by #823
Closing as this is addressed by #823