# Troubleshooting

The following table contains solutions to commonly encountered symptoms, in the form of "things that you'll need to remember to do when you change X or do Y".

| When I do this ... | ... remember to do that | Why? |
|-|-|-|
| Make changes to the function build pipeline:<br><ul><li>function spec changes that only affect build</li><li>changes to builder logic</li><li>changes to runtime-specific build logic</li></ul> | Rebuild whichever thing you're using to deploy the function (nuctl / dashboard) | As long as function builds are done locally (note there's a future plan to move function build to a builder service!) - we need the builder we're working with to be aware of any change in logic. If we're deploying with nuctl, it calls `platform.BuildFunction` |
| Make changes that will affect the deployed, running function (or Nuclio's processor binary inside the function container), e.g.:<br><ul><li>health checks</li><li>changes to trigger-specific logic</li><li>changes to function spec that affect runtime (like adding support for Docker volumes)</li><li>changes to a runtime (or a runtime's wrapper)</li></ul> | Rebuild the appropriate `processor` image _depending on the runtime of the function you're testing with_ (might need to rebuild `processor-py`, for instance)<br><br><ul><li>If you changed function spec, you also need to rebuild your deployer (`nuctl` / dashboard)</li></ul><ul><li>In some cases you might need to rebuild the appropriate runtime's `handler-onbuild` image</li></ul> | The processor binary (and in the case of function spec changes, also the deploying tool) both need to be aware of changes to `functionconfig` structure.<br><br>In addition, any change to processor code or runtime-specific code will need to run inside the function container - since function builds will use the existing `nuclio/processor` image to start from (if there is one built). For it to not be out-of-date, we must rebuild it for the processor binary to include our changes |
| Make platform-level changes that also affect kubernetes platform logic:<br><ul><li>extending the `platform.Platform` interface</li><li>writing kube-specific logic</li></ul><br>(assuming you're also testing with a Kubernetes cluster - which you should be doing!) | <ul><li>Rebuild the controller and dashboard images</li><li>Push them to your minikube's Docker hub (by using the script called `push_images.py`)</li><li>Re-apply a development-specific `nuclio.yaml` onto the minikube cluster</li></ul><br>(if you're deploying with nuctl and made changes to kube platform) - rebuild nuctl too | The controller is the entity that runs inside the Kubernetes cluster and reacts to changes made to Nuclio's CRDs - if new logic was added you need its newest version to run in the cluster.<br><br>If the changes affect the deployer too (i.e. new flag which is passed to the kube platform), it also needs to be rebuilt. |
| Use `go test` locally | Give it a package, not a single test file:<br>`go test -v ./pkg/package/... -p 1`<br>(not: `go test -v pkg/package/something_test.go`) | Go test only accepts package names, not individual test files. You may have build errors if you only give it a test file. |