Building and continuous integration

I’m attempting to set up a continuous-integration infrastructure that, among other things:

  • locally (not cloud) cross-compiles an app for the Photon and deploys it to a test Photon
  • automatically performs certain tests over the web against the test Photon running the app
  • compiles parts of the same app for x86_64 and links it with cppunit tests for automated unit testing on the host
  • and eventually even pulls in some cloud functionality into an end-to-end test
  • all tied together in Jenkins, automatically triggered by git commits.


  • has anybody ever done such a thing, and lived to tell the tale? If so, where did you tell the tale and is there a recording that you could share with me? :slight_smile:
  • are there any recommendations for how to go about understanding how the Particle firmware & app build actually works (tons of directories! tons of makefile fragments! app builds defined as a “subroutine” of the firmware build! oh my!) Is there any documentation about how it actually works, rather than just how to invoke it?
  • any recommendations for how to repeatably invoke Particle app builds from Jenkins, and manage firmware version/build/… dependencies?
  • anybody attempted to refactor the app build in a way that it boils down to something more manageable like “gcc -o firmware *.cpp -lparticle-photon” or such?

I just noticed that there’s a rather similar Particle-owned project on Github:

It lists as its first goal: “Provide a useful base for doing continuous integration against Particle Delivery on distributed RPis.”

While we don’t do RPi’s, but Photons, perhaps there are some communalities … any way of collaborating?

Yes, that is all possible.

You’ll want to install the gcc-arm local build for one. This explains how to do the builds, it’s actually straightforward once you get it installed:

The official Makefiles have a facility for building using native gcc that builds OS native apps (like for Windows, Mac, or Linux). The Particle automated tests use both that and actual on-device testing.

I didn’t need all of that, so I build a small subset of firmware includes with stuff like the String class. Then I can run tests using native gcc with valgrind for detecting memory issues on parts of my code during unit testing, which turned out to be really useful.

1 Like

I looked at this, but I’m a little confused where’s up and down in terms of how that entire build is organized. Where do I find the make targets for non-cross-compiled “OS native apps”?

That wouldn’t happen to be an open-source project so I could see what you did?