Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakartaee-tck-dev] [glassfish-dev] Ongoing GlassFish testing

Great,

Let me start-on copying glassfish CI jobs from below mentioned jakartatee-tck jobs.

regards,

Guru

On 26/11/20 7:19 pm, Alwin Joseph wrote:

Hi,

IMO we can copy below upstream jobs from Jakartaee-tck CI instance to Glassfish CI instance to run the platform & standalone TCK tests. They are configured to use a prebuilt TCK bundle & glassfish bundle to run the tests.

https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-certification/
https://ci.eclipse.org/jakartaee-tck/job/jakartaeetck-certification-web/
https://ci.eclipse.org/jakartaee-tck/job/standalonetck-certification/
https://ci.eclipse.org/jakartaee-tck/job/eftl-jakartaeetck-certification/
https://ci.eclipse.org/jakartaee-tck/job/eftl-jakartaeetck-certification-web/
https://ci.eclipse.org/jakartaee-tck/job/eftl-standalonetck-certification/
https://ci.eclipse.org/jakartaee-tck/job/eftl-jaxbtck-certification/

Additionally below pipeline jobs also need to exist in Glassfish CI.

https://ci.eclipse.org/jakartaee-tck/job/jaf-tck/
https://ci.eclipse.org/jakartaee-tck/job/jaxb-tck/
https://ci.eclipse.org/jakartaee-tck/job/mail-tck/
https://ci.eclipse.org/jakartaee-tck/job/debugging-support-for-other-languages-tck/

Guru,

Can you please help do this as you have access to both the CI instances (once you are back).

Regards,
Alwin

On 25/11/20 5:02 am, Ed Bratt wrote:

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

  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. 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

On 24 Nov 2020, at 18:35, Steve Millidge (Payara) <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
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$ 

_______________________________________________
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!MCZajDKS6ok9QGWw1vh08xlol49sGMZ7H_IE5Yin4wLKfRVHnL1CWXPI90xGyM9G2mI$ 

Back to the top