Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] TCK URLs...

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 file for the TCK location, we should be specifying this directory structure:_ __ <>{spec}/x.y/jakarta-{spec}  Â (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 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!).

Hi all,

In the short term, I think that the Platform TCK team should continue to stage new TCKs as the TCK documentation is updated (or tests fixed if needed). Each staged TCKs is subject to change until the Platform TCK team is asked to promote a respective TCK, which means no more changes are allowed to the (versioned) TCK zip (at least not without first incrementing the version number).

Also, for communicating with the TCK team, as to when the TCK team should promote a TCK zip from to, we have created tracking issues for many of the TCKs. To view the open issues use

In the thread we came up with good ideas for changing the staged TCK zip file name (or contained folder name) to include the TCK zip SHA + (time of staging) timestamp.

In terms of when to switch to this new process to use new names we could slip that in at some point as long as it doesn't disrupt the teams involved by much, however we will need to figure out the process changes for dealing with the TCK SHA + timestamp in the file name or containing folder name.


Back to the top