address PR comments

ci/tasks.py

@@ -47,8 +47,7 @@ class Release(BaseModel):
     kustomize_dir: Optional[Path]
 
 
-# TODO: rename this
-class Config(BaseModel):
+class CalitpConfig(BaseModel):
     git_repo: git.Repo
     channel: str  # this is a bit weird, but I want to be able to log this value
     releases: List[Release]
@@ -72,7 +71,7 @@ def parse_calitp_config(c):
     """
     Parses the top-level calitp configuration key via Pydantic
     """
-    c.update({"calitp_config": Config(**c.config._config["calitp"])})
+    c.update({"calitp_config": CalitpConfig(**c.config._config["calitp"])})
 
 
 def get_releases(
@@ -89,7 +88,7 @@ def get_releases(
     return ret
 
 
-# TODO: kubectl diff now supports masking secrets, so we shoulds be able to render secret diffs in PRs
+# TODO: kubectl diff now supports masking secrets, so we should be able to render secret diffs in PRs
 #  see https://github.com/kubernetes/kubernetes/pull/96084
 @task(
     parse_calitp_config,
@@ -215,7 +214,6 @@ def diff(
         print(msg, flush=True)
 
 
-# TODO: we may want to split up channels into separate files so channel is not an argument but a config file
 @task(parse_calitp_config, help=GENERIC_HELP)
 def release(
     c,

docs/infrastructure/README.md

@@ -10,14 +10,14 @@ Run `poetry run invoke -l` to list the available commands, and `poetry run invok
 
 ## CI/CD
 
-All CI/CD automation in this project is executed via GitHub Actions, whose workflow files .
+All CI/CD automation in this project is executed via GitHub Actions, whose workflow files live in the `.github` directory.
 
 ## deploy-airflow.yml
 
 While we're using GCP Composer, "deployment" of Airflow consists of two parts:
 
 1. Calling `gcloud composer environments update ...` to update the Composer environment with new (or specific versions of) packages
-2. Copying the `dags` and `plugins` folders to a GCS bucket that Composer reads
+2. Copying the `dags` and `plugins` folders to a GCS bucket that Composer reads (this is specified in the Composer Environment)
 
 ## build-*.yml workflows
 
@@ -27,7 +27,7 @@ Workflows prefixed with `build-` generally lint, test, and (usually) publish eit
 
 Workflows prefixed with `service-` deal with Kubernetes deployments.
 
-* `service-release-candidate.yml` creates candidate branches, using hologit to bring in external Helm charts and remove irrelevant (i.e. non-infra) code
+* `service-release-candidate.yml` creates candidate branches, using [hologit](https://github.com/JarvusInnovations/hologit) to bring in external Helm charts and remove irrelevant (i.e. non-infra) code
 * `service-release-diff.yml` renders kubectl diffs on PRs targeting release branches
 * `service-release-channel.yml` deploys to a given channel (i.e. environment) on updates to a release branch