$ export GOPATH=$HOME/work
A recent Go distribution (>=1.8)
You should be able to develop Minishift on 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
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 Dep for dependency management.
Before you can use Dep you need to download and install it from GitHub:
$ go get github.com/golang/dep/cmd/dep
This will install the
dep binary into $GOPATH/bin.
Make sure to use Dep version 0.3.2 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 Dep. Alternatively, you can run the Dep command directly.
$ dep ensure -v
If your work requires a change to the dependencies, you need to update the Dep configuration.
Edit Gopkg.toml to change the dependencies as needed.
Delete Gopkg.lock and re-create the vendor directory by running
Dep will recognize that there is no lock file and recalculate the required dependencies.
Check-in the updated Gopkg.toml and Gopkg.lock files.
Test that everything still compiles with the new lock file in place by running
make clean && make.
The Dep cache located under $GOPATH/pkg/dep.
If you see any Dep 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 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 sets of test cases. These test cases are known as features in Gherkin terminology. Features are located in the test/integration/features directory. Features for Minishift follow these basic concepts:
Features which follow a happy path of user. For example, basic.feature or coolstore.feature.
Features which focuses on specific fields of Minishift functionality or individual commands. For example, proxy.feature or cmd-version.feature.
By default, tests are run against the binary created by
make build ($GOPATH/bin/minishift).
To run the basic test, use the following command:
$ make integration
To run all of the tests, use the following command:
$ make integration_all
There is also a
The default targets
integration_all can be further customized using several parameters to provide more flexibility.
MINISHIFT_BINARY parameter can be used to run integration tests against a
minishift binary located in a different directory:
$ make integration MINISHIFT_BINARY=<path-to-custom-binary>
TIMEOUT parameter can be used to override the default timeout of
To run all the tests with a timeout of
7200s, use the following command:
$ make integration_all TIMEOUT=7200s
RUN_BEFORE_FEATURE parameter specifies Minishift commands to be run before each feature.
This provides the ability to run integration tests against a Minishift instance which is not in its default state.
When multiple commands are specified, they must be delimited by a semicolon.
For example, tests can be run against a stopped Minishift instance with the image caching option turned on by running the following:
$ make integration_all RUN_BEFORE_FEATURE="start; stop; config set image-caching true"
The majority of Minishift integration tests pass command line arguments directly to the
oc binaries via Go’s
However, some integration tests first start persistent instance of the shell to pass commands into later, for example:
When user starts shell instance on host machine.
Due to persistency of the shell instance all changes done in it will be present until its closure, for example, changed environmental variables.
This allows testing of commands which are dependent on the shell they are being executed in.
The steps using this approach have the
shell keyword in their definition, for example:
When executing "minishift oc-env" in host shell succeeds.
TEST_WITH_SPECIFIED_SHELL is an optional parameter.
If nothing is passed with
TEST_WITH_SPECIFIED_SHELL, then the shell type is automatically determined.
By default, the shell will be PowerShell on Windows, Bash on macOS and Linux.
TEST_WITH_SPECIFIED_SHELL parameter can be used to run the tests with different shells.
To run the tests using the Windows Command Prompt, for example, run
make integration_all TEST_WITH_SPECIFIED_SHELL=cmd.
TEST_WITH_SPECIFIED_SHELL parameter supports the
GODOG_OPTS parameter specifies additional arguments for the Godog runner.
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 set the format to
progress instead of the default
true to stop integration tests on failure.
true to disable ANSI colorization of Godog’s output.
true to print all available step definitions.
Passing any value via
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"
Multiple values for a
The integration test logs its progress directly into a console. This information is often enough to find and debug the reason for a failure.
However, for cases which require further investigation, the integration test also logs more detailed progress into a log file. This file is located at $GOPATH/github.com/minishift/minishift/out/test-results/integration_YYYY-MM-DD_HH:MM:SS.log.
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
You can also check for common coding mistakes by using:
$ make vet
make fmtcheck, failures in
make vet will fail the CI builds.
Each commit message must meet two requirements:
the commit subject is strictly less than 90 characters (GitHub ellipsis length).
the commit subject matches the format
Issue #[0-9]+ .*, meaning each commit must reference an issue.
The Makefile contains a
validate_commits target which can be used to verify these requirements:
Currently, only Circle CI validates the commit message as part of the CI build.
$ make validate_commits