Update versions for backup util to match v0.1.10 #4620
Conversation
|
Terraform plan for meta Plan: 0 to add, 1 to change, 0 to destroy.Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
!~ update in-place
Terraform will perform the following actions:
# module.environments["production"].cloudfoundry_space.space will be updated in-place
!~ resource "cloudfoundry_space" "space" {
!~ allow_ssh = true -> false
+ delete_recursive_allowed = false
id = "5593dba8-7023-49a5-bdbe-e809fe23edf9"
name = "production"
# (10 unchanged attributes hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.📝 Plan generated in Pull Request Checks #4170 |
|
Terraform plan for dev Plan: 1 to add, 0 to change, 1 to destroy.Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement
Terraform will perform the following actions:
# module.dev.module.cors.null_resource.cors_header must be replaced
-/+ resource "null_resource" "cors_header" {
!~ id = "*******************" -> (known after apply)
!~ triggers = { # forces replacement
!~ "always_run" = "2025-01-15T20:24:56Z" -> (known after apply)
}
}
Plan: 1 to add, 0 to change, 1 to destroy.📝 Plan generated in Pull Request Checks #4170 |
asteel-gsa
force-pushed
the
update-backup-operation-version
branch
from
cda2e26 to
b9d0f43
Compare
| @@ -70,13 +70,14 @@ jobs: | |||
| cf_command: update-user-provided-service fac-key-service -p '"{\"SAM_API_KEY\":\"${{ secrets.SAM_API_KEY }}\", \"DJANGO_SECRET_LOGIN_KEY\":\"${{ secrets.DJANGO_SECRET_LOGIN_KEY }}\", \"LOGIN_CLIENT_ID\":\"${{ secrets.LOGIN_CLIENT_ID }}\", \"SECRET_KEY\":\"${{ secrets.SECRET_KEY}}\"}"' | |||
|
|
|||
| - name: Backup the database | |||
| if: startsWith(github.ref, 'refs/tags/v1.') | |||
There was a problem hiding this comment.
When we were dealing with the UEI issue, I recall us going back and forth on this line. I've only scratched the surface of github actions. Can you help me understand what our goal is with this, how this line achieves it?
There was a problem hiding this comment.
@gsa-jrothacker It is a conditional clause to exclusively perform a backup operation on releases, as they are tags, with a v1. notation. More information on this specific clause can be found here.
In this pr, the removal of this line actually was, unfortunately, not what y'all were expecting, based on what little I was told, as removing this enabled backup on all environments, rather than prod exclusively.
We don't want to, nor have a necessity, to backup the data in lower environments, and the 2 hour backup cron is substantial enough for us in the lower environments. We do this exclusively in production, as if a breaking change occurs on the "deploy" we want the last copy of the data to have some degree of integrity that if we need to rollback, the pre-deploy backup would be the last known "clean copy" of the data.
There was a problem hiding this comment.
To have disabled the backup before deployment in production, this would have been acceptable
# - name: Backup the database
# if: startsWith(github.ref, 'refs/tags/v1.')
# uses: cloud-gov/cg-cli-tools@main
# with:
# cf_username: ${{ secrets.CF_USERNAME }}
# cf_password: ${{ secrets.CF_PASSWORD }}
# cf_org: gsa-tts-oros-fac
# cf_space: ${{ env.space }}
# command: cf run-task gsa-fac -k 7G -m 3G --name deploy_backup --command "./fac-backup-util.sh v0.1.10 deploy_backup"
asteel-gsa
force-pushed
the
update-backup-operation-version
branch
from
b9d0f43 to
af943db
Compare
|
Follow on PR for #4601
This brings some of the stray versions in sync with the latest backup util version of
v0.1.10and adds back a conditional clause for backups. We don't want to backup every env before deployment, just prod