Projects that produce nightly and staged TCKs ought to be able to promote them wherever is appropriate for their project. That's why the URL needs to be listed in the PR template checklist.
Completely agree. If a project wanted to explore some sort of continuous TCK delivery techniques and go off the deep end on things like "repeatable builds", great. I'm sure some pioneers will and it it will benefit us all. Checking that the final artifacts are linked should be enforced in the CCR issue and the TCK results documentation page. These last two /may/ point at a different stage location, but the SHA-256 must match the final TCK that is pushed to download.eclipse.org/jakartaee/... We could double check all this, once the ballot is complete.
Right, as long as the SHA-256 matches the name and location of the binary can change as it works its way through promotion and even after once wild in the outside world. In cases where a link must be provided within a document that is also included within this content (i.e. what link should be used in a TCK User Guide?) I recommend just pointing those to the Specification page (i.e. https://jakarta.ee/specifications/dependency-injection/2.0/). This is so that there isn't a need to update the documentation if the version number of the TCK changes (i.e. moves from 1.0.0 to 1.0.1, etc.)
-David
|
