Including ActionBarSherlock as a Git submodule

If you’re using the ActionBarSherlock library in your Android project you can easily stay up to date by including it as git submodule.

$ cd /path/to/project
 
# Initialize the submodule 
$ git submodule add https://github.com/JakeWharton/ActionBarSherlock
 
# Commit your changes
$ git commit -am "Added ActionBarSherlock submodule."
 
# Ignore local changes in the submodule directory
$ git status --ignore-submodules=dirty

To ignore changes to the submodule directory (in case permission or other changes are required) you can add the following to your .gitmodules file:

[submodule "ActionBarSherlock"]
	path = ActionBarSherlock
	url = https://github.com/JakeWharton/ActionBarSherlock
        ignore = dirty

Installing Jenkins on an Ubuntu Amazon EC2 instance

Note: This post was written over four years ago and may no longer work correctly. This post will remain published for posterity.

This tutorial assumes you have already created an Amazon EC2 instance and are able to ssh to it. In our case, we used the Quick Launch Wizard to spin up a 32-bit instance of Ubuntu Server Cloud Guest 11.10 (Oneiric Ocelot).

Once you have a running EC2 instance you’ll need to modify the instance’s security group to open up ports 22, 80 and 443.

The first thing I did was update the EC2 timezone to our local timezone:

$ sudo ln -sf /usr/share/zoneinfo/America/Los_Angeles /etc/localtime

Install any version control systems you might like to use:

$ sudo apt-get install git

Then pretty much just follow the installation instructions from the Jenkins Wiki. I’ve copied the actual steps here for posterity.

Installing Jenkins:

$ wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
$ sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
$ sudo aptitude update
 
# Note this will install the openjdk dependencies automatically!
$ sudo aptitude install jenkins

Setting up an Apache Proxy for port 80 -> 8080:

$ sudo aptitude install apache2
$ sudo a2enmod proxy
$ sudo a2enmod proxy_http
$ sudo a2enmod vhost_alias
$ sudo a2dissite default
$ touch /etc/apache2/sites-available/jenkins

Use your favorite editor to update /etc/apache2/sites-available/jenkins with the following virtual host configuration:

<VirtualHost *:80>
	ServerAdmin webmaster@localhost
	ServerName ci.company.com
	ServerAlias ci
	ProxyRequests Off
	<Proxy *>
		Order deny,allow
		Allow from all
	</Proxy>
	ProxyPreserveHost on
	ProxyPass / http://localhost:8080/
</VirtualHost>

Enable the new jenkins virtual host and restart apache:

$ sudo a2ensite jenkins
$ sudo apache2ctl restart

Jenkins should now be live and accessible from port 80! Now you can begin configuring Jenkins to your liking. I’ll follow-up with a post highlighting our Jenkins configuration. For now, here are the plugins we’ve chosen to install:

  • Green Balls
  • Post build task
  • Instant Messaging Plugin
  • IRC Plugin
  • Rake plugin
  • Git Plugin
  • Github Plugin
  • GitHub API Plugin
  • Github OAuth Plugin

Add mercurial or git changeset id to your Android app

We recently automated the debug builds of our Android app. As a result, we wanted to include the Mercurial changeset id in our app settings, so we could quickly tell what version of the app someone was running.

What we ended up doing was writing the changset id to a custom properties file that was then copied into the raw directory during a build. That properties file could then be read by our PreferencesActivity on runtime.

In order to do this we wrote a custom build.xml file for ant. Simply copy and paste the following into your build.xml file:

    <!-- Require the hg.revision task during pre-build -->
    <target name="-pre-build" depends="hg.revision" />
 
    <!-- Check to see if a mercurial repository exists in the source dir -->
    <available file=".hg" type="dir" property="hg.present" />
 
    <!-- Get the mercurial changeset id for tip -->
    <target name="hg.revision" description="Store mercurial revision in ${repository.version}" if="hg.present">
        <exec executable="hg" outputproperty="hg.revision" failifexecutionfails="false" errorproperty="">
            <arg value="id" />
            <arg value="-i" />
            <arg value="-n" />
            <arg value="-r" />
            <arg value="tip" />
        </exec>
        <echo message="Repository version is ${hg.revision}" />
 
        <!-- Create property file containing mercurial changeset id -->
        <propertyfile file="version.properties" comment="The changset id that this app was built from.">
            <entry key="changeset" value="${hg.revision}" />
        </propertyfile>
 
        <!-- Move property file to app accessible res/raw/ directory -->
        <move file="version.properties" todir="res/raw/" />
    </target>

Essentially this creates an executable task that calls hg id -i -n -r tip in the build workspace. It then adds the result of that command to a propertyfile called version.properties. That file is then copied to the res/raw/ directory.

Our app code is even more straightforward. We simply wrote a function to retrieve the changeset id from the properties file in the raw resources directory. We then take the output of this function and update the preference item.

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        addPreferencesFromResource(R.xml.settings);
 
        // Display app_build in settings as set in the app.version properties file at build time
        Preference build = findPreference("app_build");
        build.setSummary(this.getAppChangsetFromPropertiesFile());
    }
 
    public String getAppChangsetFromPropertiesFile() {
        Resources resources = getResources();
 
        try {
            InputStream rawResource = resources.openRawResource(R.raw.version);
            Properties properties = new Properties();
            properties.load(rawResource);
            return properties.getProperty("changeset");
        } catch (IOException e) {
            Log.e(TAG, "Cannot load app version properties file", e);
        }
 
        return null;
    }

Delete Branch From Remote Git Repo [Assembla]

Update: GitHub has an excellent tutorial on removing sensitive data from your GitHub repository.

We’ve just started using Git and Assembla at our office for version control and ticket tracking. Having never used any sort of version control before, this has been an interesting experience. It’s been a joy to work with so far, but there have definitely been some hurdles to overcome.

One issue we had was how to delete a branch that we had created that we no longer wanted to maintain. We had been playing around and had created several branches that we would not be maintaining. The important thing to remember is that both your local and remote repositories are two separate entities. So the branch must be deleted from all repositories to completely be rid of it.

Remote Branch

$ git push remotename :branchname

The key here being the colon preceding the branch name. The format being:

$ git push <repository> <refspec>

Where <refspec> is written:

<src>:<dst>

Pushing an empty <src> allows you to delete the <dst> ref from the remote repository.

Local Branch

$ git branch -D branchname

I stumbled upon the solution in this Assembla forum post.

We’re also starting to accumulate a fair amount of information on our staff wiki. You’re welcome to take a look if you’re into that sort of thing.