[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakarta.ee-spec] TCK URLs...
|
On 8/5/20 3:56 PM, Kevin Sutter wrote:
Hi,
I'm finding several inconsistencies with the TCK references in the
Specification PRs, especially with the directory structures and expected
locations.
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)?
In the _index.md file for the TCK location, we should be specifying this
directory structure:_
__https://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. :-)
We have
an item in the PR checklist to identify the staged location. Â I have
seen the following directory structures being referenced..._
__https://download.eclipse.org/ee4j/cdi/inject/2.0/_(as an example)_
__https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/staged-900/__
__https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee9-eftl/promoted/_
With Jakarta EE 8, it looks like we expected the TCKs to be staged in
the *"promoted"*directory (per a quick sampling of the past PRs - except
for cdi and bv...).
How the TCKs get to the "staged-900" and "promoted"
directories is a mystery to me.
Your not asking but in case anyone is curious, we have Platform TCK jobs
that copy the TCKs to the "staged-900" + "promoted" directories. We
also created 12 open issues [1] that describe the Jenkins jobs that are
used. However, the Platform TCK jobs that copy TCKs into ^ folders, are
only runnable by Platform TCK committers.
We started to discuss it on this
morning's Spec Committee call. Â Maybe we can continue this conversation
here instead of waiting for next week's call...
Just for completeness... after a ballot is completed, then a Spec
Committee member runs a script to "promote" the final TCK to this
location as defined in the _index.md file (above).
IMO, if we could pass the TCK ZIP SHA into the "promote" script so the
script could validate that the TCK contents didn't change, that would be
a good validation step.
Scott
[1]
https://github.com/eclipse-ee4j/jakartaee-tck/issues?q=is%3Aissue+is%3Aopen+review+and+promote