add instructions on how to run helm unit tests

plus add command to Makefile

Makefile

@@ -194,6 +194,9 @@ test-dev:  ## very similar to `test` command, but allows you to pass arbitray ar
            ## for example, `make test-dev ARGS="--last-failed --pdb"
 	$(call run_backend_tests,$(ARGS))
 
+test-helm:  ## run helm unit tests
+	helm unittest ./helm/oncall
+
 start-celery-beat:  ## start celery beat
 	$(call run_engine_docker_command,celery -A engine beat -l info)
 

dev/README.md

@@ -8,6 +8,7 @@
   - [Django Silk Profiling](#django-silk-profiling)
   - [Running backend services outside Docker](#running-backend-services-outside-docker)
 - [UI E2E Tests](#ui-e2e-tests)
+- [Helm Unit Tests](#helm-unit-tests)
 - [Useful `make` commands](#useful-make-commands)
 - [Setting environment variables](#setting-environment-variables)
 - [Slack application setup](#slack-application-setup)
@@ -205,6 +206,19 @@ cd grafana-plugin
 yarn test:e2e
 ```
 
+## Helm unit tests
+
+To run the `helm` unit tests you will need the following dependencies installed:
+
+- `helm` - [installation instructions](https://helm.sh/docs/intro/install/)
+- `helm-unittest` plugin - [installation instructions](https://github.com/helm-unittest/helm-unittest#install)
+
+Then you can simply run
+
+```bash
+make test-helm
+```
+
 ## Useful `make` commands
 
 > 🚶‍This part was moved to `make help` command. Run it to see all the available commands and their descriptions
@@ -436,24 +450,25 @@ for the common mistakes and best practices
 > DO NOT USE THIS APPROACH FOR NON-NULLABLE FIELDS, IT CAN BREAK THINGS!
 
 1. Remove all usages of the field you want to remove. Make sure the field is not used anywhere, including filtering,
-querying, or explicit field referencing from views, models, forms, serializers, etc.
+   querying, or explicit field referencing from views, models, forms, serializers, etc.
 2. Remove the field from the model definition.
 3. Generate migrations using the following management command:
 
-    ```python
-    python manage.py remove_field <APP_LABEL> <MODEL_NAME> <FIELD_NAME>
-    ```
+   ```python
+   python manage.py remove_field <APP_LABEL> <MODEL_NAME> <FIELD_NAME>
+   ```
 
-    Example: `python manage.py remove_field alerts AlertReceiveChannel restricted_at`
+   Example: `python manage.py remove_field alerts AlertReceiveChannel restricted_at`
+
+   This command will generate two migrations that **MUST BE DEPLOYED IN TWO SEPARATE RELEASES**:
 
-    This command will generate two migrations that **MUST BE DEPLOYED IN TWO SEPARATE RELEASES**:
    - Migration #1 will remove the field from Django's state, but not from the database. Release #1 must include
-   migration #1, and must not include migration #2.
+     migration #1, and must not include migration #2.
    - Migration #2 will remove the field from the database. Stash this migration for use in a future release.
 
 4. Make release #1 (removal of the field + migration #1). Once released and deployed, Django will not be
-aware of this field anymore, but the field will be still present in the database. This allows for a gradual migration,
-where the field is no longer used in new code, but still exists in the database for backward compatibility with old code.
+   aware of this field anymore, but the field will be still present in the database. This allows for a gradual migration,
+   where the field is no longer used in new code, but still exists in the database for backward compatibility with old code.
 5. In any subsequent release, include migration #2 (the one that removes the field from the database).
 6. After releasing and deploying migration #2, the field will be removed both from the database and Django state,
-without backward compatibility issues or downtime 🎉
+   without backward compatibility issues or downtime 🎉