GitHub partners with Arm to revolutionize Internet of Things software development with GitHub Actions

Today, we’re going to take a look at how GitHub is partnering with Arm to revolutionize IoT software development by enabling cloud native development tools directly inside the GitHub ecosystem.

To begin with, let’s take a look at what a typical IoT developers experience looks like today. If we see here on this picture, the developer today on the desktop has the IoT tools that they need installed on there, so things like the compiler, the debugger, and even the tooling to do simulation of the hardware as well, and this is directly running on their physical computer.

When we think about what the CI/CD experience looks like here, today in a lot of environments this is either running directly on physical servers, or some kind of ecosystem that is being managed by the customer. And the challenge with this is that the model in which this is being done today requires the customer, when they’re using proprietary tools for their IoT development, to have licenses in place.

So, the question here is, “how can we help these customers scale horizontally as they try to increase the developer velocity, but find an optimal way to enable them to achieve this?”

Let’s take a look at how GitHub and Arm are partnering together to really revolutionize this experience with building IoT software.

What we can see here in this diagram is that we have a developer whose code is hosted on GitHub today. When the developer pushes a changeset that they want to validate, that changeset is taken and, leveraging GitHub’s automation framework known as GitHub Actions, they’re able to run their CI pipeline

The key difference here is that today, that the Actions runner has all of the Arm Development tools pre-configured and available for use. The idea then is as an organization, I don’t need to worry about:

“How many licenses do I need for these runners?”

“How many max potential horizontal runners can I have?”

The idea here is that I just say I have a workload to run, I run that workload, there can be as many or as little as I need, and then once those workloads are run, the results are presented to the developer.

One of the key things about this partnership is that the billing model for this exercise will be based on the workloads that are run versus a legacy model of “how many licenses do we need for our peak workload?”

And this is really looking to transform the experience from a billing model for customers, but also from a development experience. There’s a huge benefit here that developers don’t need to spend time installing and pre-configuring all these tools, they’re all readily available in the cloud. But all the developer needs to do is focus on the code that they need to develop.

So, let’s take a look at a real example of this. What I’ve done here is I’ve taken the Arm TS Keyword Project which is a rather complicated embedded project, it has about 500 source files. So it’s a good example to showcase the capability here.

What we’re going to do here is, first of all, let’s take a look at the workflow file. So, this is the CI workflow, and as you can see inside this file, that it’s doing all the kind of traditional things that you would expect the CI/CD workflow file to have. It’s installing some tools, it’s going and building the application, and then actually runs the application, validates the results, and lets the developer know if the changes that they made have broken the code. And so, if we take a look at the application here, let’s come into one of the source files and what we’re gonna do is make a very simple change.

What we’ll do here is we’ll insert a little message at the start of the boot up of this board just to let us know that “hey, welcome to this program and check out this little message.”

Now, we can commit this change and we’ll go about creating a pull request for this. So we’ll just hit create pull request here. And what we’ll now see is that the pipeline will kick off in GitHub Actions, and you can see that the GitHub Actions job that’s been kicked off.

And if we jump into the details for this action, what you’ll see here is that it’s now running the full pipeline here. So. installing all the different tools that are required and it will start calling out to the Arm compiler to build the application as we see there. And then in a moment it will finish building the application and will switch to running the test scenarios, and we’ll then see the message that we had typed in in our example.

So. you can see here this will just finish executing here, validating all the test results running on the Arm Virtual Hardware and then once we’re done, we’ll get a positive and negative feedback on how the pipeline has run.

So. if we go back to a pull request now, we can see here for our example that all of the checks are passed–and the really nice thing about this is that these checks have run using the Arm tools on a GitHub Actions runner. We haven’t needed to stand up any special hardware to achieve this. This is all done on the GitHub platform and we can now merge this pull request.

So, that was a really quick demonstration of GitHub and Arm partnering together to really revolutionize the workflow for the typical IoT developer. If you’re interested in learning more about this, go check out http://github.com/Arm-software/AVH-GetStarted, or please reach out to your Arm or GitHub sales representative if you would like to have a deeper discussion on this topic. Thank you.