Update comments + docs

.github/workflows/firesim-run-tests.yml

@@ -71,7 +71,8 @@ jobs:
 
   # Note: This doesn't check if the lock file is synced/faithful to the requirements file.
   # This just ensures that both were modified in the same PR (ideally the lock file was regenerated
-  # from the requirements file).
+  # from the requirements file). This job only runs when that condition is not met and
+  # so always fails.
   check-conda-lock-modified:
     name: check-conda-lock-modified
     needs: change-filters

docs/Developer-Docs/Managing-Conda-Lock-File.rst

@@ -8,14 +8,16 @@ Updating Conda Requirements
 ===========================
 
 If developers want to update the requirements file, they should also update the lock file accordingly.
-This is done by two methods:
+There are two different methods:
 
 #. Running ``build-setup.sh --unpinned-deps``. This will update the lock file in place so that it can be committed and will re-setup the FireSim repository.
 #. Manually running ``conda-lock -f <Conda requirements file> -p linux-64 --lockfile <Conda lock file>``
 
-Caveats of the Conda Lock File
-==============================
+Caveats of the Conda Lock File and CI
+=====================================
 
 Unfortunately, so far as we know, there is no way to derive the conda requirements file from the conda lock file.
 Thus, there is no way to verify that a lock file satisfies a set of requirements given by a requirements file.
 It is recommended that anytime you update the requirements file, you update the lock file in the same PR.
+This check is what the ``check-conda-lock-modified`` CI job does.
+It doesn't check that the lock file and requirements file have the same packages and versions, it only checks that both files are modified in the PR.