groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Jenkins, Groovy, Apache, etc...
Date Mon, 03 Aug 2015 13:35:15 GMT
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


Mime
View raw message