volcano.sh/volcano@v1.9.0/docs/development/development.md (about) 1 This document helps you get started using the Volcano code base. 2 If you follow this guide and find some problem, please take 3 a few minutes to update this file. 4 5 - [Building the code](#building-the-code) 6 - [Building docker images](#building-docker-images) 7 - [Building a specific docker image](#building-a-specific-docker-image) 8 - [Building the Volcano manifests](#building-the-volcano-manifests) 9 - [Cleaning outputs](#cleaning-outputs) 10 - [Running tests](#running-tests) 11 - [Auto-formatting source code](#auto-formatting-source-code) 12 - [Running the verification](#running-the-verification) 13 - [Adding dependencies](#adding-dependencies) 14 - [About testing](#about-testing) 15 16 17 ## Cloning the code 18 19 You will need to clone the main `volcano` repo to `$GOPATH/src/volcano.sh/volcano` for 20 the below commands to work correctly. 21 22 ## Building the code 23 24 To build volcano all components for your host architecture, go to 25 the source root and run: 26 27 ```bash 28 make image_bins 29 ``` 30 the binaries will be generated at .../src/volcano.sh/volcano/_output/bin/linux/amd64/ 31 but if we just make as below 32 33 ```bash 34 make 35 ``` 36 then the binaries would be generated at .../src/volcano.sh/volcano/_output/bin/ 37 38 To build a specific component for your host architecture, go to 39 the source root and run `make <component name>`: 40 41 ```bash 42 make vc-scheduler 43 ``` 44 45 46 ## Building docker images 47 48 Build the containers in your local docker cache: 49 50 ```bash 51 make images 52 ``` 53 54 To build cross-platform images: 55 56 ```bash 57 make images DOCKER_PLATFORMS="linux/amd64,linux/arm64" BUILDX_OUTPUT_TYPE=registry IMAGE_PREFIX=[yourregistry] 58 ``` 59 60 61 ## Building a specific docker image 62 63 If you want to make a local change and test some component, say `vc-controller-manager`, you 64 could do: 65 66 Under volcano.sh/volcano repo 67 68 ```bash 69 pwd 70 ``` 71 The path should be 72 73 ```bash 74 .../src/volcano.sh/volcano 75 ``` 76 77 Set up environment variables HUB and TAG by 78 ```bash 79 export HUB=docker.io/yourrepo 80 export TAG=citadel 81 ``` 82 83 Make some local change of the code, then build `vc-controller-manager` 84 85 ```bash 86 make image.vc-controller-manager 87 ``` 88 89 ## Building the Volcano manifests 90 91 Use the following command to build the deploy yaml files: 92 93 ```bash 94 make generate-yaml 95 ``` 96 97 ## Cleaning outputs 98 99 You can delete any build artifacts with: 100 101 ```bash 102 make clean 103 ``` 104 105 ## Running tests 106 107 ### Running unit tests 108 109 You can run all the available unit tests with: 110 111 ```bash 112 make unit-test 113 ``` 114 115 ### Running e2e tests 116 117 You can run all the available e2e tests with: 118 119 ```bash 120 make vcctl 121 make images 122 make e2e 123 ``` 124 125 If you want to run e2e test in a existing cluster with volcano deployed, run the following: 126 127 ```bash 128 export VC_BIN= need to set vcctl binary path (eg:.../src/volcano.sh/volcano/_output/bin/) 129 KUBECONFIG=${KUBECONFIG} go test ./test/e2e 130 ``` 131 132 ## Auto-formatting source code 133 134 You can automatically format the source code to follow our conventions by going to the 135 top of the repo and entering: 136 137 ```bash 138 ./hack/update-gofmt.sh 139 ``` 140 141 ## Running the verification 142 143 You can run all the verification we require on your local repo by going to the top of the repo and entering: 144 145 ```bash 146 make verify 147 ``` 148 149 ## Adding dependencies 150 151 Volcano uses [Go Modules](https://blog.golang.org/migrating-to-go-modules) to manage its dependencies. 152 If you want to add or update a dependency, running: 153 154 ```bash 155 go get dependency-name@version 156 go mod tidy 157 go mod vendor 158 ``` 159 160 Note: Go's module system, introduced in Go 1.11, provides an official dependency management solution built into the go command. 161 Make sure `GO111MODULE` env is not `off` before using it. 162 163 ## About testing 164 165 Before sending pull requests you should at least make sure your changes have 166 passed both unit and the verification. We only merge pull requests when 167 **all** tests are passing. 168 169 - Unit tests should be fully hermetic 170 - Only access resources in the test binary. 171 - All packages and any significant files require unit tests. 172 - Unit tests are written using the standard Go testing package. 173 - The preferred method of testing multiple scenarios or input is 174 [table driven testing](https://github.com/golang/go/wiki/TableDrivenTests) 175 - Concurrent unit test runs must pass.