Opencode plan smoke test

[33Fraise33]

/oc plan --model sol summarize how this repository structures Docker-backed Ansible roles

[33Fraise33]

/oc plan --model sol summarize how this repository structures Docker-backed Ansible roles

[github-actions]

Repository structure

• One service per role: Docker applications live under roles/<service>/. Most existing roles primarily use tasks/main.yml; newer roles such as roles/dawarich/ follow the fuller Galaxy layout with defaults/, tasks/, handlers/, meta/, and README.md.
• Separate Docker host bootstrap: roles/docker/ installs Docker, configures the daemon, creates shared networks from docker.networks, authenticates to Docker Hub, and manages Docker users.
• Declarative container resources: Service roles use community.docker.docker_container, docker_network, and docker_volume. They explicitly define images, networks, mounts, environment variables, restart policies, pull behavior, health checks, and state.
• Networking: Containers commonly join shared services or monitoring networks. Multi-container applications may also create private networks, as Dawarich does for its application, worker, and database.
• Persistence and configuration: Named volumes store application data. Host-side configuration generally lives beneath {{ docker.dir.config }}/<service> and is generated from Jinja templates, then bind-mounted into containers.
• Restart handling: Roles with generated configuration notify handlers that restart the affected container, as demonstrated by Home Assistant.
• Routing and updates: Public applications expose themselves through Traefik container labels rather than directly published ports. WUD labels constrain image updates where version families are pinned.
• Variables and secrets: Shared and host-specific values reside in playbooks/group_vars/ and playbooks/host_vars/; secrets remain encrypted with Ansible Vault. Newer roles keep critical non-secret defaults in defaults/main.yml, use default(...) for optional settings, and assert that required secrets were supplied.
• Complex roles: Larger applications either declare several containers in one task file, such as Immich and Dawarich, or compose component task files with import_tasks, such as Home Assistant.
• Playbook entrypoints: playbooks/<service>.yml select target hosts and compose service dependencies. Roles are commonly tagged individually so operators can deploy a single component.
• Testing: The current Molecule example is molecule/dawarich/. It uses the Docker driver, prepares shared dependencies, runs syntax/convergence/idempotence checks, verifies container running and health state, and cleans up containers, networks, and volumes.

Implementation plan for another Docker-backed role

1. Add roles/<service>/ using the Galaxy layout: defaults, composed tasks, handlers, templates, metadata, and README.
2. Define only critical image/version/port defaults; require secrets through Vault or CI variables and validate them before creating resources.
3. Create required private networks, named volumes, configuration directories, and templates idempotently.
4. Declare every container with community.docker, including image policy, networks, mounts, environment, restart policy, health check, desired state, Traefik labels, and applicable WUD labels.
5. Add restart handlers for template-driven configuration changes.
6. Add a tagged playbooks/<service>.yml entrypoint that includes shared dependencies before the application role.
7. Add a Docker-driver Molecule scenario covering convergence, idempotency, health/configuration assertions, log inspection, an application-level check where possible, and complete cleanup.
8. Validate locally with pre-commit, YAML lint, Ansible lint, syntax checks, and Molecule.

No repository changes are needed for the requested summary.

github run

[33Fraise33]

/oc plan is there a way to make the interaction on GitHub come from opencode instead of GitHub actions?

[github-actions]

Yes. The displayed author is determined by the GitHub credential posting the comment, not by the model running OpenCode. Since the current workflow uses the Actions credential, GitHub shows github-actions.

Recommended implementation plan

1. Register or install an OpenCode GitHub App with an identity such as opencode[bot].
2. In the /oc workflow, obtain an installation token for that app.
3. Pass that token to the OpenCode step and any steps that create issue comments, reviews, labels, branches, or commits.
4. Ensure no later comment step falls back to the default Actions credential.
5. Test with /oc plan and confirm the response is authored by opencode[bot].

Alternatively, use OpenCode’s direct GitHub App integration and remove the repository workflow that handles /oc commands.

Changing the workflow name, job name, commit author, or --model sol setting will not change the GitHub comment author. No Ansible role changes are involved.

github run

[33Fraise33]

/oc plan just report the word "happy"

[opencode-agent]

happy

github run

[33Fraise33]

/oc build add the sentence "Build smoke test." under the "## Local OpenCode" heading in docs/opencode-github.md. Create a pull request; do not make any other changes.

[opencode-agent]

Created PR #8

github run