-
Notifications
You must be signed in to change notification settings - Fork 1
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 support for persistent data volume #2
Conversation
hellais
commented
Feb 13, 2024
•
edited
Loading
edited
- add basic readme file
- also fix deploy checks when a branch lands on master, since it fails because the comment script doesn't have in it the reference to the open PR number
It fails because the comment script doesn't have in it the reference to the open PR
Terraform Run Output 🤖Format and Style 🖌
|
Pusher | @hellais |
Action | pull_request |
Working Directory | ./tf/environments/production |
Workflow | .github/workflows/check_deploy.yml |
Last updated | Wed, 14 Feb 2024 13:58:54 GMT |
Ansible Run Output 🤖Ansible Playbook Recap 🔍
Ansible playbook output 📖
|
Pusher | @hellais |
Action | pull_request |
Working Directory | ./tf/environments/production |
Workflow | .github/workflows/check_deploy.yml |
Last updated | Wed, 14 Feb 2024 14:00:04 GMT |
Something is funky in the plan. Need to troubleshoot that. |
Ok I have fixed it. What happened, was that debian updated their base OS image and so that was triggering a redeploy of the container. It's a good idea to figure out a pattern for a non destructive upgrade of the base OS, so I did that. The basic idea is that we want to manually or semi-manually create the data volume and then pass in the tag for it as a data attribute to terraform. That way we don't destroy and recreate the data volume thereby loosing data. I have added a comment about that. |
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.
🐳