[WildFly] Announcing public CI

We are proud to announce our public CI system, which is running integration tests for WildFly, WildFly Core, Undertow, and many other related projects. This system ensures that we do not merge anything that is broken and that our master is always stable.

CI also helps us with testing pull requests by:

Making sure the code works on most common target platforms, currently Linux and Windows.

Integration testing components as part of the full WildFly test suite. This is most often used when testing WildFly Core, where we test core itself as well as changes to core integrated on top of WildFly. This ensures that the latest core always works with the latest WildFly master.

Running additional test suites such as mixed-domain tests, which are a bit harder to set up and run locally.

Running complex integration tests that span across multiple projects, such as Elytron integration work that is landing in WildFly 11.

It is also utilized to test WildFly against various platforms and JDK combinations, such as testing the IBM JDK on Linux and Windows, testing Solaris SPARC, as well as regularly testing early builds of JDK 9. CI also produces nightly builds of WildFly and WildFly core, which you can follow on our forums.

We are using TeamCity as our CI with a few of our own customizations, including the following:

A bit-modified, unofficial TeamCity.GitHub plugin that allows us to post failed tests and other details of the failure to the pull request.

A pull-player, which we use as our trigger for pull requests. It provides us with a whitelisting of pull request authors for which CI tests are auto-triggered to prevent denial-of-service attacks. It also provides an option to retrigger CI testing by adding the comment “retest this please” to the pull request.

The system is powered by three servers running an ESXi hypervisor with everything else virtualized.

The front entry point is running Nginx with configured HTTP that is using an SSL certificate provided by Let’s Encrypt.

The infrastructure is managed by Ansible with a set of our playbooks.

We would like to thank JetBrains, which kindly donated the open source license for TeamCity.

Out of the Box HTTP/2 and TLS
Unique to WildFly, is that HTTP/2 now works without any special JVM flags (even on Java 8!), configuration changes, or keystore changes. You simply point your browser at port 8443 and WildFly will automatically generate a self-signed TLS cert for you, and negotiate HTTP/2 if your browser supports it (most do). When you are ready to deploy in production, you simply update the keystore with whatever cert you would like to present to your users.

Load-balancing Profile
In order to make it even easier to get started with load-balancing, we added a profile to the default domain.xml file, called "load-balancer". You can now build a fully clustered topology using just our default profiles in domain mode, creating a server with the "load-balancer" profile, and a set of backend servers using the "full-ha" profile.
wildfly.org/news/2016/08/19/WildFly10-1-Released/