Jenkins, Groovy, Apache, etc...

[Andrew Bayer <an...@gmail.com>]

Hey all -

So - https://issues.apache.org/jira/browse/BUILDS-78 and the like, and the
issues around the release...I wanted to start talking about what we'd like
to move to builds.apache.org, what's needed to do so, what blockers there
are and the like. I kinda own builds.a.o, so I'm definitely the person to
talk to about getting things going there. =)

A.

Re: Jenkins, Groovy, Apache, etc...

[Paul King <pa...@asert.com.au>]

On 3/08/2015 6:31 PM, Andrew Bayer wrote:
> So - https://issues.apache.org/jira/browse/BUILDS-78 and the like, and the issues around the release...I wanted to start talking about what we'd like to move to builds.apache.org <http://builds.apache.org>, what's needed to do so, what blockers there are and the like. I kinda own builds.a.o, so I'm definitely the person to talk to about getting things going there. =)

Hi Andrew,

Thanks for kicking this thread off. One of the key people involved with setting up our CI server (Cédric) is on holidays, so expect some more feedback later, but we can certainly get discussions going. There are numerous things to talk about and some of them are possibly better discussed in their own threads but we might as well start here.

Our current CI runs on TeamCity and can be found here: http://ci.groovy-lang.org/

It handles numerous CI/deployment tasks:
+ running our test suites for the various streams of Groovy on their supported JDK versions (and various snapshot JDK versions)
+ building local OpenJDK snapshots used for above
+ running Github PRs across several JDK versions
+ building and publishing the "guide" (doco) part of the website - generated from specially built tests interwoven with markup - a live specification if you will (as well as providing standard Javadoc/Groovydoc doco for each version)
+ building our artifact bundles for a release (there are more than 270 jar artifacts involved in a release)
+ publishing artifacts with Maven/GVM/Bintray integration
+ running some joint builds for numerous integral/exemplar Groovy community projects

Many of these things are typical vanilla steps and can no doubt be made to work on any modern CI setup. So the TL;DR takeaway for my email is we should just set up a basic Jenkins build for Groovy so that obvious things that make sense to run within that environment can be done as people find time to migrate stuff across.

Having said that, there are numerous things which we are less clear on how to proceed:
+ full control over JDK and gradle versions is pretty crucial - we have up to 7 JDK versions that come into play (including weekly snapshots for OpenJDK 7, 8 and 9 which we build) when running the test suites for each commit. When new features are added to bleeding edge versions of Java, and when JDK bugs are discovered or fixed, we need to bring new JDK versions into play in a timely/low overhead fashion or retire them if no longer needed and in some instances we might need to tweak the JDK installations
+ there is a strong feeling amongst the committers to keep the TeamCity server in place into the foreseeable future; in the short-term, we are simply not going to have the time to migrate everything, especially for a sideways move that provides our users with no tangible benefits; and in the longer term there seems to be a sizeable portion of our user base who "use Groovy as a CI/devops glue language" and seem to value tight integration with TeamCity and Jenkins, so we'd like to have both for the time being. There are other CI infrastructure tools we'd also like to foster tight integration with but I am not sure we have the cycles right now to stretch any further.
+ we'd like to test across Linux, Mac OS X and Windows agents
+ we'd like to keep the release process as a devops process, it just makes sense for our complex build to remove the many points of failure that a manual process implies
+ we'd like minimal changes to how the guides (test Groovy code interwoven with asciidoc markup) are created and published
+ the existing integration with GVM and Bintray is also deemed crucial; we are confident we have nothing to worry about wrt Maven integration :-)
+ there is a strong preference to keep the groovy-lang.org domain for user oriented information (guides/doco), with developer oriented info using the Apache domain (so we need to discuss transferring that domain at some point). We used to have user doco under a codehaus domain and there was strong feedback within our community to have it available at a URL more closely aligning with what most other languages use, so we spent a lot of time and effort getting that in place and promoting that as the new home for such doco and we'd like not to undo that at this time.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus