In my previous post, Pulse Roadmap Update, I mentioned that we are working on major changes to the Pulse administration UI. I also mentioned these changes were worthy of their own post, so here we are! After an initial evaluation and prototyping period, work on the new administration UI is now in full swing. We’ve still got months of work to go, but the direction has become clear enough for us to communicate.
As I mentioned previously, the main goals of this rewrite are discoverability and efficiency. We want it to be easier for you to find the configuration you’re after, and faster to make changes when required. We’re also dragging the admin UI from it’s humble lightly-scripted beginnings into the brave new world of HTML5 (we might even drop the quaint “AJAX-powered” terminology from our website 😉 ). For example: the new UI makes use of HTML history APIs to finally integrate with the back/forward navigation of the browser.
We’ll be making things more discoverable in two key ways:
- Providing an overview page for each project, which displays a summary of the main configuration in one place (key details from the SCM, recipes, requirements, properties, stages and dependencies). This will allow you to see what the project is about at a glance, without digging into the details.
- Making it easier to find where projects override values set in their template ancestors, as these are usually the key things you want to see and/or change. Currently overrides are marked but can only be found by browsing to their specific location in the configuration tree.
On the efficiency side, we also have multiple changes, some more visible than others:
- Navigating through the template hierarchy will be possible in a consistent way on every configuration page. You’ll be able to navigate to the same configuration in any other project (not just direct ancestors and descendants), where such configuration exists.
- The project and agent trees will be searchable, making it easy to jump straight to the instance you’re after.
- As mentioned above, proper browser history navigation is supported so you can easily jump back and forth.
- Under the covers a lot less data will be transferred between the Pulse master and browser, and the master will do a lot less work. The existing implementation has become heavyweight through multiple iterations and is being replaced with a lighter HTTP-friendly API with more work done on the client.
These are ambitious changes and as such we’ll be launching them in a new major version: Pulse 3.0! The implementation will also lay the groundwork for updates to other parts of the UI, as well as a new config API, although these will be held back for future releases. We prefer to ship sooner and tackle other areas incrementally rather than embark on a full rewrite. As always, while the next major version is in the works, Pulse 2.7 will be actively maintained including minor feature updates where practical.
Now, back to the UI work!
Long time users of our Pulse Continuous Integration Server would know that we don’t believe in posting long-term roadmaps. They just never reflect a changing reality! But we have always been happy to discuss features with customers, including keeping our issue tracker (creaky old version of Jira that it is) completely open for all to see and contribute. In that spirit I’d like to talk a little about where we’re heading with Pulse in the near term, the bit that can be predicted, in a format more digestible than disparate issues.
The next version of Pulse (as yet unnamed), will have updates focused on a few areas:
- Upgrades of underlying libraries including Equinox, Spring, Spring Security, Hibernate, Jetty, Quartz, EhCache and more. If you haven’t seen a lot of visible changes reported recently this is why: these upgrades have occupied the first part of this development cycle. These are truly the most boring of all changes, which we hope you won’t notice directly at all! What you will notice, though, is a payoff of this strong foundation over time.
Major updates to the administration interface. The interface works well enough at the moment but could be improved in a couple of key areas: discoverability and efficiency. Key goals for these updates include:
- Improving the visibility of the most commonly-used configuration via overview pages.
- Making it easier to discover what is overridden (via templating) and where.
- More efficient navigation, especially through the template hierarchy.
- Modernisation to take advantage of HTML 5 (which the current interface predates).
These changes are big enough to warrant a dedicated blog post at a future point.
- Improved visibility of the build environment. When builds fail in curious ways the culprit is often a small difference in the environment. Pulse currently publishes environment information via implicit env.txt artifacts, but these haven’t kept up to date with the variety of options Pulse now gives for specifying build properties.
- Improvements to the Windows experience. In 2.7 work was done to improve Windows service support, but more could be done to streamline the setup process in particular.
As always we will also be working on dozens of smaller improvements and suggestions from our user base, most of which fall under one of:
- UI polish, especially in the reporting interface.
- Increased flexibility of project and build configuration.
- Updated support for modern versions of build tooling.
The Android development tools project has seen big changes over the last year. The original Eclipse ADT development environment was superseded late last year by Android Studio — a new IDE based on Intellij. Under the hood Android Studio also uses a new command line build system based on Gradle, replacing the previous Ant-based system. I’ve been keen to find out how these changes impact the integration of Android test reports with continuous integration servers like Pulse.
- Android JUnit Report is redundant.
- Run on-device Android tests with:
- Collect reports from:
The original Ant-based build system for Android didn’t produce XML test reports for instrumentation tests (i.e. those that run on-device), prompting me to create the Android JUnit Report project. Android JUnit Report produced XML output similar to the Ant JUnit task, making it compatible with most continuous integration servers. The good news is: Android JUnit Report is now redundant. The new Gradle-based build system produces sane XML test reports out of the box. In fact, they’re even more complete than those produced by Android JUnit Report, so should work with even more continuous integration servers.
The only downside is the documentation, which is a little confusing (while there are still documents for the old system about) and not very detailed. With a bit of experimentation and poking around I found how to run on-device (or emulator) tests and where the XML reports were stored. With a default project layout as created by Android Studio:
ASDemo.iml app/ app.iml build.gradle libs/ proguard-rules.pro src/ androidTest/ main/ build.gradle gradle gradle.properties gradlew gradlew.bat local.properties settings.gradle
You get a built-in version of Gradle to use for building your project, launched via gradlew. To see available tasks, run:
$ ./gradlew tasks
(This will download a bunch of dependencies when first run.) Amongst plenty of output, take a look at the Verification Tasks section:
Verification tasks ------------------ check - Runs all checks. connectedAndroidTest - Installs and runs the tests for Debug build on connected devices. connectedCheck - Runs all device checks on currently connected devices. deviceCheck - Runs all device checks using Device Providers and Test Servers. lint - Runs lint on all variants. lintDebug - Runs lint on the Debug build. lintRelease - Runs lint on the Release build. test - Run all unit tests. testDebug - Run unit tests for the Debug build. testRelease - Run unit tests for the Release build.
The main testing target test does not run on-device tests, only unit tests that run locally. For on-device tests you use the connectedAndroidTest task. Try it:
$ ./gradlew connectedAndroidTest ... :app:compileDebugAndroidTestJava :app:preDexDebugAndroidTest :app:dexDebugAndroidTest :app:processDebugAndroidTestJavaRes UP-TO-DATE :app:packageDebugAndroidTest :app:assembleDebugAndroidTest :app:connectedAndroidTest :app:connectedCheck BUILD SUCCESSFUL Total time: 33.372 secs
It’s not obvious, but this produces compatible XML reports under:
with names based on the application module and device. In your continuous integration setup you can just collect all *.xml files in this directory for reporting.
Although the new build system has killed the need for my little Android JUnit Report project, this is a welcome development. Now all Android developers get better test reporting without an external dependency. Perhaps it will even encourage a few more people to use continuous integration servers like Pulse to keep close tabs on their tests!
To all Pulse customers, existing and potential, a bit of news: we’ve applied some long-overdue changes to pricing. Well, not changes so much as clarification! Since the initial release of Pulse we’ve always favoured an up-front pricing policy. We loathe hidden pricing designed to lure you into a lengthy, pushy sales process. So our sales front page has always included pricing information.
However, the pricing on the page didn’t show the full reality. We had three tiers of pricing for 1, 5 and 15 agents, then the option of license 10 packs on top. In practice customers often asked a few questions:
- Can we get a more specific number of agents, e.g. 10?
- Can Pulse handle large numbers of agents, well beyond 15?
- Do discounts apply as the number of agents continues to grow?
In all cases the answer has been yes. We aim for flexibility, and have allowed anyone that asked to purchase a smaller number of agents at a time. Pulse can certainly handle many more than 15 agents: some customers have hundreds in production and we’ve always offered discounts for high numbers.
Thus it is about time we reflected reality in our published prices. From now on there are no defined agent pack sizes: you start with a single agent license for US$900, then add as many additional agents as you need. Agents are priced on a sliding scale so they become progressively cheaper as your installation grows. You can see this clearly on our updated sales page.
What does this mean for existing customers? As a matter of policy: no existing customer will lose out. If you have a deal better than the new published pricing, that deal remains. This may mean you can get more agents free, or a discounted renewal price next time around. For reference: the original single agent license is now US$50 cheaper, and this will translate to a US$25 discount for our existing Pulse Standard License holders. The pricing for 5, 15 and 25 agents remains identical, so many customers will see no change. Larger licenses will be dealt with individually as they come up for renewal.
We think this new pricing better reflects our aim to be both up front and flexible. If you have any questions, please contact sales.
I’m dusting off the blog with a bang, announcing that Pulse 2.7 has gone gold! This release brings a broad range of new features and improvements, including:
- New agent storage management options, including the ability to prevent builds when disk space is low.
- Configuration system performance improvements.
- Live logging performance improvements.
- Xcode command updates, including a new clang output processor.
- A new plugin for integration of XCTest reports.
- More flexibility and feedback for manual triggering.
- New service support, including integration with systemd and upstart.
- Improved support for git 2.x, especially partial clones.
- Support for Subversion 1.8.
- Improved dependency revision handling across multiple SCMs.
- More convenient actions for cancelling builds.
- The ability to run post build hooks on agents.
As always we based these improvements on feedback from our customers, and we thank all those that took the time to let us know their priorities.
Pulse 2.7 packages can de downloaded from the downloads page. If you’re an existing customer with an active support contract then this is a free upgrade. If you’re new to Pulse, we also provide free licenses for evaluation, open source projects and small teams!
At Zutubi we’ve reaped massive benefits over the years from open source. We’ve contributed back bits and pieces in that time — feedback and patches — but always felt we could do more. You may have noticed recent posts here about some of our projects, but we thought they deserved a bit more attention. So we’ve recently launch an new open source section on our website. This is a home for a few small projects of our own that we’ve opened up to the community. We hope you find them useful!
So far we’ve listed three projects:
- android junit report: a custom test runner for Android projects that produces XML test reports in a format similar to the Ant JUnit task.
- zutubi android ant: a collection of Ant tasks that supplement the standard Android build tooling.
- zutubi diff: a Java library for reading, inspecting and applying patch files in unified diff and other formats.
Over time we hope to publish more of our work in this way. You can keep an eye out for new projects on our website and/or follow our organisation on GitHub (or indeed my own GitHub account for Android-specific projects).
And as always: feedback is welcome, so fork away!
Recently I’ve made a few updates to my custom Android test runner, android-junit-report. This runner makes it easy to integrate your Android test results into a continuous integration process by producing de-facto standard JUnit-style XML reports. The latest changes bring the runner up to speed with the latest version of Android and include better documentation. A summary of the updates follows:
- A new home page for the project.
- Within the home page, full documentation.
- Updates to where the reports are written by default. The runner no longer attempts to use the internal storage of the test application, instead it always defaults to the internal storage of the main application (i.e. the one under test).
- Support for a new __external__ token that allows you to place the reports in the external storage area of the application under test (given availability and permission to do so).
- Changes to the token syntax to avoid the need to escape when calling the runner via a shell.
I’d like to acknowledge the help of Sebastian Schuberth and Christopher Orr in fine-tuning some aspects of the runner for this release. The latest runner version, 1.5.8, is available for download now.
In my prior post Android: Attaching Sources to Libraries in Eclipse I noted that ADT version r20 added the ability to link sources to libraries in the Android Dependencies classpath container in Eclipse. Although this was a welcome addition, the method used to link sources is a bit cumbersome: you must create a .properties file alongside each library, and add a property that points to the source jar.
I felt this could be a lot simpler if you are willing to adopt a convention for the location of source jars. Once the convention is established, adding linked sources is as simple as placing the source jar in the expected location. This makes the process as seamless as the Android Dependency container is for adding libraries in the first place.
So I’ve made this possible via a new libproperties task in my zutubi-android-ant project. This task inspects the jars in your libs/ directory, looks for corresponding source jars by naming convention, and adds appropriate .properties files when sources are found. If you’re willing to accept the default convention, where source a source jar for library libs/foo.jar is placed at libs/src/foo-source.jar, then this simple Ant target can be used to generate the required .properties files for you:
<target name="link-sources"> <zaa:libproperties/> </target>
Of course you’ll need to import the zutubi-android-ant tasks into your build file first. If you want to ensure sources are present for all libraries, set the attribute failOnMissingSrc to true and your build will fail if any source jar is missing. You can even establish your own conventions, using a regular expression to match the libraries and a replacement string to generate paths to source jars:
<target name="link-sources"> <-- libs/alib-1.3.jar maps to libs/src/alib-src-1.3.jar --> <zaa:libproperties failOnMissingSrc="true" jarPattern="(.+)-([0-9.]+)\.jar" srcReplacement="src/$1-src-$2.jar"/> </target>
Head over to the new zutubi-android-ant home page for more details, including quick-start instructions to get the tasks installed in your build in minutes.
I’m back into Android development these days, and expect plenty more to come (especially with a Nexus 7 due to arrive today!). So my Android-related projects on GitHub should be getting some much-needed attention. In fact I’ve already added a couple of new tasks to zutubi-android-ant (my extensions to the Android SDK Ant tooling): zaa:lint and zaa:ndkbuild.
The names of the tasks are pretty self-explanatory. The zaa:lint task runs Android Lint, which checks your source for common bugs and problems. If you don’t use lint, do yourself a favour and add it to your builds, it will save you a lot of grief! The zaa:ndkbuild task runs the Android NDK build command, which builds your native code.
Both tasks are simple extensions of the venerable exec task which make it simpler to run the underlying tools regardless of their install location and host operating system. This makes it easier to write machine-independent targets in your build files, which is great for teams working in diverse environments (and, of course, your continuous integration server). The tasks rely on the standard Android Ant properties (i.e. sdk.dir and ndk.dir) to locate the tools.
Because the tasks extend the built-in exec, they support all of the standard configuration. Adding arguments, tweaking the environment, and so on should all be familiar to Ant users. In future I may expand the tasks further to support some more tailored configuration, specific to the tools, but they are already fully-capable and very useful.
You’ll find more documentation in the README over at the zutubi-android-ant repository. Expect more tasks to follow, too!
Since ADT r17, Android projects in Eclipse have had a nice property: all jars in your libs directory have been automatically picked up by Eclipse projects under a magic “Android Dependencies” entry in the build path. Ant builds use the same conventions, so adding a library is as simple as dropping it into the right directory. Unfortunately, though, this magic came with a major limitation: there was no way to attach sources to these libraries (see issue 27940). This led me to duplicate build path entries manually just to get source attachments.
Good news: in the just-released r20 version of ADT, Google have provided a solution to this problem. It’s not well advertised, but if you check out comment 21 on the aforementioned issue, you see that by creating a properties file for each library, you can tell ADT where to find the sources. So, for example, if you have a jar named:
you can create a properties file alongside it named:
Within the properties file you can add a src property set to the relative (or absolute, but that’s version-control-unfriendly) path of the source jar, zip or directory. Say, like me, you put it in the libs/src subdirectory, your properties file might look like:
Once you’ve added the properties file, refresh the project in Eclipse and voilà: the sources will be attached! A similar property named doc is supported for javadoc attachments.
Although this new feature is very welcome, I feel like it could use a bit more fine tuning. The main issue is the need to create a separate properties file for each jar. I keep my source jars in predictable locations, with conventional names, so I should be able to configure the convention once and have everything Just Work from then on. Heck, I’m not sure why there isn’t a default convention, which I could just follow with no further configuration!