Additionally below pipeline jobs also need to exist in
Glassfish CI.
Can you please help do this as you have access to both the CI
instances (once you are back).
I'm very much in favor of GlassFish, as a compatible
implementation, becoming self-sufficient with respect to
compatibility testing.
There are two things to consider
- Testing at existing and legacy compatibility levels, and
- 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. 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.
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.
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
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
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/glassfish-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!LjQWpZTlhq0fAlH1abySOcZTk0d0NBqgBQr-6JEAA4tFLL5m7evvFqyb6Utaoxc$
_______________________________________________
glassfish-dev mailing list
glassfish-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/glassfish-dev__;!!GqivPVa7Brio!Mn_b9sevfCra1RBDI3hwPweVodV5s5rCVQhUipwfAx5MiWF8GWbX_wAMwoMsZ-ZTMg$
