Tuesday, December 13, 2011

Using a Cisco VPN .pcf file with Ubuntu

It's Winter Break and I need to log into the Northwestern VPN, but alas - I've forgotten how to set it up and the Northwestern IT website isn't helpful (we don't support Unix, they say).

Here's how I did it on my Ubuntu 11.04 box:
  1. Download the .pcf file and put it on your Desktop or somewhere.
  2. In terminal, run  sudo apt-get install network-manager-vpnc
  3. Click on the wireless icon on your Gnome panel, and hit Edit Connections
  4. Click the VPN tab, and the 'Import'
  5. Navigate to and select the .pcf file you downloaded earlier.
Et voila, your VPN is set up! :)

If you get a "Connection failed because there were no valid VPN secrets" error, restart, and it should go away by itself.

Tuesday, October 18, 2011

Setting up Hudson to trigger a build with every push to your GitHub repo

Once again, this required a little bit of parsing around the internet. The way to trigger a Hudson build remotely is to send a POST request to this address:

http://<hudson addr>:8080/job/<your-job-name>/build

In order to find the exact POST URL for your Hudson install, navigate to the API page located at <hudson addr>/job/RedTeam/api

Once you have this address, go to your GitHub repository. Select "Admin" in the top menu, and click "Service Hooks". Now select "Post-Receive URL's" and add the address you copied from the Hudson API.

Finally, do a test git push, just to make sure everything works.

Cheers, and I hope this helps folks out there!

Wednesday, October 12, 2011

Headless Jasmine testing with Hudson/Jenkins

There is some literature out there on this, but parsing through it was super-hard, especially for a person like me who's a newb to all these TDD contraptions. For instance, this very excellent link shows you how to set up headless testing, but is vague when it comes to Hudson integration: http://www.build-doctor.com/2010/12/08/javascript-bdd-jasmine/

So assuming you have Jasmine working in your browser, do the following:

1) Go to the Larry Myers' Jasmine-Reporters repo on github, and clone/download the repository you find here: https://github.com/larrymyers/jasmine-reporters

2) Set up a lib folder in the same directory as your SpecRunner.html file (this is the html file that references all the scripts Jasmine will be using for testing; you have one of these if you got Jasmine to run in a browser), with the following files in it:
    * js.jar
    * env.rhino.1.2.js
    * jasmine.console_reporter.js
    * jasmine.junit_reporter.js
    * envjs.bootstrap.js

3) To SpecRunner.html, between the script tags that contain the jasmine reporters, add the JUnitXMLReporter() as follows:
    jasmine.getEnv().addReporter(new jasmine.JUnitXmlReporter());


4) Run the following command from terminal in the same directory as the SpecRunner.html file:
    java -jar lib/js.jar -opt -1 lib/envjs.bootstrap.js SpecRunner.html

Et voila! That should produce the headless testing you needed. Now for the Hudson integration (I'm assuming Jenkins has something similar) do the following:

1) Navigate to <project-name>/Configure.

2) Under the 'Build' heading, click 'Add Build Step', and select 'Execute Shell'.

3) Add the following lines to the textbox that shows up, replacing <dir-containing-specrunner> with the appropriate path. $WORKSPACE is simply a predefined variable that contains the path to the Hudson workspace:
    #!/bin/sh
    cd $WORKSPACE/<dir-containing-specrunner>
    java -jar lib/js.jar -opt -1 lib/envjs.bootstrap.js SpecRunner.html

4) Under the 'Post-Build Actions' heading, select 'Publish JUnit test result report'

5) In the field that appears, enter the following:
    <dir-containing-specrunner>/TEST-*.xml

6) Save, and tell Hudson/Jenkins to do a build. The console output should show your tests being run, and Hudson will do a report on them. :)

Special thanks to Zac Thompson over at Stack Overflow, for helping me with steps 4-5 of the Hudson integration part. See: http://stackoverflow.com/questions/7735149/parsing-junit-xml-with-hudson/7735455#7735455

Hope this is useful!

Sunday, October 9, 2011

Installing a specific Android SDK component from terminal on an Amazon ec2 instance

