[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] [glassfish-dev] Ongoing GlassFish testing
|
More inline below.
On 11/24/20 6:32 PM, Ed Bratt wrote:
I'm very much in favor of GlassFish, as a compatible implementation,
becoming self-sufficient with respect to compatibility testing.
+1
There are two things to consider
1. Testing at existing and legacy compatibility levels, and
2. Supporting evolution of the Jakarta EE Platform.
To date, GlassFish and the platform evolution have gone hand-in-hand.
That shouldn't be presumed, moving forward, but we shouldn't do anything
that will preclude this.
Additionally, the Platform API and Component committer groups have their
own obligation to evolve their TCKs and it they must do that with an
implementation that's willing and staffed to undertake that effort -- as
a collaboration. No Spec. can evolve without a compatible implementation
to go along with it.
I'd be in favor of expanding the Jenkins test array for GlassFish to
support the version(s) of TCK validation and other environment changes
(i.e. JDKs, OSes, Databases, etc.) that are necessary for GlassFish
releases.
I do not think these should be assumed to replace the requirements of
the various Platform and component API team responsibilities. So, I
think this starts out that GlassFish would copy over what's in the
Jakarta EE TCK project -- but Jakarta EE TCK project still has it's own
operational requirements. (Over time, hopefully, the EE TCK project
requirements may diminish, but for now, it looks to me like it's almost
strictly and additional effort.)
In an ideal world, GlassFish compatibility testing would include the
Platform TCK -- as well as validation that all included technologies are
compatible. This would suggest that GlassFish should run the Platform
TCK and all the stand-alone TCKs that cover content included.
Moving these out of the TCK project should be straight-forward though I
don't know if the TCK team is planning any "high priority" maintenance
that they'd want to bring over to the GlassFish CI/Jenkins.
I would expect some continuation of the memory/CPU core tuning to make
better use of the test environment.
Currently for every VM running TCK tests, we are using:
* 10 GB of memory
* 2 CPU cores
I would like us to instead try using for every VM running TCK tests:
* 4-5 GB of memory
* 1 CPU cores
We likely need to alter some of the TCK running scripts to run fewer
tests per VM to avoid running out of memory.
The risk of switching to 1 CPU core is we could hit bugs.
On the plus side, IMO we would be able to roughly double our amount of
concurrent testing with the tuning change (after solving the likely OOM
failures).
Additionally IMO, we should keep the GlassFish deployment descriptors in
the Platform TCK as a source for other implementations to dynamically
remap. From a `find -name *sun*.xml | wc -l` check, I see there are
`2909` of these files.
There are also other GlassFish specific scripts + various other files
(e.g. root JenkinsFile aspects for running the TCK) that we may want to
copy over to GlassFish as well. IMO copying such files is best for now.
Maintaining
them could be a more complex chore, especially as it's likely the TCK
content and structure may evolve over the course of the next couple of
releases. But that's a future problem.
Yes, it is a future problem. Also, do we maintain every EE release
forever? In 10-100 years, could still respond to Jakarta EE 8 TCK test
challenges with Java SE 8 as the base JDK? These problems probably
belong in the future problem set to solve but thought I would mention it
anyway.
I'll can probably find someone who can copy the appropriate jobs over to
the GlassFish Jenkins instances. We will need to generate some project
specific expertise over time though. And, maybe we can actually make
some improvements in how it runs, for the GlassFish project.
+1 for generating/spreading the project specific expertise.
Scott
More that likely, we'll need to be judicious about how and when we use
the CI resources since GlassFish does not have as many systems at it's
disposal as the Jakarta EE TCK -- if available resources becomes an
issue, we can certainly take it up to the Working Group steering
committee and see if resources can be shuffled around.
-- Ed
On 11/24/2020 10:44 AM, Gurkan Erdogdu wrote:
Hi
+1 to move into GlassFish Jenkins instance
Regards.
Gurkan
On 24 Nov 2020, at 18:35, Steve Millidge (Payara)
<steve.millidge@xxxxxxxxxxx <mailto:steve.millidge@xxxxxxxxxxx>> wrote:
All,
As we move to getting a GlassFish final released. I’ve a question on
TCK testing. Up to the release of Jakarta EE we’ve been using the TCK
project Jenkins jobs to test GlassFish compatibility. Now that the
TCK has been released some questions come to mind.
Should we move testing over to the GlassFish Jenkins instance or keep
it at the TCK Jenkins?
If we decide to move to the GlassFish instance can somebody help with
updating the TCK jobs here or create new testing jobs?
If we decide to keep GlassFish testing on the TCK instance can
somebody help kick off jobs periodically?
Thanks
Steve
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx <mailto:glassfish-dev@xxxxxxxxxxx>
To unsubscribe from this list,
visithttps://www.eclipse.org/mailman/listinfo/glassfish-dev
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!LjQWpZTlhq0fAlH1abySOcZTk0d0NBqgBQr-6JEAA4tFLL5m7evvFqyb7-GGYsQ$>
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visithttps://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!LjQWpZTlhq0fAlH1abySOcZTk0d0NBqgBQr-6JEAA4tFLL5m7evvFqyb6Utaoxc$
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
