Various updates to the operations guide based on PR feedback.

Enabled continuous deployment to efsp-staging from GitHub.

docs/operations_guide/index.md

@@ -74,7 +74,7 @@ You should already have the following:
 You will need to create the app before deploying. Since the fly.toml already exists, you will want to create the app without generating a new one. To create the app, you will need an app name and Fly.io organization. The example commands will reference efsp-staging and the suffolk-lit-lab organization, but you should substitute your own values there. You can use the same app name, but the Fly.io organization will likely be different.
 
 Create the app by running:
-```
+```bash
 fly app create efsp-staging --org suffolk-lit-lab
 ```
 
@@ -84,18 +84,18 @@ New app created: efsp-staging
 ```
 
 Next, configure the app with your .env values. You should have already copied the env.example file as .env.fly and edited the values in it to match your environment.
-```
+```bash
 cat .env.fly | fly secrets import --app efsp-staging --stage
 ```
 
 The stage option is used so that the values are set but the application won't redeploy until the next step.
 
 Now deploy the application by running:
-```
+```bash
 fly deploy --config fly.toml --app efsp-staging
 ```
 You can omit the --app parameter if you're using the app name defined within the fly.toml. You can also omit the --config parameter if you're using the default fly.toml file (as opposed to fly.production.toml, for example). The shortened version in that case would be:
-```
+```bash
 fly deploy
 ```
 
@@ -104,7 +104,7 @@ This step will take some time as Fly.io verifies the configuration and builds th
 If all goes well, your app will be running. Your app should be reached by https on a Fly.io domain name. This value will look something like https://{your-app-name}.fly.dev/ and should be in the output.
 
 Finally, you can set the scale to limit the number of machines created to 1. This step is optional. By default, Fly.io will create 2 machines for high availability. Setting it to 1 makes for a simpler and slightly cheaper setup, but with tradeoffs in performance and availability. To see more in-depth discussion on the tradeoffs, go to the "Scaling Up Fly.io" section. 
-```
+```bash
 fly scale --app efsp-staging count app=1
 ```
 
@@ -116,19 +116,19 @@ fly scale --app efsp-staging count app=1
 The process for manual deployment is very similar to the non-Fly.io steps.
 
 First, update the code on your local to the latest:
-```
+```bash
 git fetch --all
 git pull origin main
 ```
 
 Then run:
+```bash
+fly deploy --config fly.toml
 ```
-fly deploy -c {MY_FLY.TOML}
-```
-Where the {MY_FLY.TOML} value is the fly.toml config file for the environment you are deploying to. If you don't pass a -c option, the default fly.toml file will be used. For EFSP, this is the staging environment. The production config file is fly.production.toml.
+If you are deploying to a different environment, change fly.toml to match the config for the target environment. If you don't pass a `--config` option, the default fly.toml file will be used. For EFSP, this is the staging environment. The production config file is fly.production.toml.
 
 To deploy to production:
-```
+```bash
 fly deploy -c fly.production.toml
 ```
 
@@ -139,7 +139,7 @@ One thing to keep in mind is that the manual deployment builds the Docker image
 If you have forked the EFSP repo, you can set up auto-deploy. Fly.io can be deployed to from a GitHub workflow. For more information on how you would do this, check out:
 https://fly.io/docs/app-guides/continuous-deployment-with-github-actions/
 
-There is an example fly.yml file called fly.yml.example. You can use this as a template for your .github/workflows/fly.yml. 
+You can use the .github/workflows/fly.yml by setting your own FLY_API_TOKEN as a repository secret. Alternatively, you can use it as a template to be customized or you can remove it entirely if you do not want GitHub to run that workflow. 
 
 ## Viewing Logs
 
@@ -214,7 +214,7 @@ You can scale up the # of machines if you reach a point where there is a lot of
 The default Fly config for EFSP will keep just a single machine running at all times. This is important as the code update will only happen if an instance is active when the schedule hits (2:15 am on the machine's clock).
 
 You can set the # of instances to scale to with the following command:
-```
+```bash
 fly scale count app={NUMBER_OF_INSTANCES}
 ```
 where NUMBER_OF_INSTANCES is 1 or higher. For setting it to 1 makes for the simplest setup. You can also leave it with the default 2 to take advantage of Fly.io's rolling deployment strategy. Auto-stop is enabled, so as long as there isn't traffic hitting the machine during the scheduled code update, you will not need to worry about concurrency issues even with multiple machine instances configured.
@@ -253,12 +253,12 @@ To learn more about Grafana, check out:
 Run the fly_create_api_key.sh script to generate a new API key. The generated key will grant API access to your EFSP instance. The API key is printed to the console output and can be copied from there. Best practice is to give each user of your EFSP instance their own API key.
 
 To create an API key for the app specified in your fly.toml, run:
-```
+```bash
 ./fly_create_api_key.sh
 ```
 
 If you want to create a production key, run:
-```
+```bash
 ./fly_create_prod_api_key.sh
 ```
 
@@ -269,33 +269,35 @@ The script uses Fly.io commands to spin up an ephemeral machine that will run th
 ### SSH Console access
 
 Fly.io offers a Fly command that is akin to connecting to a Lightsail instance using SSH. This is handy if you need to troubleshoot the machine. Unlike SSH, you won't need to set up any keypairs. Instead, your Fly.io login will be all that is needed to authenticate you. To SSH to a Fly.io machine, use the following command:
-```
+```bash
 fly ssh console
 ```
 
 ### Setting Secrets/Configuration in Fly.io
 
 You can view the names of the variables that are set with the following command:
+```bash
 fly secrets list
+```
 
 Note that this will not show the values, but it does display both the digest and creation date for the value.
 
 The recommended way to set secrets in Fly.io is to edit them in a .env file. The name .env.fly is assumed for the remainder of these instructions. Note that .env files are excluded from Git. This is important as you should never commit secrets into the repository.
 
 After you edit your .env.fly file and set the appropriate values, you can use the following command to update the Fly.io secrets:
-```
+```bash
 cat .env.fly | fly secrets import
 ```
 
 This will sync the value of every variable in the .env.fly to Fly.io. Note that this will not unset/touch any secrets whose names are not in the .env.fly file.
 
 You can manually set a single secret with the following command:
-```
+```bash
 fly secrets set [name] [value]
 ```
 
 To unset a value, use the following command:
-```
+```bash
 fly secrets unset [name]
 ```
 

fly_create_api_key.sh

@@ -1,3 +1,3 @@
-echo "Who will be using this API key? This value will be stored in the server_name field."
+echo "Who will be using this API key? This value will be stored in the server_name field (so no spaces)."
 read server_name
 fly console --debug --verbose --vm-size shared-cpu-2x --vm-memory 4096 --command "mvn -f /usr/src/app/pom.xml exec:java@LoginDatabase -Dexec.args=\"$server_name true true\""

fly_create_prod_api_key.sh

@@ -1,3 +1,3 @@
-echo "Who will be using this API key? This value will be stored in the server_name field."
+echo "Who will be using this API key? This value will be stored in the server_name field (so no spaces)."
 read server_name
 fly console --config fly.production.toml --debug --verbose --vm-size shared-cpu-2x --vm-memory 4096 --command "mvn -f /usr/src/app/pom.xml exec:java@LoginDatabase -Dexec.args=\"$server_name true true\""