For his Software Project Management class, Professor Riesbeck is having us setup continuous integration servers. Our eventual projects will be using PhoneGap to create Android/iOS apps (Android in my team's case), so my task this weekend has been to figure out a way to set up a CI server (we chose Hudson) on to an Amazon ec2 instance.

I faced several problems while doing this, and one of the big ones was how to get the android sdk over to the amazon server.

The first thing I tried was to cp the monstrosity that is the sdk over to the ec2 instance. Here's the command I used:

sudo cp -r android-sdk-linux_x86/ ec2-user@*********.compute-1.amazonaws.com:~

However, the transfer was taking forever (and I had a WildCats game to go to), so after about 30 minutes of waiting, I ctrl+C'd it. After some googling around, however, I discovered the wget command. I don't know how I've never stumbled across it before, but it's fantastic! All it does is download stuff of the internet from the command line, which is precisely what I needed. Here's how I used it:

wget http://dl.google.com/android/android-sdk_r13-linux_x86.tgz

Since Amazon's internet is waaay faster than mine, it worked like a charm, and I had the sdk file in a few minutes.

My next problem was that I didn't have any SDK components, and I needed to figure a way to get them without opening the SDK manager GUI, since I was ssh'd into the ec2 instance via terminal. I also wanted to get only the components I needed, because I didn't want to waste a lot of time/bandwidth.
 
Again, some Googling helped me find the android sdk update command. To use it, navigate to <your_sdk_folder>/tools. The file you need is called 'android'. Run ./android help to find out more about it. To learn more about the sdk update command, learn ./android sdk update help.

Here's what I did to get what I wanted:

    ./android list sdk

This will give you a numbered list of packages available for install. It looks something like this:

    Packages available for installation or update: 35
    1- Documentation for Android SDK, API 13, revision 1
    2- SDK Platform Android 3.2, API 13, revision 1
    3- SDK Platform Android 3.1, API 12, revision 3
    4- SDK Platform Android 3.0, API 11, revision 2
    5- SDK Platform Android 2.3.3, API 10, revision 2
    6- SDK Platform Android 2.3.1, API 9, revision 2 (Obsolete)
    7- SDK Platform Android 2.2, API 8, revision 3
    8- SDK Platform Android 2.1, API 7, revision 3
    9- SDK Platform Android 1.6, API 4, revision 3
   10- SDK Platform Android 1.5, API 3, revision 4
   11- Samples for SDK API 13, revision 1
   12- Samples for SDK API 12, revision 1
   13- Samples for SDK API 11, revision 1
   14- Samples for SDK API 10, revision 1
   15- Samples for SDK API 8, revision 1
   16- Samples for SDK API 7, revision 1
   17- Google APIs by Google Inc., Android API 13, revision 1
   18- Google TV by Google Inc., Android API 12, revision 2
   19- Google APIs by Google Inc., Android API 12, revision 1
   20- Google APIs by Google Inc., Android API 11, revision 1
   21- Google APIs by Google Inc., Android API 10, revision 2
   22- Dual Screen APIs by KYOCERA Corporation, Android API 10, revision 1
   23- EDK 1.1 by Sony Ericsson Mobile Communications AB, Android API 10, revision 1
   24- Google APIs by Google Inc., Android API 9, revision 2
   25- Google APIs by Google Inc., Android API 8, revision 2
   26- Dual Screen APIs by KYOCERA Corporation, Android API 8, revision 1
   27- Real3D by LGE, Android API 8, revision 1
   28- GALAXY Tab by Samsung Electronics., Android API 8, revision 1
   29- Google APIs by Google Inc., Android API 7, revision 1
   30- Google APIs by Google Inc., Android API 4, revision 2
   31- Google APIs by Google Inc., Android API 3, revision 3
   32- Android Compatibility package, revision 3
   33- Google Admob Ads Sdk package, revision 3
   34- Google Market Licensing package, revision 1
   35- Google Market Billing package, revision 1


Use the numbers on the list to run the update command. For instance, in my case, I needed the Google API's for Android 2.3.3, which depends on the Android 2.3.3 API. To adapt the update commant, this was:

    ./android update sdk -u -n -t 5,21

The -n argument simulates the install, so you don't actually download a few gigabytes of data accidentally. Run the command without -n to do the actual install.
The -u argument suppressed the user interface, so that the GUI didn't show up.
The -t argument was needed for the filter.