Repository navigation
OpenCode Setup Improvements #1581
Copy link
Copy link
Open
Labels
Priority: MediumBreaks a feature but has a workaroundBreaks a feature but has a workaround
Description
The current /oc action uses OpenCode GitHub action.
What Problems It Brought (in my experience)
- We're fully restrained by the action's code in regards to how it interacts with OpenCode CLI itself. What parameters it passes to the command, how it structures requests, how creates branches, what context supplies with comments, etc. It acts just a middleman between us and a single CLI command that sends the LLM request.
- It can't differentiate between write and read-only contributors, because the action always checks for write perms under the hood; meaning we can't have the bot answer questions of read-only members, it won't run at all.
- If we want to change bot's identity, the PAT of the other account will require admin-read permission just to check for write perms, per point 2. It's an unnecessary permission, for a single check at the start of the workflow, just due to the poor way the action is coded.
What Benefits It Has
- Hands off pipeline, without manual perm checking, manual context supplementation, manual prompting or other infrastructure work (branch creation, etc).
What I Want to Do (in Steps)
- Refactor it to use OpenCode CLI instead of an action. Done in ci(oc): Refactor the /oc action to CLI #1568.
- Refactor the workflows to use a GitHub app to mint PATs, instead of maintaining 999 different PATs from the separate bot account manually. Done in ci(oc): Refactor workflows to use GitHub app #1626
- Refactor to have a single central dispatcher workflow with comment triggers, routing to a correct workflow based on the command, instead of each command type having its own trigger, firing for each comment 4+ workflows.
- Split
/ocinto two commands: write and read-only. One for maintainers-only to specifically do something, requiring write-perms, the other for everyone to ask. Like/askand/do. Alternately, keep a single command, but automatically elevate into write mode when user perms allow. - Implement more command types (
/fixfor example, to implement the suggested fix to an issue, split/investigatefrom/review, etc.). - Implement advanced bot behavior like in CodeRabbit, Cubic, and other bots. Answering if bot account is pinged, detecting replies to its review comments, resolving threads, editing, or updating head comments if needed, etc.
- Make OpenCode sessions persistent, so they can be resumed if there is a follow-up, instead of starting a new clean one. Possible via
-s/--sessionCLI flag (also--forkexists). Will likely require eitheractions/cache, branch memory or comment memory to store session ID. - Cache OpenCode install in workflows.
- Refactor most scripts from bash to Python or JS. Fully possible to run via actions, without external hosting. Inlined bash is ASS.
- Move prompts into separate MD files (or do the step below). Inlining huge prompts is ASS.
- Make use of OpenCode agents, commands, and skills, to reduce duplication and allow reusability.
- Think about reusable workflows and composite actions for cross-repo use.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Priority: MediumBreaks a feature but has a workaroundBreaks a feature but has a workaround
Activity
[-]OpenCode setup V2[/-][+]OpenCode Setup Improvments[/+][-]OpenCode Setup Improvments[/-][+]OpenCode Setup Improvements[/+]