Skip to content

Commit

Permalink
Merge pull request #9 from alphagov/turn-off-automatic-deployments
Browse files Browse the repository at this point in the history
Turn off automatic deployments
  • Loading branch information
mike29736 authored Dec 22, 2023
2 parents 17fe339 + 3eec3a2 commit 08172c5
Show file tree
Hide file tree
Showing 3 changed files with 10 additions and 6 deletions.
2 changes: 0 additions & 2 deletions .github/workflows/deploy.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,8 +16,6 @@ on:
options:
- production
default: 'production'
release:
types: [released]

jobs:
build-and-publish-image:
Expand Down
6 changes: 4 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand Down
8 changes: 6 additions & 2 deletions docs/deployments.md
Original file line number Diff line number Diff line change
Expand Up @@ -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),
Expand Down

0 comments on commit 08172c5

Please sign in to comment.