See https://support.instruqt.com/support/tickets/137 --- we can no longer rely on Instruqt to stop all shell tab processes as you move from one challenge to another, which causes two problems with this track: 1) users sometimes check whilst a Terraform command is still running, which causes subsequent confusion when they run terraform again and get error messages about the state being locked; 2) We tell users to start blast-radius, which may be running when we tell them later on to start it again, and they get port already in use errors.
Where we run terraform commands in a challenge, update the check script to ensure that Terraform is not still running
Fix a bash error which was causing a check for google_compute_subnetwork to fail because we did not quote what could be an empty string
Make some checks a little more robust
In the tf-graph challenge
Make the check for it running more robust
And then if it is running, shut it down so we do not get errors later on
Clarify instructions in the add-virtual-network challenge
See https://support.instruqt.com/support/tickets/137 --- we can no longer rely on Instruqt to stop all shell tab processes as you move from one challenge to another, which causes two problems with this track: 1) users sometimes check whilst a Terraform command is still running, which causes subsequent confusion when they run
terraform
again and get error messages about the state being locked; 2) We tell users to startblast-radius
, which may be running when we tell them later on to start it again, and they get port already in use errors.terraform
commands in a challenge, update the check script to ensure that Terraform is not still runninggoogle_compute_subnetwork
to fail because we did not quote what could be an empty stringtf-graph
challengeadd-virtual-network
challenge