Turn off automatic deployments

Automatic deployments are designed with integration in mind and don't
work when production is the target (as is the case for us).

This project requires manual deployment. (And already did require that
before this commit, only it didn't know it yet.)

I've made the bare minimum change to turn this feature off: removing the
`release` trigger from the workflow file. But I have left some of its
supporting code in place. Github workflows setups are mostly identical
across our code bases and occasionally multiple projects receive fixes
and updates to these files simultaneously. I'm optimistically embracing
the idea that the closer we can keep this project's versions of these
files, the more likely it is that we'll receive fixes and updates when
those other projects do.

.github/workflows/deploy.yml

@@ -16,8 +16,6 @@ on:
         options:
         - production
         default: 'production'
-  release:
-    types: [released]
 
 jobs:
   build-and-publish-image:

README.md

@@ -28,9 +28,11 @@ In production, it's run from a scheduled task via its `./collect` executable.
 
 `bundle exec rspec`
 
-### Docs
+### Deployments
 
-[Deployments](docs/deployments.md)
+**This project requires manual deployment.**
+
+[More detailed information about deployments...](docs/deployments.md)
 
 ## Licence
 

docs/deployments.md

@@ -6,14 +6,18 @@ This project only runs in production and only has the one target environment for
 
 For this reason, deployment promotion between environments has no meaning for this project.
 
+## Automatic deployment
+
+**This project requires manual deployment.** (This is because the automatic deployment Github user, `govuk-ci`, doesn't have permission to deploy directly to production since it's designed to deploy to integration and take advantage of deployment promotion.)
+
+As with our other projects, when changes are merged, a new release tag is created. As we're deploying manually, there's technically no need to wait for that to complete, but it does make the action log easier to follow if we deploy releases.
+
 ## How deployment works
 
 Since the project is run from a scheduled task (a K8s `CronJob`), its deployment process differs slightly from that of our apps and some details might prove useful to be aware of if they're not already familiar to you.
 
 Everytime it's run on its schedule, a new Pod will pull a new copy of this project's Docker image from ECR. This differs from the way apps work in that an app's long-running Pods are reprovisioned with the new image once, during the deployment itself.
 
-As with our other projects, when changes are merged, a new release tag is created and in turn, the changes will be deployed automatically.
-
 ## Deploying to integration
 
 Because the scheduled task only usually runs in production, some changes are required to enable a version to be deployed to integration (e.g. for testing),