save progress

Makefile

@@ -10,7 +10,7 @@ clean:
 dev:
 	terraform --version
 	cd devenv && mkdir -p state && cd tf && terraform init && terraform apply -auto-approve -var="clustertype=$(CLUSTER_TYPE)"
-	# ./devenv/scripts/deploy_operator.sh
+	./devenv/scripts/deploy_operator.sh
 
 push:
 	echo "$(shell cat devenv/state/registry.txt)/app-routing-operator:$(shell date +%s)" > devenv/state/operator-image-tag.txt
@@ -49,15 +49,3 @@ all-tests:
 	./devenv/scripts/run_private_cluster.sh
 	make clean
 	./devenv/scripts/run_public_cluster.sh
-
-SUBSCRIPTION = ""
-TENANT = ""
-INFRAS = "basic cluster"
-INFRA_FILE = "./infra-config.json"
-
-# e2ev2 is the new e2e test framework. It will completely replace the old e2e test framework soon
-e2ev2-infra:
-	(cd testing/e2e && go run ./main.go infra --subscription=$(SUBSCRIPTION) --tenant=$(TENANT) --names=$(INFRAS) --infra-file=$(INFRA_FILE))
-
-e2ev2-test:
-	(cd testing/e2e && go run ./main.go deploy --infra-file=$(INFRA_FILE))

docs/e2e.md

@@ -7,17 +7,20 @@ E2E is ran automatically on every PR. See [GitHub Runner](#-github-runner).
 
 You can also run E2E locally. See [Local E2E](#-local-e2e).
 
+> [!NOTE]  
+> We recently added a new E2E framework called E2EV2 which this document refers to. The older E2E framework is still in place but will shortly be phased out and removed. E2EV2 is referred to as E2E and is the topic of this doc.
+
 ## Architecture
 
 ### Major Steps
 
-E2e is designed so that every major step is run in a separate GitHub Job. This allows for easy retries and makes it a lot more obvious about which step failed. It also means logs are easier to read.
+E2E is designed so that every major step is run in a separate GitHub Job. This allows for easy retries and makes it a lot more obvious about which step failed. It also means logs are easier to read.
 
 ![e2e-jobs](./e2e-jobs.png)
 
 In the above diagram, each box is a GitHub Job. The arrows show the order in which the jobs are run. Essentially, each infrastructure step is run in parallel, and then the operator is installed and tested on each infrastructure. Infrastructure refers to the AKS cluster and the Azure resources needed for testing.
 
-E2e can be run in the same way locally but typically only one kind of infrastructure will be chosen to be run locally. The separation of each major phase will be the same.
+E2E can be run in the same way locally but typically only one kind of infrastructure will be chosen to be run locally. The separation of each major phase will be the same.
 
 ### Tests
 
@@ -51,7 +54,7 @@ Tests are defined in [/testing/e2e/suites/](../testing/e2e/suites/). Add any new
 
 ## GitHub Runner
 
-todo: will fill in details when I add GitHub workflows to run new e2e
+We use GitHub workflows to run and require passing E2E tests on every PR. [.github/workflows/ok-to-test.yaml](../.github/workflows/ok-to-test.yaml), [.github/workflows/pr-validate.yaml](../.github/workflows/pr-validate.yaml), [.github/workflows/pr-validate-fork.yaml](../.github/workflows/pr-validate-fork.yaml), [.github/workflows/e2ev2.yaml](../.github/workflows/e2ev2.yaml), and [.github/workflows/e2ev2-provision-test.yaml](../.github/workflows/e2ev2-provision-test.yaml) chain together to provide this.
 
 ## Local E2E
 
@@ -60,8 +63,11 @@ Typically, when testing changes locally it's overkill to test changes on a wide
 Run e2e tests with the following commands.
 
 ```bash
+(
+cd testing/e2e
 go run ./main.go infra --subscription=<subscriptionId> --tenant=<tenantId> --names="basic cluster" # provisions the infrastructure and saves it to local config file
 go run ./main.go deploy # deploys the testing job to the cluster and exits based on job status. also uploads logs to local file
+)
 ```
 
-You can replace `basic cluster` with the name of any infrastructure defined in [/testing/e2e/infra/infras.go](../testing/e2e/infra/infras.go). 
+You can replace `basic cluster` with the name of any infrastructure defined in [/testing/e2e/infra/infras.go](../testing/e2e/infra/infras.go). 

docs/validating.md → docs/local-testing.md

@@ -1,25 +1,21 @@
 
-# Validating
+# Local testing 
 
-Before submitting a pull request, you need to ensure that your changes work and don't cause regressions.
+Before submitting a pull request, you need to ensure that your changes work and don't cause regressions. You may also need to inspect what's going on inside the cluster to develop features.
 
 ## Development Environment 
 
 You can easily provision a development environment to test your changes on.
 
-To run a single E2E suite, the user must run the following commands from the root of the project:
 1. `make clean` to clear out any preexisting Terraform state.
 2. `make dev` to deploy all Azure resources necessary to run a full suite, including a Kubernetes cluster that the operator will be deployed to. IMPORTANT: this does not start the add-on. The next step needs to be run for the add-on to be fully deployed with the correct image.
 3. `make push` to build the add-on image according to the user's local state/branch and push it to the add-on deployment. This step can be re-run when changes to the local add-on are made and the user wishes to manually test those changes on a cluster.
-4. `make e2e` to deploy the e2e tester job, which will run the e2e test suite inside the cluster.
 
 By default, the `make dev` command will create an environment with a public cluster using a public DNS Zone. However, two arguments can be specified to change the type of the cluster and/or the zone: `CLUSTER_TYPE` and `DNS_ZONE_TYPE`. For instance, to run a suite with a private cluster and a public zone, a user can run `	make dev CLUSTER_TYPE=private DNS_ZONE_TYPE=public`.
 
-Alternatively, to run a full suite with all possible configuration options, users can simply run `make public-cluster-test` for a public cluster and `make private-cluster-test` for private clusters. To run both, users can run `make all-tests`.
-
 Region can be specified by exporting an env variable before running the `make dev` command. `export TF_VAR_location="East US"` sets the location to East US.
 
-This development environment is useful for manually interacting with App Routing and automated E2E testing.
+This development environment is useful for manually interacting with App Routing during development.
 
 ## E2E