$ export GOPATH=$HOME/work
A recent Go distribution (>1.7)
|You should be able to develop Minishift on any operating system, such as GNU/Linux, macOS or Windows. The Windows operating system might require additional steps or have some limitations.|
We highly recommend to setup a default Go workspace. Even though it might require an adjustment in your work processes, the goal is to have a single workspace for all Go development.
Create the following directories in the base directory you want to use, such as $HOME/work:
Contains executable commands
Contains package objects
Contains Go source files
Add the path of the root workspace directory to the
GOPATH environment variable.
$ export GOPATH=$HOME/work
Add the workspace bin directory to the
PATH environment variable:
$ export PATH=$PATH:$GOPATH/bin
On Windows operating systems, you use the UI or use
Get the Minishift sources from GitHub:
$ cd $GOPATH/src $ git clone https://github.com/minishift/minishift.git github.com/minishift/minishift
You can use any editor you want. However, most of the core maintainers of Minishift use IntelliJ IDEA with the latest Go plug-in. This IDE indexes your whole workspace and allows for easy navigation of the sources, and also integrates with the Go debugger Delve.
For instructions on setting up IDEA, see Setting up Go on IntelliJ.
Minishift uses Glide for dependency management.
Before you can use Glide you need to download and install it from GitHub:
$ go get github.com/Masterminds/glide
This will install the glide binary into $GOPATH/bin. Make sure to use Glide version 0.12.3 or later.
After a clean checkout or after a
make clean, there won’t be a vendor directory containing the needed Minishift dependencies.
To install the dependencies, you can run the following command:
$ make vendor
This command calls and runs Glide. Alternatively, you can run the Glide command directly.
$ glide install -v
If your work requires a change to the dependencies, you need to update the Glide configuration.
Edit glide.yaml to change the dependencies as needed.
Delete glide.lock and re-create the vendor directory by running
Glide will recognize that there is no lock file and recalculate the required dependencies.
Check-in the updated glide.yaml and glide.lock files.
Test that everything still compiles with the new lock file in place by running
make clean && make.
In some cases the Glide cache located under ~/.glide/cache can get corrupted.
If you seeing Glide errors during
Run the following command to create a platform-specific binary and copy it to $GOPATH/bin.
Start the OpenShift cluster with your built minishift binary:
$ minishift start
This command will run Minishift from $GOPATH/bin/minishift, if you set up your Go workspace as described in the Creating the Go workspace section.
You can also execute the binaries directly from the out directory of the checkout. Depending on your operating system, the binary is in one of the following directories:
For more Minishift commands and flags, see the Minishift command reference documentation.
Unit tests run on Travis before the code is merged. To run tests during the development cycle:
$ make test
To run specific tests, use one of the following methods:
Run all tests on a single package.
# Eg: go test -v ./cmd/minikube/cmd $ go test -v <relative path of package>
Run a single test on a single package.
$ go test -v <relative path of package> -run <Testcase Name>
Run tests that match a pattern.
$go test -v <relative path of package> -run "Test<Regex pattern to match tests>"
For more information about test options, run the
go test --help command and review the documentation.
Integration tests utilize Godog, which uses Gherkin (Cucumber) to define test cases.
The test cases are defined in test/integration/features.
By default, the tests are executed against the binary created by
make build, that is $GOPATH/bin/minishift.
To run the tests, run:
$ make integration
To run integration tests against a Minishift binary in a different location you can use the
$ make integration MINISHIFT_BINARY=<path-to-custom-binary>
Additional properties for Godog runner can be specified with
The following options are available:
tags to ensure that scenarios and features containing at least one of the selected tags are executed.
paths to define paths to different feature files or folders containing feature files.
This can be used to run feature files outside of the test/integration/features folder.
format to change the format of Godog’s output.
For example, you can use
pretty format instead of the native
stop-on-failure to true to stop integration tests on failure.
no-colors to true to disable ansi colors of Godog’s output.
definitions to true to print all available step definitions.
For example, to run integration tests on two specific feature files using only
@openshift tags and without ansi colors, the following command can be used:
$ make integration GODOG_OPTS="-paths ~/tests/custom.feature,~/my.feature -tags basic,openshift -no-colors true"
When multiple values are used for options in
Minishift adheres to the Go formatting guidelines. Code with incorrect formatting will fail the CI builds. You can check whether any of your files violate the guidelines with the following command:
$ make fmtcheck
You can correct the formatting errors yourself or instruct the violations to be corrected automatically with the following command:
$ make fmt