Developer Setup

This section goes into detail on how to get set up to develop the SDK as well as various development workflow steps that we use here at Vapor IO.

Getting Started

When first getting started with developing the SDK, you will first need to have Go (version 1.9+) installed. To check which version you have, e.g.,

$ go version
go version go1.9.1 darwin/amd64

Then, you will need to get the SDK source either by checking out the repo via git,

$ git clone
$ cd synse-sdk

Or via go get

$ go get -u
$ cd $GOPATH/src/

Now, you should be ready to start developing on the SDK.


To aid in the developer workflow, Makefile targets are provided for common development tasks. To see what targets are provided, see the project Makefile, or run make help out of the project repo root.

$ make help
build           Build the SDK locally
ci              Run CI checks locally (build, test, lint)
clean           Remove temporary files
cover           Run tests and open the coverage report
dep             Ensure and prune dependencies. Do not update existing dependencies.
dep-update      Ensure and prune dependencies. Update existing dependencies.
docs            Build the docs (via Slate)
examples        Build the examples
fmt             Run goimports on all go files
help            Print usage information
lint            Lint project source files
setup           Install the build and development dependencies
test            Run all tests
version         Print the version of the SDK

In general when developing, tests should be run (e.g. make test) and the could should be formatted (make fmt) and linted (make lint). This ensures that the code works and is consistent and readable. Tests should also be added or updated as appropriate (see the Testing section).


All commits and pull requests to the Synse Plugin SDK trigger a build in Circle CI. The CI configuration can be found in the repo’s .circleci/config.yml file. In summary, a build triggered by a commit will:

  • Install dependencies
  • Run linting
  • Check formatting
  • Run tests with coverage reporting (and upload results to CodeCov)
  • Build the example plugins in the examples directory

When a tag is pushed to the repo, CI checks that the tag version matches the SDK version specified in the repo, then generates a changelog and drafts a new release for that version.