This page describes the steps a Developer should take to fetch Spinnaker’s codebase and get set up to work on it.
Follow the contributing guidelines if you plan to submit your work as a patch to the open source project.
This guide assumes you have access to a machine with a minimum specification of:
This guide has been tested against a machine with these specifications but it’s feasible to develop Spinnaker on different flavors of Linux and with fewer resources, depending on what you’re working on.
The following steps will install Spinnaker’s management tool, Halyard, fetch Spinnaker’s codebase, and perform just enough configuration to get Spinnaker up and running.
Each of these steps will take between 5 and 30 minutes to finish and may require you to do multiple things, such as installing CLI tools or configuring service accounts. A good way to approach this process is to open a step in its own browser tab and then work through it to completion, closing it (and any others you’ve opened in support of it) once it’s done.
hal deploy apply
Halyard creates a directory at
~/dev/spinnaker with the following contents:
.pidfiles, one for each service that is running
scripts directory contains scripts to start and stop each individual service. For
~/dev/spinnaker/scripts/deck-stop.sh will kill the Deck process and
deck.pid file. Running
~/dev/spinnaker/scripts/deck-start.sh will restart Deck
and recreate its
The final step,
hal deploy apply, checks out the git repos for each service and launches
Spinnaker. You can then access the Deck UI by visiting
Halyard will figure out how to individually configure each of Spinnaker’s services based on the settings you give it. You can change Halyard settings with the
halcommand but it’s also worth knowing that Halyard configuration lives in the
~/.haldirectory and that the configuration it generates for each service is placed in the
~/.spinnakerdirectory. This guide won’t go into further detail on this but you can read more about Halyard configuration here .
Once you have a working LocalGit deployment you can begin to make changes to the codebase. After you’ve made edits in the code of a service you can see those changes reflected by restarting the service you’ve modified.
To restart a service call
hal deploy apply --service-names clouddriver, replacing
with whichever service you want to restart. The only service that does not require this kind
of restart is Deck; its webserver watches for file changes and re-compiles the application as
Import the project into IntelliJ:
Project from Existing Sources
If your IntelliJ project becomes broken for any reason then a quick fix is to clean your workspace and delete all files that git doesn’t already know about:
git clean -dnxf -e '*.iml' -e '*.ipr' -e '*.iws'to perform a dry-run.
git clean -dxf -e '*.iml' -e '*.ipr' -e '*.iws'to perform the deletion.
Each Java service can be configured to listen for a debugger. To start the JVM in debug
mode, set the Java system property
The JVM will then listen for a debugger to be attached on a port specific to that service. The service-specific debug ports are as follows:
The JVM will not wait for the debugger to be attached before starting a service; the relevant
JVM arguments can be seen and modified as needed in the service’s