Developer Setup
How to set up your developer environment for Azure Service Operator v2
Key folders of note include:
api
contains all of our supported resources. Much (most!) of this code is generated, but handwritten code is added at various extension points for flexibility.pkg
contains the package genruntime
which is provides infrastructure for our generated resources.internal
contains packages used by our generic controller.The size of each dot reflects the size of the file; the legend in the corner shows the meaning of colour.
Basic use: run task controller:test-integration-envtest
.
The task controller:test-integration-envtest
runs the tests in a record/replay mode by default, so that it does not touch any live Azure resources. (This uses the go-vcr library.) If you change the controller or other code in such a way that the required requests/responses from ARM change, you will need to update the recordings.
To do this, delete the recordings for the failing tests (under {test-dir}/recordings/{test-name}.yml
), and re-run controller:test-integration-envtest
. If the test passes, a new recording will be saved, which you can commit to include with your change. All authentication and subscription information is removed from the recording.
To run the test and produce a new recording you will need to have set the required authentication environment variables for an Azure Service Principal: AZURE_SUBSCRIPTION_ID
, AZURE_TENANT_ID
, AZURE_CLIENT_ID
, and AZURE_CLIENT_SECRET
. This Service Principal will need access to the subscription to create and delete resources.
A few tests also need the TEST_BILLING_ID
variable set to a valid Azure Billing ID when running in record mode. In replay mode this variable is never required. Note that the billing ID is redacted from all recording files so that the resulting file can be replayed by anybody, even somebody who does not know the Billing ID the test was recorded with.
Some Azure resources take longer to provision or delete than the default test timeout of 15m. To change the timeout, set TIMEOUT
to a suitable value when running task. For example, to give your test a 60m timeout, use:
TIMEOUT=60m task controller:test-integration-envtest
If you need to create a new Azure Service Principal, run the following commands:
$ az login
… follow the instructions …
$ az account set --subscription {the subscription ID you would like to use}
Creating a role assignment under the scope of "/subscriptions/{subscription ID you chose}"
…
$ az ad sp create-for-rbac --role contributor --name {the name you would like to use}
{
"appId": "…",
"displayName": "{name you chose}",
"name": "{name you chose}",
"password": "…",
"tenant": "…"
}
The output contains appId
(AZURE_CLIENT_ID
), password
(AZURE_CLIENT_SECRET
), and tenant
(AZURE_TENANT_ID
). Store these somewhere safe as the password cannot be viewed again, only reset. The Service Principal will be created as a “contributor” to your subscription which means it can create and delete resources, so ensure you keep the secrets secure.
If you want to skip all recordings and run all tests directly against live Azure resources, you can use the controller:test-integration-envtest-live
task. This will also require you to set the authentication environment variables, as detailed above.
By default task controller:test-integration-envtest
and its variants run all tests. This is often undesirable as you may just be working on a single feature or test. In order to run a subset of tests, use the TEST_FILTER
:
TEST_FILTER=<test_name_regex> task controller:test-integration-envtest
If you would like to try something out but do not want to write an integration test, you can run the operation locally in a kind cluster.
Before launching kind
, make sure that your shell has the AZURE_SUBSCRIPTION_ID
, AZURE_TENANT_ID
, AZURE_CLIENT_ID
, and AZURE_CLIENT_SECRET
environment variables set. See above for more details about them.
Once you’ve set the environment variables above, run one of the following commands to create a kind
cluster:
task controller:kind-create-with-service-principal
.controller:kind-create-with-podidentity
.You can use kubectl
to interact with the local kind
cluster.
When you’re done with the local cluster, tear it down with task controller:kind-delete
.
Pull requests opened from forks of the azure-service-operator repository will initially have a skipped
Validate Pull Request / integration-tests
check which
will prevent merging even if all other checks pass. Once a maintainer has looked at your PR and determined it is ready they will comment /ok-to-test sha=<sha>
to kick off an integration test pass. If this check passes along with the other checks the PR can be merged.
Full error:
error loading schema from root … open /azure-service-operator/v2/specs/azure-resource-manager-schemas/schemas/2019-04-01/deploymentTemplate.json no such file or directory
This git repo contains submodules. This error occurs when the submodules are missing, possibly because the repo was not cloned with --recurse-submodules
.
To resolve this problem, run git submodule init
and git submodule update
and then try building again.
How to set up your developer environment for Azure Service Operator v2