Display build info (timestamp) for debugging in production.

[corylown]

This is intended to capture refinement needed to how the Jekyll build/timestamp is displayed on the wallscreens. For production we want this to be unobtrusive but also available and legible for staff for debugging purposes.

• The more info modal may be a place to add a button, link, or hidden trigger to display the build info.
• Any existing build info should be removed from the main wallscreen display.

See discussion on PR https://github.com/sul-dlss/wallscreens/pull/226 for additional details.

[thatbudakguy]

i think it'd help to know what we expect the scenarios are for build info being used, especially by people outside the access team. @ggeisler's comments on the PR are helpful for imagining a scenario where:

• something is wrong with the wallscreen
• the access team wants more information
• the access team isn't available to look at the wallscreen ourselves
• a curator or staff is available to look at the wallscreen
• the person looking at the wallscreen shouldn't be expected to do much work to get the build info

if this is what we assume will be the most common case, what about just including the information in the "more info" modal and not hiding it at all? i think users are already pretty acclimated to seeing info like this in interfaces, so we might not need to create a complex interaction to access it.

if, on the other hand, we care a lot about not showing this info to the average user, we could include it on one of the non-wallscreen pages like the "homepage" — visible to anyone with access to the actual wallscreen PC, who can disable kiosk mode and check the page, but otherwise inaccessible. but maybe it isn't reasonable to expect anyone other than us to do things like this; not sure.

last thought: while timestamps are useful (and we get them pretty much for free), i feel like the most useful information is things that directly describe the content used in the build — so a version number or (even better) a commit hash. otherwise, one can create a wallscreen build at any time with no guarantee of what's actually in it. we could think about versioning the project in _config.yml, which would give us access to that info in templates. if there's a simple solution to get the commit hash, i think that'd be ideal.

[corylown]

if this is what we assume will be the most common case, what about just including the information in the "more info" modal and not hiding it at all?

I think this approach is worth considering. And I agree it might be useful to capture a version or commit hash.

[corylown]

Mockup that displays the build info in the more info modal:

[thatbudakguy]

so TIL there's a very useful git command git describe --tags, which produces output like:

$ git describe --tags
v0.0.2-222-g226533e

...of the form [t]-[n]-g[h], where [t] is the most recent tag (version), [n] is the number of commits since that tag, and [h] is the shortened commit hash. this seems ideal to me!

i went ahead and tried using a jekyll hook to expose this data by putting a file (I called it git_info.rb) in _plugins/:

Jekyll::Hooks.register :site, :pre_render do |site, payload|
    site.config['git_info'] = `git describe --tags`
end

sure enough, this made {{ site.git_info }} work in any template.

[ggeisler]

Sure, we can go with the modal approach @corylown mocked up. I still feel it's a bit wrong undesireable, from a UX perspective, to show information that to the vast majority of users is meaningless, but this subtle enough, should be simple to implement, and will be easy to direct SUL staff to for potential problem reporting purposes. So I agree it's probably not worth our time at this stage to design and implement a more involved solution just to hide it from visitors.