Git push to flash firmware binary to particle devices

Tutorials
1

if your micro controller are located remotely connected to internet I find it convenient to update firmware using the CI/CD approach. So today I wrote a gitlab-ci that upload firmware binary as soon as you push your code to gitlab remote.

stages:
  - flash

flash_binary:
  image: node:10
  stage: flash
  only:
  - master
  script:
  - apt-get update
  - apt-get -y install curl
  - curl -sL https://deb.nodesource.com/setup_10.x | bash -
  - apt-get install -y nodejs
  - npm install npm
  - npm install -g particle-cli
  - particle -q login -u $PARTICLE_USR -p  $PARTICLE_PWD
  - particle compile photon --target 0.7.0
  - particle flash <name_of_your_particle_device> *.bin

in the above code you see I have PARTICLE_USR and PARTICLE_PWD which I have declared in Gitlab Project > Settings > CI/CD > Variables > [expand] and save the environment variables here. For PARTICLE_PWD i choose secret variable so it is not echoed.

3 Likes
2

thanks, had not seen this before. i guess a next probable step is for you to apply for a job at particle. :slight_smile:

1 Like
3

Not a BFD so far what I have done. there are lot of complexities we can expect on a multi node production setup.

4

yeah, still a clean solution to updates. i’m wondering though when and how you get rid of the .bin file.
would seem to me you would not want more than 1, the recently uploaded, in the directory. so should the now old [just flashed] .bin be moved to an archive or should it be deleted?

5

You may want to add the --saveTo switch to get a distinct file name and keep overwriting that each fresh build and use that same file name for the flash. This way you could keep an archive of binaries by just renaming them (although moving them into an archive directory would be wiser :wink:) but won't flash the wrong one.

6

A more extensible approach would be to avoid logging into the particle cli and only use it for compilation (or use a local toolchain more directly)

Then, use a script to call the Particle Cloud API. This would allow you to actually upload your firmware to a product, unreleased. You could even have it upload the fw and release it to an “alpha” product group for testing once you create the pull request, and then have the firmware version simply released to product default when the PR is closed.

The advantage of the script and API combo is it gives you a lot more flexibility on exactly how you want to control your release process. You can still flash single devices directly, but the particle CLI doesn’t do as much with products as the API. Another advantage is using an API key which is cleaner to manage, especially in the context of a team of people.

2 Likes