Tips for Contributing to Spinnaker


#1

Last night, we hosted a Code Night at the Netflix office for Spinnaker. I got some feedback that it would be helpful to start a thread here about some contributing tips for those of you who are interesting in getting started. If you have any other questions/comments/concerns, please voice them here.

Language Choice

In the codebase, you’ll see a lot of Groovy, Java and a little bit of Kotlin. What’s the deal, why do we have 3 JVM languages?

Groovy was the original choice, but its continued use has been deprecated: We try to avoid introducing any new Groovy into the codebase as the dynamic nature of the language, while it provides brevity, tends to cause more pain than its worth through RuntimeExceptions (object casting issues and so-on).

Java is our go-to (currently we do not support Java 9, stuck with 8 for the moment!). We still use Groovy for testing our Java classes via Spock, because it’s convenient and its mocking and assertions are hard to beat.

Kotlin is our newest, and preferred language - what we wish Java was. It gives the compile-time type safety of Java, but makes you as a programmer more productive once you’re up to speed on it. Keiko, Keel and large parts of Orca are written in Kotlin, with more on the way. For testing, we write JUnit5 with Hamkrest in Kotlin, since we’ve found Spek wanting and Spock rather clunky.

So, what to use? Our general rule is, no more than 2 languages in a module’s main tree (e.g. orca-core/src/main has Java and Groovy - so introducing Kotlin is a no-go). Java is the go-to if you’re adding a new class to a module that’s already got Groovy, and is also totally acceptable to choose if you just aren’t comfortable with Kotlin. Groovy is also a no-go: Editing existing classes in Groovy is totally fair game, but we encourage refactoring low-hanging fruit written in Groovy into Java. We encourage the use of Kotlin for new modules and services.

On Similiar Code Behavior

Often times, people are going to be adding new functionality that is similar to pre-existing code. This especially is true when contributing a larger feature like a new cloud provider or stage. I would encourage you to use good judgement while adding code and avoid the urge to blindly copy-and-paste code. Take the time to understand whether or not the way it was done before is the right way or not. In many respects, Spinnaker is a legacy system with code that may have been the way forward 4 years ago, but isn’t anymore. That said, if you’re unsure, it’s always healthy to ask the people responsible for guidance (check git’s history, etc).


#2

Is it OK to use AssertJ instead of Hamcrest? It’s already on the classpath.


#3

Yes it is. Rob Fletcher is working on some AssertJ extensions for Kotlin that will make testing a little bit more of a pleasant experience, based on our early adoption pains. More on that to come, but it’ll wind up being offered via korkTest, or similar, to all services.


#4

Yes, I’m starting to use AssertJ myself as I’m finding Hamkrest a little frustrating. The version we’re pulling in is slightly old (2.6.0) and comes in via the dependency on spring-boot-starter-test in orca-web. Feel free to directly depend on a newer version.

I am planning to work on some Kotlin-specific extensions. I’ve made some good progress but AssertJ’s API is very large and can be quite complex so it’s not quite ready for general use yet.