[DISCUSS] Guacamole CI Builds

[Nick Couchman <vn...@apache.org>]

There's been some churn in the community of folks wanting some support for
continuous integration with the Guacamole repos.  Travis CI has come up a
couple of times - I stumbled across it and thought it might be useful, and
another contributor opened a PR for adding the travis.yml files for the
client and server repos.  However, Mike also pointed out that ASF also
operates a Jenkins instance that we could leverage.

So, the two questions up for discussion are:

1) Do we want to leverage a CI system, such as Jenkins or Travis, for the
Guacamole code?

2) If (1 == Yes), is there any reason we would not just use ASF's Jenkins
system?  Is there any compelling reason to go to Travis CI (or any other
system) over ASF's Jenkins?

My personal votes are:

1) Yes, we should leverage some sort of CI system, like Jenkins, for making
up-to-date builds available.  While the Guacamole code is relatively small
and easy to build yourself, there are certainly instances, both while
developing and while testing and using the product, that it's useful to
have those pre-built binaries available.

2) Personally I don't have an affinity for one CI system or another - if
ASF provides Jenkins, seems like that's probably the best way to go, but
I'm not familiar enough with Jenkins or Travis or any of the others to know
what the merits of one are vs. another.

-Nick

Re: [DISCUSS] Guacamole CI Builds

[Mike Jumper <mi...@guac-dev.org>]

On Tue, Sep 26, 2017 at 5:56 AM, Nick Couchman <vn...@apache.org> wrote:

> On Tue, Sep 26, 2017 at 2:45 AM, Mike Jumper <mi...@guac-dev.org>
> wrote:
> ...
> >
> > 2) Personally I don't have an affinity for one CI system or another - if
> > > ASF provides Jenkins, seems like that's probably the best way to go,
> but
> > > I'm not familiar enough with Jenkins or Travis or any of the others to
> > know
> > > what the merits of one are vs. another.
> > >
> >
> > I'm pretty squarely in the Jenkins camp, as I've found Travis overly
> > limiting and separation-of-concerns-violatey:
> >
> > https://github.com/apache/incubator-guacamole-server/
> > pull/110#issuecomment-331723648
> >
> > ... but am curious what others here think.
> >
> > - Mike
> >
>
> Sounds good - I agree that having the Travis CI code inside the repo seems
> a little...odd, and that it feels cleaner to have the build system handling
> things completely separate from the code.  Jenkins is fine with me, the
> more-so since ASF runs an instance.
>
>
We now have Jenkins handling CI for Guacamole:

https://builds.apache.org/view/E-G/view/Guacamole/

There are a currently a pair of builds which build the master branches of
guacamole-client and guacamole-server, and another pair of builds which do
the same but ship the results to Coverity Scan for analysis. The
guacamole-client builds were much easier, as the ASF build nodes seem
geared towards building Java, while the guacamole-server builds required
dynamic generation of Docker images to take care of installation of
dependencies without touching the build nodes themselves. Both of the
Coverity builds also download the Coverity build tools (~500MB) at the
beginning of the build to avoid having to install those tools globally.

All builds are configured to email dev@ upon failure.

Next steps are to add a build which verifies the latest still builds
against the various supported versions of FreeRDP (the other dependencies
do not need this), and then to look into checkstyle builds to verify the
style of received pull requests automatically, as suggested by Carl some
time ago:

https://github.com/apache/guacamole-client/pull/184#issuecomment-334850490

- Mike

Re: [DISCUSS] Guacamole CI Builds

[Nick Couchman <vn...@apache.org>]

On Tue, Sep 26, 2017 at 2:45 AM, Mike Jumper <mi...@guac-dev.org>
wrote:

