Circle Ci for Continuous Integration

This article talks about the use of continuous integration with github actions. Does anyone have any experience using Circle Ci for continuous integration on FRC or FTC Robots?

I’m interested in any set up, struggles, experiences, etc. that you may have encountered.

For those who don’t know what continuous integration is, here is a handy dandy article explaining it.

What advantages does Circle CI have over GH Actions?

Anyway, the different CI platforms shouldn’t be that different one from another.

That’s actually the question I’m interested in too, what advantages does it have? I’ve been told by a friend that it’s industry standard. I presume there is some reason for this, but I’m not quite sure what it is.

“Industry standard” is misleading in this case. I’m sure it’s standard in their experience, but in my (relatively short) time in the field, across three companies, I’ve never encountered CircleCI as something a team actually used.

Many, if not most, developers have a limited scope of experience that tends to color what they consider “standard” for tooling. This is equally applicable for highly experienced developers and fresh grads.

This doesn’t necessarily mean it isn’t common, but claiming something is “standard” is a bit of a higher, well, standard, than that.

1 Like

Good to know, thank you!

From your experience, what have teams typically used? What are their pros verse cons?

For an FRC team, the most common thing I’ve seen is nothing.

For an actual company, I’ve seen:

  • Jenkins (at all three places in various forms)
  • GitLab CI (at a startup, my personal favorite to use)
  • GitHub Actions (in a weird, company-neutered form)
  • Drone (do not recommend)
  • Vela (a weird in-house open-sourced thing, also do not recommend, if only because nobody uses it)
  • A weird in-house thing I don’t recall the name of

Philosophically, I think you’re on the right track with anything that will offer you a free tier of pipeline runners in the FRC context.

The reason we chose to highlight Actions in the documentation is because of its tight integration with GitHub. You don’t need to create a separate account to manage pipelines like you need to do with other providers (most teams are already using GitHub to host their source code).

Actions is also becoming really powerful on its own; we recently moved all the WPILib infrastructure from Azure Pipelines to Actions without many issues.

4 Likes

And from the company I work at:

  • Bamboo
  • Before that, test executables that we manually scheduled with cron jobs
1 Like

TBA used to use Travis for our CI/CD. We’ve fully switched over to GitHub Actions (for the main repo at least). Mostly because Travis changed how their free quota works, and GH Actions was tightly integrated with everything else we do on GitHub.

1 Like

For a while, Travis CI was a go-to staple for CI on a lot of GitHub projects. Free and reliable. Unfortunately, since they were acquired, they’ve changed a lot of their free availability, they’ve had an annoying number of outages, and their reputation is kind of dropping quickly.

Which leads me to not necessarily believe that Circle CI is the greatest option for the future. There’s nothing really wrong with it right now, but I just don’t see why it can’t be goofed like Travis was. I definitely wouldn’t call CircleCI “industry standard,” but would hand that title to Jenkins, for better or for worse.

Github Actions is, imo, probably just more reliable for the future given how tightly it integrates with GitHub, which won’t be going away anytime soon. GitLab also has a pretty good CI featureset available, although I don’t know anything about its pricing model.

GH Actions has a bunch of good examples here.

There’s also a growing community for GH Actions plugins, for example, automatic code coverage comments on PRs and many others, which makes a very strong case for GH Actions.

I have some experience with GH Actions, writing both workflows and Actions. I haven’t looked much at other CI platforms, but GH Actions was relatively easy to learn (the docs are very extensive). The ecosystem of community Actions is also very populated- you can find an Action for most use cases.

I agree with @cadandcookies. At JPL, Jenkins is the standard, with Github Actions an interesting up-and-comer.

For the scope of an FRC robot project, I think you’ll find very little difference between the popular CI-as-a-service options available today (e.g. Travis, Circle, GH Actions). The biggest differences you’ll notice are small changes in the YAML configuration. You probably won’t see a notable performance or feature set differences.

  • Drone (do not recommend)
  • Vela (a weird in-house open-sourced thing, also do not recommend, if only because nobody uses it)

No comment :shushing_face:

2 Likes

I’m also working on a slightly more ambitious project with FTC robots. I want to include the WPILIB libraries within gradle.build file. I then want to create a command based architecture that plays nicely with the internals of FTC. Finally, be able to allow our team to create robot libraries that are cross-capable with both FRC and FTC code.

Our school has multiple FTC teams and an FRC team, so I’m looking for a way to make the skills a lot more transferable across programs. Plus, if someone writes something nifty for one robot, I want it available across all.

What do you (or anyone else) feel the learning curve is comparatively across different platforms is?

As I said before, GH Actions has very good and extensive docs, relatively easy to learn from. That’s my experience with GH Actions, I don’t have experience with other platforms so I can’t compare.


On a related note, Gradle is also a really well-documented tool that can be useful to know.

That’s a pretty broad set of challenges, but I think only a very narrow slice is actually relevant to CI.

I want to include the WPILIB libraries within gradle.build file.

This already works! You shouldn’t have to do anything different for CI to make this work.

I then want to create a command based architecture that plays nicely with the internals of FTC. Finally, be able to allow our team to create robot libraries that are cross-capable with both FRC and FTC code.

I’d break this problem down into a few pieces to find the right solution:

  • Where do you want the library code to live? Based on your description, you probably want a separate GitHub repository from your robot code
  • How do you want to package the library? Two options that come to mind:
    • Git submodules (I haven’t had a great experience with them, but might be worth a try)
    • A JAR library is a more common approach for java libraries
  • How do you want to distribute the library?
    • Most popular Java libraries publish using Maven, usually on Maven Central. This can be a bit cumbersome to set up, and is a bit overkill for an FRC team’s library with very few projects consuming it.
    • An easier option is https://jitpack.io/, which is still super easy to consume using Gradle
    • Or, if you are using Git Submodules, you’ll just use Git
  • What is in the library? This is totally up to you :slight_smile:

I don’t personally have much experience with FTC’s libraries, but I do have quite a bit of Android experience so I’m very familiar with the build system that FTC uses. The good news is that both FRC (when using Java) and FTC use Gradle, which makes it pretty easy to share a library between both FRC and FTC.

There’s no easy answer for how to abstract out the more “platform specific” code (e.g. WPIlib) to use on each robot. That’ll probably be your biggest challenge, but you can always start small (e.g. start with utility code that is not dependent on WPIlib) and grow from there.

Note that none of these challenges are specific to CI- You can run Gradle tasks on any CI offering that supports Java.

I instituted using submodules in my team’s codebase this year, and I would recommend it if you are building a library. They can be placed anywhere as a directory in your code and are commit-linked (so no chance of breaking changes for old code).

One issue I’ve encountered is that submodules are not friendly for new programmers, and I had to spend a fair amount of time assisting them. Luckily, VS Code shows the submodules in the version control tab and makes it relatively easy to perform everyday actions without having to teach terminal commands.