For the past two years, I’ve been using my own self-hosted ARM64 infrastructure to create a Cloud Native Buildpack for Java that works on ARM64. I started with a cluster of Raspberry Pi 4 devices. After ramping up with “spring-native” I switched to a free-tier ARM64 VM in Oracle Cloud. While this setup worked well, I realized that I could streamline my workflow, and perhaps, get my work moved up to Paketo if I used a modern, and accessible, CI/CD platform.
After some research, I decided to try out CircleCI, since it offered ARM64 workflow support. Although I have been a fan of CircleCI for some time, this was my first impression with authoring workflows on CircleCI.
The process of setting up my account and migrating my GitHub actions was surprisingly easy. I provided CircleCI with access to my public GitHub repositories, and started with a “hello world” template that worked right out of the gate.
orbs:
go: circleci/[email protected]
Orbs
From there, I consulted the CircleCI documentation on using ARM, and made some simple edits to the template. The biggest takeaway for me was that CircleCI “orbs” map to GitHub “actions”, which made the transition even smoother.
machine: ubuntu-2004:latest
image: ubuntu-2004:latest
resource_class: arm.medium
- run: echo "Hello, Arm!"
I live-streamed the process of converting my existing workflows to a CircleCI workflows, and encountered a few minor issues along the way. However, these were quickly resolved, and I was able to release everything from my paketo-arm64 repository without using any self-hosted infrastructure!
Overall, I’m thrilled with my first impression of authoring workflows on CircleCI. If I had made the jump sooner, I could have saved myself a lot of headaches. I highly recommend CircleCI to anyone looking for a modern, streamlined CI/CD platform that supports ARM64 workflows.
Watch:
Update 2023-02-27:
I have successfully terraform destroyed the Oracle OCI ARM64 infrastructure that was being used as a self-hosted runner.