Re: [ee4j-build] Notes from Eclipse EE4J Build team discussion today (Ma

[Ed Bratt <ed.bratt@xxxxxxxxxx>]

Martin

Thanks for your offer. Our current philosophy is to try and re-engineer as little as possible as we transition everything over to Eclipse. This is true for migrating scripts for CI/CD systems. As you might imagine, we are discovering all the places where we take the underlying system features and configurations for granted. The issue that has held up GlassFish builds (and this could well extend to other build jobs) is that we rely on NFS file-systems to transfer artifacts from the Jenkins/Hudson Master to the corresponding Slave. Eclipse has systems that use cloud based VMs where NFS isn't supported between the different nodes and also systems in-house that do provide NFS support. It seemed like pinning these jobs to the specific nodes that provide NFS support was going to be relatively easy.

We spent about a week trying to build a conversion feature so that we could use the plugin's provided in Jenkins to perform the same exchange, but the developer team concluded it would take too much re-engineering right now. Initially, we didn't expect this would take so long to provision at Eclipse, but I understand they will have these systems ready for us by the end of this week.

Going forward, it would be great to remove this NFS dependency throughout our build scripts. I'd love to see the infrastructure be more flexible and facilitate cloud utilization. I expect that we will want to gravitate more of our infrastructure to containerized operations as well so this work won't be just for one EE4J project.

Jignesh and Arindam are the folks doing the development work here. Feel free to discus the initial details here on the list or if you want to just work directly with them, we would definitely appreciate it. Hopefully, we can create a pattern that other community members can follow to improve the Eclipse GlassFish, and other EE4J component project builds.

Cheers,

-- Ed

On 3/22/2018 3:33 AM, Martijn Verburg wrote:

Hi Ed,

Anything we can do to help unstick Glassfish?  I'm part of the AdoptOpenJDK build farm, maybe there's a challenge that we've faced before?

Cheers,
Martijn

On 22 March 2018 at 00:14, Ed Bratt <ed.bratt@xxxxxxxxxx> wrote:

If any of this is incorrect, please reply with corrections and/or updates

GF build infra. Still stalled. This is becoming more and more urgent as we approach contribution of GlassFish proper to Eclipse.

MQ builds -- Moved to production instance. Yamini solved the port issue. Yamini will provide solution to this list so others can follow this pattern.

JSON-B -- ready to submit CQ (but we still need internal approval so please wait for that).

JAXB -- GF still requires JAXB1 -- need to amend the project.

Jan -- Jersey update. Migrating internal jobs to internal Jenkins to facility contribution. Hope to complete this migration this week.

Anand -- Having trouble with Grizzly unit tests that are timing out. Also noticing that authentication/credentials sometimes revert to read-only. Eclipse requests these be run without timeout to see how long they actually take. Please let the team know when this is completed.

JSON-P -- GlassFish org. Jobs interact at the port level. May need to regularize the port selection code (See Yamini's update). Or, "dockerize"

Tomas -- Also working to containerize build patterns to avoid interactions across build jobs running in parallel on Jenkins.

Thanks,

-- Ed

_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-build

_______________________________________________
ee4j-build mailing list
ee4j-build@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ee4j-build