Finalize changes to gitea workflow.

.gitea/workflows/production/build-deploy-docs.yml

@@ -1,9 +1,9 @@
 on:
   push:
-    # paths:
-    #   - "content/**"
-    #   - "static/**"
-    #   - "templates/**"
+    paths:
+      - "content/**"
+      - "static/**"
+      - "templates/**"
     branches:
       - "main"
 
@@ -64,9 +64,6 @@ jobs:
           push: true
           platforms: linux/amd64
           tags: gitea.raer.me/${{ gitea.repository }}:${{ gitea.ref_name }}
-# It seems that the deploy stage here is the only thing that really needs changing.
-## Further, changing this actually simplifies things. We no longer need this complex things that have been commented out below, instead, we do a much simpler process. The more complex process *should* be managed in a separate repo, anyway, because actually doing work on the machine that this is deployed to should be a more protected process.
-
   job2:
     needs: job1
     name: Connect to deployment host, update, and redeploy docs website.
@@ -105,45 +102,3 @@ jobs:
       -
         name: Run deploy script.
         run: ssh staging
-## The above is far cleaner than below. That means less things have to change in this repo, when things on the deployment host change. In fact, looking over this... it seems that *NO* changes must be made to the actions when things on the deployment host change. As it should be. When the deployment host changes, the scripts related to deployment should change. And because those should be more tightly managed, they should not be spread out in places like this gitea action config.
-
-## Even the deployment key needn't change, due to how variable scopes work in gitea. The lowest level variable takes precedence, so repo variables are always preferred over user/org and system variables.
-
-## Thus, from the developer's pov, the repo must simply have five secrets, three of which are managed by an administrator with root-level access to the deployment host who will configure the repo secrets as needed.
-
-
-
-
-
-
-## Now, stuff like this can be stuck in a shell script that's stored on the deployment host and activated by an SSH key that is restricted to running only the deployment script.
-      #   name: Safety check (ensure dirs exist and repo has been cloned)...
-      #   run: |
-      #     echo "Adding ci dir if it doesn't exist..."
-      #     ssh staging 'bash -c "[ -d ci ] || mkdir ci"'
-      #     echo "Cloning git repo if it isn't already cloned..."
-      #     ssh staging 'cd ci; bash -c "[ -d ${{ gitea.event.repository.name }} ] || git clone https://${{ secrets.PRODUCTION_API_TOKEN }}@gitea.raer.me/${{ gitea.repository }}.git"'
-      # -
-      #   name: Deploy testing script on remote...
-      #   run: |
-      #     ssh staging '\
-      #       cd ci/${{ gitea.event.repository.name }}; \
-      #       git remote remove origin; \
-      #       git remote add origin https://${{ secrets.PRODUCTION_API_TOKEN }}@gitea.raer.me/${{ gitea.repository} }.git; \
-      #       git checkout ${{ gitea.ref_name }}; \
-      #       git reset --hard HEAD; \
-      #       git pull origin ${{ gitea.ref_name }}; \
-      #       git remote remove origin;'
-#       # -
-#
-#
-#         name: Pull new image and redeploy...
-#         run: |
-#           ssh staging '\
-#             echo "${{ secrets.PRODUCTION_REGISTRY_TOKEN }}" | docker login --password-stdin --username ${{ secrets.PRODUCTION_REGISTRY_USERNAME }} gitea.raer.me; \
-#             docker stop blog.raer.me-prod; \
-#             docker rm blog.raer.me-prod; \
-#             docker pull gitea.raer.me/${{ gitea.repository }}:${{ gitea.ref_name }}; \
-#             docker run -d --name blog.raer.me-prod -p ${{ secrets.PRODUCTION_DEPLOYMENT_HOST }}:4020:80 gitea.raer.me/${{ gitea.repository }}:${{ gitea.ref_name }}; \
-#             docker logout gitea.raer.me;'
-