Add Build Time/HashTo Validator

[init-dcat-ap-de]

Currently I change something visible, like a label or a error message, to check wether or not a rebuild of the validator had happened after pushing to GitHub.

Example: https://github.com/GovDataOfficial/DCAT-AP.de-SHACL-Validation/commit/ce96ad63fe9d771ae9644d86f8a364e39dbbef9d

It would be nice to see the last build time and (/or) the GitHub Commit-Hash, that was used. Maybe in the footer of the validator website.

[costas80]

This is already possible. If you view the source of the validator's UI you will see at the very bottom of the HTML, information as follows:

<div class="no-display">
   <div id="build.version">1.2.0-SNAPSHOT</div>
   <div id="build.timestamp">2022-05-20 09:01:19 (Z)</div>
   <div id="startup.timestamp">2022-05-21 03:04:11 (Z)</div>
   <div id="resource.timestamp">2022-05-20 09:07:08 (Z)</div>
</div>

These timestamps (in UTC) have the following meaning:

• build.version: The specific release version of the validator (the SNAPSHOT version means this is a latest, non-milestone build, which applies for all validators hosted by the Test Bed).
• build.timestamp: The time when the validator application (the software) was last built.
• startup.timestamp: The time when the validator was last started.
• resource.timestamp: The time when the validator's configuration relevant to the specific "domain" being used was last updated.

In your case what addresses your need is the resource.timestamp. This is the time when you last updated your configuration (for DCAT-AP.de for example).

Having said this, this information is not documented (only partially in the validator's Change history section). We'll add this point on our backlog to better document this.

Does this cover your needs?

[init-dcat-ap-de]

Yes, perfect. The hidden elements are fine for me.

[costas80]

The validator's documentation has been updated to document the discussed timestamps (see the change history section).

Regarding the resource.timestamp property, I should point out that this may be two things:

• For validators running as JARs or on-premise Docker containers pointing to resources on filesystem, this is the time when the configuration was last updated (as initially explained).
• For validators running as Docker containers with bundled configuration (as is the case for validators hosted by the Test Bed) this is the time when the configuration was last checked for updates.

In the case of the DCAT-AP.de validator which is running on the Test Bed the second case applies, meaning that the discussed timestamp indicates when the configuration was last checked. Any changes made before this time will have been taken into account.