Show indication of when sandbox was last updated

[cecilia-donnelly]

@jcunard points out that we should show a message on the sandbox showing when it was last updated. This will be less important once we have continuous deployment (#222) set up, but for now it will help testers know when the sandbox has changed and is ready for them to take a fresh look.

[jasonaowen]

This is a good idea!

We should be careful how we implement it, and in particular we should avoid sabotaging reproducible builds. I don't know how close or far we are from that goal now, but adding in a timestamp at compile time would move us away from that goal.

In an ideal world, there is some environment variable WildFly exposes that says when the last deploy was. Second to that would be a variable we set as part of the deploy process, and just read from the application.

If that doesn't work out, we can add a build step to generate a JSP file that includes the current commit, ideally as a link to the commit on GitHub (https://github.com/OpenTechStrategies/psm/commit/${COMMIT_HASH}).

If we really, really need to compile in a date, the commit date would be better than the deploy date, since it will be stable across multiple builds.

[brainwane]

Relatedly: it would be good if we could configure https://solutionguidance.github.io/psm/javadoc/ to indicate in some way what commit it was built from. And/or mention on the gh-pages index page, https://solutionguidance.github.io/psm/ , what commit we're building the Javadocs and user docs from. (thanks to @jasonaowen for discussing this in https://github.com/SolutionGuidance/psm/pull/605#issuecomment-354176557 .)

[kfogel]

I don't think we need to endanger reproducible builds here. Just use the commit ID as the unique identifier (so it will always be the same for the same build, thus preserving determinism), and use that commit's date as the date. I agree with @jasonaowen that commit date is better than deploy date anyway.

Later on, if there are other timestamps we want to show (e.g., "database last reset at date X", etc), those can be calculated and presented at run-time, or via a configuration file, so again build determinism is not endangered.

[PaulMorris]

Okay, thanks @kfogel , I will proceed with @jasonaowen 's 3rd option above of "add a build step to generate a JSP file that includes the current commit" and include the date of the commit as well. (And I won't pursue his 1st and 2nd options -- using Wildfly variables or setting a variable as part of the deploy process.)

[PaulMorris]

Related: #851 Add Debug Mode