Dienstag, 12. August 2014

JavaScript CI - The Next Generation

A few months back, I start working with JavaScript. Since I am full convinced about the benefits of the Continuous Integration (CI) methodology, I have start to get familiar with CI in the context of JavaScript.
CI is a methodology which can be adopt in any language, but because I am familiar with CI in the context of Java, i.e. I am working with Java for some years; I will present the tools for CI in Javascript as a parallel for the tools I use in Java.
Of course, it can be that there are better suited tools for the job, but the tools I will present are doing a great job for me and work great.

As a CI Server I will go also with Jenkins which is doing a great job.
In order to have CI we will need to have test that can be run automatically. Mostly for Test in Java I use TestNG as a library, but also in this area is a new player in town Spock. I have start using Spock  in Grails and it's very expressive. You should give it a try ;).
For the JavaScript there are also plenty of  testing framework. I have started with Jasmine and stick with it because it's more then just a testing framework, it's supports also BDD and in some how I find't expressive like Spock.
The second tool it will be  Karma which is a test runner. Sorry if I go to far with the analogy, but I will say that Karma is the equivalent of the Surefire Plugin in Java, i.e. it also executes the test independent from the test library and generates, depending on the configuration, different reports e.g. coverage, unit-test.

After creating the test in Java, mostly we have a helper which, with regard to test, is putting all together: with only one command we have in a moment the tests run and different operating figures generated e.g. tests result, tests coverage, statical analysis etc. In Java, for me, those helper are Ant, Maven and also here as new player Gradle. In terms of JavaScript I will start the introduction with Grunt which is a task runner and in my analogy to Java context, I will say that Grunt is the Ant for JavaScript.

There is one more thing which is missing: a dependencies resolver. For Java Maven is doing a great job. For JavaScript at the moment are some more options, all of them with theirs  pro's and con's. The tools that I use are Bower and Nmp as a part of Node.js.

That was just a short presentation of the tools I recommend you to use when you want to start to develop with joy awesome JavaScript application.

In other words as Spock will say code -"live long and prosper"

Samstag, 29. März 2014

Jenkins Gerrit Trigger and Gerrit 2.8 /RTFM

Yesterday I upgrade my Gerrit from version 2.7 on 2.8. The reason for the upgrade was the improved possibility to search now also in the commit message.
For more details have a look at in the doc.
The update was ok and run without any problems.
The problem started first next day. After pushing changes to gerrit the the jenkins gerrit trigger was doing his job and a build was automatically started on jenkins. Till here everything was good.
First when I start to review some code I just notice that jenkins was not able to make any notification about the status of the change was it "approve" or not.
After a look at the logs I wasn't  smarter :(

  • the Gerrit+Trigger Plugin was doing his work and was sending a message: INFO: Notifying BuildCompleted to gerrit: gerrit approve 438,4 --message 'Build Unstable https://jenkinsserver.my/jenkins/job/myJob/1088/ : UNSTABLE' --verified 0 --code-review -1
  • unfortunately in gerrit nothing was logged :(
After a little research I land where I was at the begin of my update: namely on the the manual and release notes of Gerrit 2.8 and what do you know in the Schema Change which I have read and also done are also some WARNING's some of which I have already read. Unfortunately only some and/or not all paid enough attention :(. The third WARNING  specify clearly that the deprecated approve alias was removed. Here a short cite from the 
WARNING: The deprecated approve alias for the review SSH command has been removed. This is important for all users of the Jenkins Gerrit Trigger Plugin since this plugin by default uses the approve command to vote and comment on changes in Gerrit. If you use the Gerrit Trigger Plugin, go to its global configuration in Jenkins and adapt the Gerrit commands to use the review command instead of the approve command.

So the solution is obvious easy: 
  • login in jenkins and change under
    • Manage Jenkins
      • Gerrit Trigger
        • Gerrit Servers
          • Gerrit Reporting Values
            • Advanced
  • change the Gerrit Verified Commands as specified in the manual: review instead of approve

after update:
once again Did you read the F... Manual?else:
RTFM




Samstag, 15. Februar 2014

Jenkins integration test with ssl



A few days back, after a colleague has push his new integration test, our Jenkins has started be unstable. The test was implying to work with a https URL, on a local area network. The https was using self-signed certificate. Actually no big deal, but in the end that was part of the problem.

The curios part was that the test was passing on the developer machine, only on the CI Server, Jenkins was failing the test. After a closer look the problem was found: the JVM was not accepting the self-signed certificate. This means that we need add our certificate to the keystore of the JVM or to provide the JVM with a keystore that has our self-signed certificate.

to list the cretificate of the JVM do
keytool -list -keystore $JAVA_HOME/jre/lib/security/cacerts

you will be asked for a password. To just list the cacerts, you don't need to introduce any password.
If you want to add a new entry then you will need a password. It's looks like the default password is
changeit
in order to add a new  entry do
keytool -import -alias <your server> -file myServer.crt -keystore $JAVA_HOME/jre/lib/security/cacerts 

If you don't provide last argument -keytrore then it's gone import in users home/.keystore

The last problem that needs to be fix is to make those certificate available at the test time in Jenkins.
For this you can add the following arguments for jenkins:

-Djavax.net.ssl.trustStore=<the path to your keystore>
-Djavax.net.ssl.trustStorePassword=<your keystore password>