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 [email protected]
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" [email protected] 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 [email protected]:

@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" [email protected] 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 [email protected]:

@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.

[chrisisbeef]

@bkimminich - The CI vision was never fully realized with Jenkins, so really what my list of requirements are (for both esapi-legacy and esapi-3)

1. Continuous/Nightly Builds (nightly pushed to Maven Central)
2. Published test reports
3. PR Building
4. Pushbutton Release

[kwwall]

And, I would add someone to take ownership of the CI process and be will to attend to it in a timely fashion, when / if something goes awry. (I don't mean fixing broken builds or tests, but rather coordinating with people to get those things done, attending to CI infrastructure problems, etc.)

…

-kevin

[bkimminich]

1. Continuous builds = no problem, Travis builds on every GitHub push / Nightly builds = Intentionally not supported by Travis (Build periodically travis-ci/travis-ci#582) but would be possible with some 3rd party service (e.g. https://nightli.es)
2. Travis doesn't persist build artifacts or reports, but it can certainly deliver them somewhere during the build process. Or we can integrate some convenient service like http://coveralls.io (e.g. via https://github.com/trautonen/coveralls-maven-plugin) or https://scan.coverity.com which directly supports Java projects.
3. Travis supports building all PRs separately.
4. This does not fit into the Travis approach. But it's possible to get something similar, like doing the release building and publishing to GitHub when a tag is built: https://docs.travis-ci.com/user/deployment/releases/

[bkimminich]

I've implemented a Travis CI build for my fork of https://github.com/ESAPI/esapi-java-legacy including integration with Coveralls (measures test coverage) and Coverity (measures code quality). I could send a PR for that, but you'd have to change the coverity token (secure: "..." in the .travis.yml) because the current one is valid only in my fork:

https://github.com/bkimminich/esapi-java-legacy

Build and analysis badges are embedded in the readme which link to the corresponding services.

[kwwall]

We already have a Coverity instance for ESAPI Java legacy.

I can add you to that one, but I prefer not to have multiple ones.

-kevin
Sent from my Droid; please excuse typos.
On Apr 11, 2016 4:26 AM, "Björn Kimminich" [email protected] wrote:

I've implemented a Travis CI build for my fork of
https://github.com/ESAPI/esapi-java-legacy including integration with
Coveralls (measures test coverage) and Coverity (measures code quality). I
could send a PR for that, but you'd have to change the coverity token (secure:
"..." in the .travis.yml) because the current one is valid only in my
fork.

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

[b-long]

@kwwall Kevin, it just doesn't make sense that ESAPI isn't doing some of the things that engineers have come to expect from modern/robust projects. Consider the node mysql README or the node express README. Just glancing at the top of these documents we get a great sense for the stability and richness of the projects. Just as the code is open to the world, so should the CI system (and it should invoke all of your development platforms). I tried to do this for the group, but I was disheartened by the response. If you would please, just take a look at this : https://github.com/b-long/esapi-java-legacy/tree/ci-integration#readme . It's addressing the legacy project, but right away we see that we might have work to address.

[bkimminich]

You already are on Coverity, then the only thing you need is to change the secure token from mine to yours and you get a free analysis whenever you merge+push to the coverity_scan branch. Coveralls is not even requiring a token, so it just needs to be setup via their website.

I'll submit my changes as a PR. If you like I can do the same setup for ESAPI 3.X even if there is not much to build, test and scan today.

Am 11. April 2016 16:30:44 MESZ, schrieb "Kevin W. Wall" [email protected]:

We already have a Coverity instance for ESAPI Java legacy.

I can add you to that one, but I prefer not to have multiple ones.

-kevin
Sent from my Droid; please excuse typos.
On Apr 11, 2016 4:26 AM, "Björn Kimminich" [email protected]
wrote:

I've implemented a Travis CI build for my fork of
https://github.com/ESAPI/esapi-java-legacy including integration with
Coveralls (measures test coverage) and Coverity (measures code
quality). I
could send a PR for that, but you'd have to change the coverity token
(secure:
"..." in the .travis.yml) because the current one is valid only in my
fork.

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

---

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

[kwwall]

@b-long as I said, I have no inherent objections regarding using Travis-CI or even incorporating build badges, etc. into our README.md. However, OTOH, I'm not sure it's a good idea to do that until we address the JUnit test failure that happens periodically in the esapi-java-legacy builds. (See issue 352, ESAPI/esapi-java-legacy#352, there). @xeno6696 opened that bug and we've assigned it to @jeremiahjstacey. I'm not sure what the status is, but until we consistently get clean JUnit runs, I'm not sure I see any advantage of putting up build badges that shout to the world "Hey world, look at our mess!". If you think it will motivate people to pitch in and help with trying to fix it, then go for it. I'm just thinking it might have the opposite effect. (The code coverage can wait until a bit later; it's rather abysmal by my standards, but part of that is the fact that unit testing using mock objects is a royal PITA in ESAPI because of all the f'ing singletons. IMO, we need a redesign there. I'm doing that for the JavaEncryptor but I don't plan on touching the other components.)

In the meantime, I had a few additional questions regarding @bkimminich's pull request over on esapi-java-legacy, but otherwise, I think we can pull this off soon.