Question: Should the Specification PRs include the TCK zip SHA as a
way of ensuring that the TCK zip contents do not unexpectedly change
during the PR process (or that TCK zip contents didn't change a
second before the Spec Committee member ran the "promote" script)?
We did require the SHA in the PR during Jakarta EE 8. It's certainly
my preference, but I understand how people find it cumbersome.
However, it solves a lot of problems and provides a lot of freedoms.
Someday, I'd really love us to have a Github App that can help
automate some of the PR review process. Ideally it'd compute the SHA
and add it as a comment. It could even block a merge if the SHA has
changed.
Fancy ideas and no time :)
In the _index.md file for the TCK location, we should be specifying
this directory structure:_
__https://download.eclipse.org/jakartaee/_
<http://download.eclipse.org/jakartaee/_>{spec}/x.y/jakarta-{spec}-tck-x.y.z.zip
 (this is in our checklist, so I think we're good with this)
But, where should the "staged" version of the TCK be located?
I'm tuned in here to find out. :-)
I was mid post in a new thread a few hours ago with some ideas. I'll
try to get it finished and send it.