Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-spec] TCK URLs...

On Aug 5, 2020, at 3:20 PM, Scott Marlow <smarlow@xxxxxxxxxx> wrote:

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)?

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/_{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.

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.

That would be a great addition.  Right now it will compute the SHA and signature before an upload.  


When an upload is complete it will download them again and check the SHA and signature.


Right now our input is actually a list of URLs:


Having it take a list of SHAs would be possible.  We could check that each file has to match one of the supplied SHAs or the publish fails.

Of course it'd be nice to have "this is the SHA for this specific file" vs a list and list, but that would require much more rework of the script.  Mathematically, the odds are by definition impossibly low that a supplied SHA would match more than one file or falsely match a file.


-David

Back to the top