> On Mon, Sep 25, 2017 at 7:38 PM, Nick Couchman <vn...@apache.org> wrote:
>
> > There's been some churn in the community of folks wanting some support
> for
> > continuous integration with the Guacamole repos.  Travis CI has come up a
> > couple of times - I stumbled across it and thought it might be useful,
> and
> > another contributor opened a PR for adding the travis.yml files for the
> > client and server repos.  However, Mike also pointed out that ASF also
> > operates a Jenkins instance that we could leverage.
> >
> > So, the two questions up for discussion are:
> >
> > 1) Do we want to leverage a CI system, such as Jenkins or Travis, for the
> > Guacamole code?
> >
> >
> Yes.
>
> ...
> > My personal votes are:
> >
> > 1) Yes, we should leverage some sort of CI system, like Jenkins, for
> making
> > up-to-date builds available.  While the Guacamole code is relatively
> small
> > and easy to build yourself, there are certainly instances, both while
> > developing and while testing and using the product, that it's useful to
> > have those pre-built binaries available.
> >
> >
> It's probably important to distinguish between CI and generation of nightly
> binary builds. CI has far more to offer than just providing pre-built
> binaries, and Guacamole would greatly benefit from CI.
>
> ...
>
> http://www.apache.org/legal/release-policy.html#host-rc
>
> Also:
>
> http://www.apache.org/legal/release-policy.html#release-types
>
> Specifically:
>
> "Nightly Builds ... are intended for regular testing of the build process
> and to give automated testers a common build for regression testing. They
> are not intended for use by the general public."
>

Good to know.  Nightly builds for dev/test only.


>
> 2) Personally I don't have an affinity for one CI system or another - if
> > ASF provides Jenkins, seems like that's probably the best way to go, but
> > I'm not familiar enough with Jenkins or Travis or any of the others to
> know
> > what the merits of one are vs. another.
> >
>
> I'm pretty squarely in the Jenkins camp, as I've found Travis overly
> limiting and separation-of-concerns-violatey:
>
> https://github.com/apache/incubator-guacamole-server/
> pull/110#issuecomment-331723648
>
> ... but am curious what others here think.
>
> - Mike
>

Sounds good - I agree that having the Travis CI code inside the repo seems
a little...odd, and that it feels cleaner to have the build system handling
things completely separate from the code.  Jenkins is fine with me, the
more-so since ASF runs an instance.

-Nick

Re: [DISCUSS] Guacamole CI Builds

[Mike Jumper <mi...@guac-dev.org>]

On Mon, Sep 25, 2017 at 7:38 PM, Nick Couchman <vn...@apache.org> wrote:

> There's been some churn in the community of folks wanting some support for
> continuous integration with the Guacamole repos.  Travis CI has come up a
> couple of times - I stumbled across it and thought it might be useful, and
> another contributor opened a PR for adding the travis.yml files for the
> client and server repos.  However, Mike also pointed out that ASF also
> operates a Jenkins instance that we could leverage.
>
> So, the two questions up for discussion are:
>
> 1) Do we want to leverage a CI system, such as Jenkins or Travis, for the
> Guacamole code?
>
>
Yes.

...
> My personal votes are:
>
> 1) Yes, we should leverage some sort of CI system, like Jenkins, for making
> up-to-date builds available.  While the Guacamole code is relatively small
> and easy to build yourself, there are certainly instances, both while
> developing and while testing and using the product, that it's useful to
> have those pre-built binaries available.
>
>
It's probably important to distinguish between CI and generation of nightly
binary builds. CI has far more to offer than just providing pre-built
binaries, and Guacamole would greatly benefit from CI.

Having an automated system build the code on multiple platforms, against
multiple versions of its various dependencies, all while executing unit
tests (and submitting builds for static analysis) is great. It helps ensure
the code satisfies its own tests and doesn't inexplicably break on a
previously known-good platform. Prior to acceptance into the Incubator, the
project had such jobs on its own Jenkins instance, where those jobs have
been continuing to run. We should really migrate them over.

Nightlies are an entirely different animal, and we need to be careful
there. AFAIK, there's nothing against nightly builds in policy, but they're
very strictly for development/testing only and we can't be pointing users
at those:

http://www.apache.org/legal/release-policy.html#host-rc

Also:

http://www.apache.org/legal/release-policy.html#release-types

Specifically:

"Nightly Builds ... are intended for regular testing of the build process
and to give automated testers a common build for regression testing. They
are not intended for use by the general public."

2) Personally I don't have an affinity for one CI system or another - if
> ASF provides Jenkins, seems like that's probably the best way to go, but
> I'm not familiar enough with Jenkins or Travis or any of the others to know
> what the merits of one are vs. another.
>

I'm pretty squarely in the Jenkins camp, as I've found Travis overly
limiting and separation-of-concerns-violatey:

https://github.com/apache/incubator-guacamole-server/pull/110#issuecomment-331723648

... but am curious what others here think.

- Mike