---
created: 2026-04-13
path: Sources/Dev
project: github-deploy-refactor
status: complete
tags:
- pbs
- ansible
- deployment
- github
type: project-plan
updated: 2026-04-25
---

# GitHub Deploy Refactor: pbsdeploybot Machine User Pattern

Replaced the per-repo deploy key approach in the wordpress-install Ansible
project with a centralized machine user (pbsdeploybot) for GitHub SSH access.

## Background

The original github role used individual deploy keys per repository, copied
to the target server at deploy time. This created three problems: key sprawl
across repos, complex three-way clone branching logic, and a separate SSH
key file for every repo that needed cloning.

## What Changed

### Machine user: pbsdeploybot
- GitHub machine user account with read access to all PBS repos
- Single SSH key pair on each target server, configured in `~/.ssh/config`
- Aliased SSH hosts (e.g., `git-real-projects`) route to the correct key
- No deploy keys needed per-repo — pbsdeploybot is added as a collaborator

### Ansible github role (wordpress-install)
- Removed per-repo deploy key copy tasks
- Removed three-way clone branching logic
- Simplified to a single `ansible.builtin.git` task with `accept_hostkey: true`
- Runs as `become_user: "{{ ansible_user }}"` so SSH config is available
- Vars are passed per-invocation (repo_url, repo_dest, repo_version)

### Playbook integration
- github role invoked twice: once for ssh-login-alerter, once for pbs-video-manager
- Both clones run before their dependent application roles
- Tagged so `--tags ssh_login_alert` triggers both the clone and the app role

### Key details
- SSH key: pre-configured on target servers in `~/.ssh/config`
- Host alias pattern avoids bare `github.com` in SSH config
- `repo_version: master` (not main) for repos using that convention
- Defaults in `roles/github/defaults/main.yml`: repo_version=main, owner/group=ansible_user

## Current State

Working in the wordpress-install staging branch. The Ansible playbook run
was blocked by an SSH key issue on the staging server (the key was offered
but rejected). Not yet deployed to production.

## Future Direction

The docker-container project will absorb the github clone logic into the
dockers role as `tasks/common/github.yml`, sitting next to `common/deploy.yml`.
Containers that need a repo clone will import it with container-specific vars
before calling deploy.yml. This eliminates the standalone github role for
container deployments while keeping the same pbsdeploybot auth pattern.