So I was connecting PS3 controller to my “Jerry Annihilator” robot tank the other day, and faced the weirdest (of that day) issue: Arduino’s compilation process was reliably failing with “Sketch is too big” error. Can you imagine?
Apparently, Ps3Controller library and its underlying dependency – Bluetooth Low Energy lib – were so big, that they wouldn’t fit into my trusty ESP32 module. However, quick googling suggested that changing partition scheme could help.
Indeed, choosing “Minimal SPIFFS” partition scheme from the “Tools” menu increased program storage space from 1.2MB to 1.9 megs, which is more than enough for my 1.4MB sketch.
So we’re all good, right? No, not entirely. As I mentioned in my previous post, I’m using
arduino-cli to compile the sketch on GitLab server. So naturally partition scheme should be specified there as well. But how? Is that even possible?
TL;DR yes, it’s possible, just add
--build-properties build.partitions=min_spiffs,upload.maximum_size=1966080 parameter to
arduino-cli compile call and magic will happen. But if you want to hear the whole story, stick around for a little bit longer.
Continue reading “Changing ESP32 partition scheme in arduino-cli”
It’s been a while since my last post. But fear not – the blog is not dead! No sir. In fact, I’ve gotten myself into a new project which urges to be written about. The project is called “Jerry Annihilator” and it’s a robot that eventually will bring me a fame, a fortune, and a world domination. Here he is, my ticket to the bright future:
OK, he doesn’t look intimidating now, but first – it’s not the latest revision. And the second – the guy’s just a few months old, give him a break.
So anyway, despite the age, the project is backed by a quite a bit of code, which, though being maintained by GitLab server (basement edition), still has zero unit tests and equal amount of continuous integration. Of cause, I could justify it by me being an ex web-developer, so any CI/CD and unit testing activities in Arduino IDE / ESP32 C++ project environment would be disturbingly unnatural. However, being a consultant now, especially one who also specializes in CI/CD, makes that “ex web-developer” excuse invalid.
So today I try to make the things right and for starters fix the CI part – if code hits the server, it should be built. That should be a good start.
Continue reading “GitLab CI for ESP32 and Arduino”
I’ve been using Gitlab CI for a while now and until certain point it worked really well. We had three build servers (GitLab runners) in the beginning, and when number of teammates or build steps and therefore commits and build jobs increased, I’d just add one more server to handle an extra load and felt that problem was solved.
Not for long. When number of servers climbed to more than ten, it became obvious that simply adding servers one by one doesn’t work anymore. It was both expensive to have all of them running all the time and it still wasn’t enough to handle occasional spikes of commits. Not to mention that during the nights and weekends those servers were doing absolutely nothing.
The whole thing needs to be dynamic and fortunately GitLab CI supports autoscaling out of the box. Documentation is a little bit confusing but in reality it’s very easy to get started. So here’s the plan: let’s try it!
Continue reading “Autoscaling build servers with Gitlab CI”
Last month we finally finished migration from our previous CI/CD system to GitLab CE and that’s something that makes me extremely happy. It’s just so much easier to maintain our CI/CD monster, when repository, build configurations, build results, test results and even that “Approve” button that publishes the build to release repository – when they all are in the same place.
And what I particularly love about GitLab is how simple it is to configure all of that. So simple, that today I’ll show you how to setup fully functional CI/CD for demo project starting from installing GitLab and finishing with successful commit landing at “production” server. So, without further ado, let’s begin.
Continue reading “Easy continuous integration and deployment with GitLab CI”