- Shell 53.3%
- Just 24.6%
- Jinja 22.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
| .github | ||
| bin | ||
| defaults | ||
| docs | ||
| LICENSES | ||
| meta | ||
| molecule | ||
| tasks | ||
| templates | ||
| .ansible-lint | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| .python-version | ||
| .yamllint.yml | ||
| justfile | ||
| mise.toml | ||
| README.md | ||
| REUSE.toml | ||
postgres-backup-local Ansible role
This is an Ansible role which installs postgres-backup-local to run as a Docker container wrapped in a systemd service.
This role implicitly depends on:
Usage
💡 Refer to this page for details about setting up the service with this role.
Example playbook:
- hosts: servers
roles:
- role: galaxy/com.devture.ansible.role.systemd_docker_base
- role: galaxy/postgres_backup
- role: another_role
Example playbook configuration (group_vars/servers or other):
postgres_backup_identifier: my-postgres-backup
postgres_backup_architecture: amd64
postgres_backup_base_path: "{{ my_base_path }}/postgres-backup"
postgres_backup_container_network: "{{ my_container_container_network }}"
postgres_backup_uid: "{{ my_uid }}"
postgres_backup_gid: "{{ my_gid }}"
postgres_backup_connection_hostname: ""
postgres_backup_connection_username: ""
postgres_backup_connection_password: ""
# If Postgres is running on the same machine, set this to its data path,
# so the Postgres version will be autodetected.
postgres_backup_postgres_data_path: ""
# Alternatively, you'd need to configure `postgres_backup_container_image_to_use`.
postgres_backup_databases_auto: ['first', 'second', 'third']
Development
pre-commit
You can optionally install a Git pre-commit hook (via mise + prek) that runs formatting and linting checks before each commit. See .pre-commit-config.yaml for which hooks are to be executed.
To install the hook, run the just command below:
just prek-install-git-pre-commit-hook
Molecule
This role supports Molecule, an Ansible testing framework designed for developing and testing Ansible collections, playbooks, and roles.
Refer to this page for details about how to utilize it.
Releases
Tags are created on the GitHub workflow by .github/workflows/autotag.yml, which asks bin/compute-next-tag.sh what the commit on main should be released as. The answer comes from the version pinned in defaults/main.yml and from the tags that already exist, so a commit that only touches documentation or CI is not released at all, and any change to the role itself is — without waiting for a dependency bump to carry it along.
bin/test-compute-next-tag.sh exercises that script against throwaway repositories, and runs as a prek hook.