Re: [jakarta.ee-spec] TCK URLs...

[Scott Marlow <smarlow@xxxxxxxxxx>]

On 8/5/20 8:10 PM, David Blevins wrote:
> > On Aug 5, 2020, at 3:20 PM, Scott Marlow <smarlow@xxxxxxxxxx 
> > <mailto: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/_ 
> > > <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.

Thanks David, I assume you mean the 
https://www.eclipse.org/lists/jakartaee-tck-dev/threads.html#00858 
thread that you started.  I like the idea of including the SHA in the 
staged TCK name, as that makes it more obvious as to which TCK is 
intended to be in the pull request (so fewer mistakes or errors will 
happen, very nice!).

Scott

> > 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.
>
>   - 
> https://github.com/jakartaee/specification-tools/blob/master/promotion/promote-release.sh#L80
>
> When an upload is complete it will download them again and check the SHA 
> and signature.
>
>   - 
> https://github.com/jakartaee/specification-tools/blob/master/promotion/promote-release.sh#L128
>
> Right now our input is actually a list of URLs:
>
>   - 
> https://github.com/jakartaee/specification-tools/blob/master/promotion/promote-release.sh#L15
>
> 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
>
>
> _______________________________________________
> jakarta.ee-spec mailing list
> jakarta.ee-spec@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-spec