Add Travis CI integration

[b-long]

I'd like to add Travis CI to this project, so that we can increase it's adoption among open source contributors.

[kwwall]

I can see how this might make sense adding Travis CI to
"ESAPI/esapi-java-legacy", but I'm not quite seeing the
value of adding it to "ESAPI/esapi-java", because in reality,
at this point, there is no THERE THERE. Presently, it is only
a set of interfaces and incomplete ones at that so there
is not really much there too 'build' if you will. But whatever.

Chris Schmidt had already set up a CloudBees (Jenkins) CI
instance at https://esapi.ci.cloudbees.com/, so I'm not really
sure why we should have BOTH a Jenkins and Travis-CI instance.
I mean, it that's what people expect / want and it doesn't
cost ESAPI anything, then go for it. But I just wasn't sure
if you were aware of the CloudBees nightly builds.

-kevin

On Mon, Mar 14, 2016 at 6:59 PM, Brian Long notifications@github.com
wrote:

I'd like to add Travis CI to this project, so that we can increase it's
adoption among open source contributors.

—
Reply to this email directly or view it on GitHub
#4.

Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.

[kwwall]

@b-long Could you please explain to a relative CI newb like me why we need / should have BOTH a Jenkins AND a Travis-CI nightly build? What's the advantage? And what, if anything, is the downside?

[ramzimaalej]

I believe we just need one CI. I don't see any advantage of having both.

[jaxley]

CI build != nightly build. The difference is in frequency of builds and merges. CI attempts to merge frequently and build the code more frequently than once a day, including running all unit tests, to ferret out any integration issues with the code changes. If there are not very many contributors, and therefore not many merges to master during the day, then the frequency probably would not have a practical effect.

You could set a build to run at least hourly, for example, so long as there were commits in that hour.

Was the plan to add more frequent builds to the Jenkins setup?

Which option would be easier to manage (especially access management) and monitor for build failures? I haven't used Travis but have seen that github can display the current CI build status; not sure if it has the same option for Jenkins.

[b-long]

Sorry for the spam all, I didn't see all the traffic on this thread when I last commented on #3 .

Right, so, CI attempts to build continuously . The important characteristic in today's open source world is to build all merge requests before you merge. The other important characteristic is to be simple. Jenkins is not simple IMHO (I've been a fan of it since 2010, but this winter was the last straw).

Modern CI systems are highly flexible and can be setup in minutes. All of them provide the build badges you've mentioned. There are many offerings that are provided as a service for free: wercker, appveyor, and travis are just a few. What's more, you can build on Linux, Mac and Windows using these and have confidence that your build works on all target platforms. Since each of these are free, there's no down-side to using multiple offerings. Typically, by building on Linux, Mac and Windows your tests will become even more robust.

[kwwall]

I understand the concept of CI & how the 'c' is continuous. Just sayin'
the CloudBee's Jenkins instance is apparently set up to do nightly builds.
Given how we only get commits less than 1x/month for ESAPI 2.x and never
for ESAPI 3, I think that schedule is fine.

What is holding up progress IMO is not CI related, but is rather simply not
enough people contributing bug fixes.

-kevin
Sent from my Droid; please excuse typos.
On Mar 15, 2016 9:30 AM, "Brian Long" notifications@github.com wrote:

Sorry for the spam all, I didn't see all the traffic on this thread when I
last commented on #3 #3 .

Right, so, CI attempts to build continuously . The important
characteristic in today's open source world is to build all merge requests
before you merge. The other important characteristic is to be simple.
Jenkins is not simple IMHO (I've been a fan of it since 2010, but this
winter was the last straw).

Modern CI systems are highly flexible and can be setup in minutes. All of
them provide the build badges you've mentioned. There are many offerings
that are provided as a service for free: wercker http://wercker.com/,
appveyor https://www.appveyor.com/, and travis https://travis-ci.org/
are just a few. What's more, you can build on Linux, Mac and Windows using
these and have confidence that your build works on all target platforms.
Since each of these are free, there's no down-side to using multiple
offerings. Typically, by building on Linux, Mac and Windows your tests will
become even more robust.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
#4 (comment)

[bkimminich]

I favor Travis-CI for OSS projects a lot over Jenkins, as they basically offer a full-grown CI service for free w/o need for maintenance etc. You get free build matrix (e.g. for multiple JDKs) and tons of useful free cloud services (e.g. Coverity, Coveralls etc.) that integrate with Travis-CI.

[b-long]

@kwwall IMHO, there are a few issues with Jenkins :

1. Visibility (Where is it?)
2. Control (What if there's a problem?)
3. Cost (Maintenance)

This PR of mine needs some work. Separately, I'm trying to convey the value in the esapi-legacy project. Here's the diff and here's the build badges showing the value in the README . Notice, this project is having issues building on Windows.

[ramzimaalej]

I think most of people are in favor TravisCI, and with all concerned that
have been raised about Jenkins, I'm convinced that TravisCI is our best
shot. Should we move on and get it configured ?

2016-03-29 13:05 GMT-04:00 Brian Long notifications@github.com:

@kwwall https://github.com/kwwall IMHO, there are a few issues with
Jenkins :

1. Visibility (Where is it?)
2. Control (What if there's a problem?)
3. Cost (Maintenance)

This PR of mine needs some work
#5. Separately, I'm trying to
convey the value in the esapi-legacy project. Here's the diff
https://github.com/b-long/esapi-java-legacy/pull/1/files and here's the
build badges showing the value in the README
https://github.com/b-long/esapi-java-legacy/tree/ci-integration#readme
. Notice, this project is having issues building on Windows
https://ci.appveyor.com/project/b-long/esapi-java-legacy/build/9.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4 (comment)

Cheers,
Ramzi

[kwwall]

I have no objection to using TravisCI instead of Jenkins via CloudBees.
BUT, if we are going to do that, let's also do it for ESAPI-java-legacy as
well since that at least has some real implementation code behind it an is
not just interfaces.

@chrisisbeef - you okay with that?

-kevin
Sent from my Droid; please excuse typos.
On Mar 30, 2016 3:31 PM, "Ramzi Maalej" notifications@github.com wrote:

I think most of people are in favor TravisCI, and with all concerned that
have been raised about Jenkins, I'm convinced that TravisCI is our best
shot. Should we move on and get it configured ?

2016-03-29 13:05 GMT-04:00 Brian Long notifications@github.com:

@kwwall https://github.com/kwwall IMHO, there are a few issues with
Jenkins :

1. Visibility (Where is it?)
2. Control (What if there's a problem?)
3. Cost (Maintenance)

This PR of mine needs some work
#5. Separately, I'm trying to
convey the value in the esapi-legacy project. Here's the diff
https://github.com/b-long/esapi-java-legacy/pull/1/files and here's
the
build badges showing the value in the README
https://github.com/b-long/esapi-java-legacy/tree/ci-integration#readme
. Notice, this project is having issues building on Windows
https://ci.appveyor.com/project/b-long/esapi-java-legacy/build/9.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#4 (comment)

Cheers,
Ramzi

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#4 (comment)

[chrisisbeef]

As previously mentioned - I am completely impartial to which CI server software / hosting we go with. What is more important to me is that it allows us to do releases (without making drastic and/or incompatible changes to our build/release strategy) and that someone owns this.

[bkimminich]

Could you post a list of requirements that todays Jenkins fulfills so we can check if Travis gives us the same or similar features? Then I'm happy to help setting up the corresponding YAML configuration for Travis here and in the legacy project.