-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add media backup #2220
Add media backup #2220
Conversation
Terraform plan for dev 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.dev.module.clamav.cloudfoundry_app.clamav_api will be updated in-place
~ resource "cloudfoundry_app" "clamav_api" {
~ docker_image = "ghcr.io/gsa-tts/fac/clamav@sha256:01b7d29c95a8c60a3355e1e0d7ea583b4a4f7aab1fe60039b8f5f5791c08c1a3" -> "ghcr.io/gsa-tts/fac/clamav@sha256:4b7513597a0e3cb7e71a1109e6fd63d53476ebf453928b23649176609b3ee0f7"
id = "779bbc51-f78a-4186-90eb-5acb68d7d746"
name = "fac-av-dev"
# (15 unchanged attributes hidden)
# (1 unchanged block hidden)
}
Plan: 0 to add, 1 to change, 0 to destroy.
Warning: Argument is deprecated
with module.dev.module.database.cloudfoundry_service_instance.rds,
on /tmp/terraform-data-dir/modules/dev.database/database/main.tf line 14, in resource "cloudfoundry_service_instance" "rds":
14: recursive_delete = var.recursive_delete
Since CF API v3, recursive delete is always done on the cloudcontroller side.
This will be removed in future releases
(and 2 more similar warnings elsewhere) ✅ Plan applied in Deploy to Development and Management Environment #233 |
Terraform plan for meta No changes. Your infrastructure matches the configuration.
✅ Plan applied in Deploy to Development and Management Environment #233 |
Minimum allowed coverage is Generated by 🐒 cobertura-action against 931f74c |
ae7bf69
to
f99c8c4
Compare
f99c8c4
to
959ce31
Compare
We have a race condition where if the service is unbound too quickly, the backups fail
4f94117
to
d75032b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good, @asteel-gsa. You may want to pull in main
now that the unrelated failing tests have been resolved.
Thank you @danswick and @tadhg-ohiggins |
This reverts commit 8974656.
Adds mediabackup command, and documentation regarding it
Make sure you’ve merged
main
into your branch shortly before creating the PR. (You should also be mergingmain
into your branch regularly during development.)Verify that no Git surgery was necessary, or, if it was necessary at any point, repeat the testing after it’s finished.
Once a PR is merged, keep an eye on it until it’s deployed to dev, and do enough testing on dev to verify that it deployed successfully, the feature works as expected, and the happy path for the broad feature area (such as submission) still works.
PR checklist: reviewers
make docker-clean; make docker-first-run && docker compose up
; then rundocker compose exec web /bin/bash -c "python manage.py test"
The larger the PR, the stricter we should be about these points.