CI/CD solutions for extension development

Developers
1

Continuing the discussion from another thread…

This is something I wanted to talk about for a while.

I’ve also used Azure Devops for my extensions that includes Ruby C extensions.

I have my source code on GitHub and I only use Azure Devops to build - I don’t host the repo at Azure.

So far I’ve used the UI to configure the CI/CD. The drawback with that, I find, is that when I make changes to my source code that require build changes I need to perform separate changes on Azure. And if I then had to roll back something in my source I’d have to make similar changes on Azure again.

I seems to be it’s be better to have the Azure config stored along with the source code. I’ve yet had time to dive into Azure Devops to see how/if that can be done.

But I have seen that since Microsoft acquired GitHub and introduced CI/CD services it looks to be backed by Azure as well. And the examples indicate that you define the config in YAML. Might be the solution I’m looking for. But I need to compare the differences between CI/CD on Azure Devops directly vs GitHub’s variant of this.

Anyway - the nice thing with these services, including AppVeyor etc, is that they offer basic free hosted tiers. And they include Windows/macOS and linux.

Previously I built my Ruby C extensions manually, which meant copying files across from my main Windows machine and my mac build machine. Now I just need to kick of a CI/CD build and wait a few minutes before I get the RBZ with all files and binaries included. For Vertex Tools and SUbD it’s extra nice as it will also perform the npm tasks that is required to build the webdialog content.

One drawback is that these free hosted machines doesn’t come with SketchUp installed, so you cannot automate running TestUp ruby tests. That’s something I’m still looking into. I’m considering getting a dedicated build machine where I self-host agents for Azure Devops or AppVeyor with a custom config that includes SketchUp and TestUp.

I’ve also had good use of using CI/CD machines as it has detected certain hard coded paths or assumed too much about the host computer. Having the build running on a separate machines makes it easier to pick up issues like that.

I’m curious what your own workflow for building and deploying your SketchUp extensions are? (Mostly for when the extension is more than just zipping up Ruby files.)

1 Like
2

I can’t give specific details, as @merwan did all of the setup, but we use Jenkins on a dedicated server. The Windows project is built in a VM on the server, and the MacOS project is built on a physical Macbook (the Macbook is just a remote executor for Jenkins).

2 Likes
3

One you physically have yourself, or one you rent?

4

One we have, this is our MacOS dev machine.

1 Like
5

The pain in the ass is that SketchUp does not run in a docker container which is the most widespread infrastructure for app testing and deployment. There’s still no stand-alone cross-platform SketchUp API+SDK library without GUI dependencies.
Github seems to have to catch up a little with Gitlab who have CI included for a while (although Github has it maybe in its offerings for businesses). It would be interesting to see what Microsoft does as new Github owner and whether they make CI more easily accessible for opensource targeting the Windows platform.

6

Github has actions since a few weeks. Features • GitHub Actions · GitHub

Haven’t tried them though.

To test sketchup one can run a build agent on a dedicated, in house machine, that is connected to the cicd platform.

Edit: a quick google shows that this is possible on github with self-hosted runners About self-hosted runners - GitHub Docs

7

I don’t recall when GitHub Actions started their ‘beta’, but a lot of repos / users were active before GA.

Anyway, quite a few Ruby repos moved much of their CI to Actions. Not necessarily because it was better than Travis / AppVeyor / CircleCI / etc, but because they allowed essentially unlimited concurrent jobs on free accounts, and they have good integration with the GH UI/API.

But, they currently only ‘natively’ support older versions of Ruby 2.4, 2.5, & 2.6.

2 Likes
8

So a developer (every developer) needs to

  • create a build script to build a virtual machine image with a supported OS, SketchUp and all requirements on it (and Github runner app)
  • build the VM image
  • deploy it on some cloud or local infrastucture that has a dedicated GPU (because the Ruby API does not run headless without SketchUp GUI, and SketchUp GUI does not run without GPU)
  • connect their Github repositories’ actions to this runner

Could we have one common runner that all extension developers can connect to?

9

Easiest would be to use local machines. They have sketchup installed or any build dependency, it’s quick to attach a screen, keyboard and mouse when needed.

For webapps, both frontend and backend it is another story, they run in docker containers anyhow, but desktop apps i think are easiest built on local dedicated machines.