anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 02:36:57 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Feature request: Forgejo / Gitea actions support #1274

New Issue
Open
opened 2026-02-16 17:30:15 -05:00 by yindo · 13 comments
yindo commented 2026-02-16 17:30:15 -05:00
Owner
Copy Link
Copy Source

Originally created by @justyns on GitHub (Aug 12, 2025).

Originally assigned to: @fwang on GitHub.

Similar to the github support mentioned on https://opencode.ai/docs/github/, it would be nice if there was also support for forgejo/gitea actions. They are somewhat compatible with github actions, but I'm assuming opencode itself would need custom logic for using the forgejo api for comments/prs/etc instead of github's.

Ref:

Originally created by @justyns on GitHub (Aug 12, 2025). Originally assigned to: @fwang on GitHub. Similar to the github support mentioned on https://opencode.ai/docs/github/, it would be nice if there was also support for forgejo/gitea actions. They are somewhat compatible with github actions, but I'm assuming opencode itself would need custom logic for using the forgejo api for comments/prs/etc instead of github's. Ref: - https://forgejo.org/docs/latest/user/actions/github-actions/
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 27, 2025):

[automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!

@rekram1-node commented on GitHub (Dec 27, 2025): [automated] Closing due to 90+ days of inactivity. Feel free to reopen if you still need this!
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@cweagans commented on GitHub (Dec 29, 2025):

Very very interested in Gitea support. Not my issue, so I can't reopen, but I'd really like to see this.

@cweagans commented on GitHub (Dec 29, 2025): Very very interested in Gitea support. Not my issue, so I can't reopen, but I'd really like to see this.
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@0x7C2f commented on GitHub (Jan 2, 2026):

Bumping for interest! Currently running ForgeJo.

@0x7C2f commented on GitHub (Jan 2, 2026): Bumping for interest! Currently running ForgeJo.
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@janmaroto commented on GitHub (Jan 12, 2026):

Really interested on seeing this on Forgejo.

@janmaroto commented on GitHub (Jan 12, 2026): Really interested on seeing this on Forgejo.
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@ghost commented on GitHub (Jan 18, 2026):

This would be a great feature (Gitea)!

@ghost commented on GitHub (Jan 18, 2026): This would be a great feature (Gitea)!
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@ccsert commented on GitHub (Jan 18, 2026):

Currently, I have implemented some features and verified them in a private environment. Below is the repository link:
https://github.com/ccsert/opencode/tree/feat/gitea-support

For specific usage, please refer to:
https://github.com/ccsert/opencode/blob/feat/gitea-support/gitea/README.md

Pull Request (PR) link:
https://github.com/anomalyco/opencode/pull/9345

The current content has not yet been merged through the PR. If needed, you can manually modify the actions to use the packaged files I prepared.
Replace:

run: ~/.bun/bin/bun install -g opencode-ai@latest

With:

run: ~/.bun/bin/bun install -g @ccsert/opencode-linux-x64
@ccsert commented on GitHub (Jan 18, 2026): Currently, I have implemented some features and verified them in a private environment. Below is the repository link: [https://github.com/ccsert/opencode/tree/feat/gitea-support](https://github.com/ccsert/opencode/tree/feat/gitea-support) For specific usage, please refer to: [https://github.com/ccsert/opencode/blob/feat/gitea-support/gitea/README.md](https://github.com/ccsert/opencode/blob/feat/gitea-support/gitea/README.md) Pull Request (PR) link: [https://github.com/anomalyco/opencode/pull/9345](https://github.com/anomalyco/opencode/pull/9345) The current content has not yet been merged through the PR. If needed, you can manually modify the actions to use the packaged files I prepared. Replace: ``` run: ~/.bun/bin/bun install -g opencode-ai@latest ``` With: ``` run: ~/.bun/bin/bun install -g @ccsert/opencode-linux-x64 ```
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@ccsert commented on GitHub (Jan 20, 2026):

Hi everyone,

I've noticed that the opencode repository has quite a few long-standing open pull requests. This might be due to limited maintainer bandwidth or other reasons.

Currently, any customization or feature enhancement requires going through the full PR → review → merge cycle, which can be slow and inflexible—especially when we want to add custom functionality (e.g., tailored CI workflows, enhanced code review automation, etc.). The existing contribution model makes rapid iteration challenging.

This leads me to wonder: Would it make sense to create a separate project that builds on opencode's extensibility, but is specifically designed to integrate with Gitea’s ecosystem? For example, such a project could:

  • Support automated code reviews for Gitea pull requests;
  • Integrate static analysis tools like Semgrep (similar to how GitHub Copilot leverages CodeQL);
  • Leverage Gitea’s tooling (e.g., MCP or other APIs) to enable richer, more customizable CI/CD pipelines.

This approach would allow us to retain the core strengths of opencode while enabling faster, community-driven innovation without being blocked by upstream merge constraints.

I’d love to hear your thoughts:

  • Are others facing similar limitations?
  • Has anyone already explored something like this?
  • Do you have suggestions for a better architecture or integration strategy?
@ccsert commented on GitHub (Jan 20, 2026): Hi everyone, I've noticed that the opencode repository has quite a few long-standing open pull requests. This might be due to limited maintainer bandwidth or other reasons. Currently, any customization or feature enhancement requires going through the full PR → review → merge cycle, which can be slow and inflexible—especially when we want to add custom functionality (e.g., tailored CI workflows, enhanced code review automation, etc.). The existing contribution model makes rapid iteration challenging. This leads me to wonder: Would it make sense to create a separate project that builds on opencode's extensibility, but is specifically designed to integrate with Gitea’s ecosystem? For example, such a project could: - Support automated code reviews for Gitea pull requests; - Integrate static analysis tools like [Semgrep](https://github.com/semgrep/semgrep) (similar to how GitHub Copilot leverages CodeQL); - Leverage Gitea’s tooling (e.g., MCP or other APIs) to enable richer, more customizable CI/CD pipelines. This approach would allow us to retain the core strengths of opencode while enabling faster, community-driven innovation without being blocked by upstream merge constraints. I’d love to hear your thoughts: - Are others facing similar limitations? - Has anyone already explored something like this? - Do you have suggestions for a better architecture or integration strategy?
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@ccsert commented on GitHub (Jan 20, 2026):

Hi everyone,

I've noticed that the opencode repository has quite a few long-standing open pull requests. This might be due to limited maintainer bandwidth or other reasons.

Currently, any customization or feature enhancement requires going through the full PR → review → merge cycle, which can be slow and inflexible—especially when we want to add custom functionality (e.g., tailored CI workflows, enhanced code review automation, etc.). The existing contribution model makes rapid iteration challenging.

This leads me to wonder: Would it make sense to create a separate project that builds on opencode's extensibility, but is specifically designed to integrate with Gitea’s ecosystem? For example, such a project could:

  • Support automated code reviews for Gitea pull requests;
  • Integrate static analysis tools like Semgrep (similar to how GitHub Copilot leverages CodeQL);
  • Leverage Gitea’s tooling (e.g., MCP or other APIs) to enable richer, more customizable CI/CD pipelines.

This approach would allow us to retain the core strengths of opencode while enabling faster, community-driven innovation without being blocked by upstream merge constraints.

I’d love to hear your thoughts:

  • Are others facing similar limitations?
  • Has anyone already explored something like this?
  • Do you have suggestions for a better architecture or integration strategy?

Currently, I have implemented some features without modifying the opencode source code.

Image
@ccsert commented on GitHub (Jan 20, 2026): > Hi everyone, > > I've noticed that the opencode repository has quite a few long-standing open pull requests. This might be due to limited maintainer bandwidth or other reasons. > > Currently, any customization or feature enhancement requires going through the full PR → review → merge cycle, which can be slow and inflexible—especially when we want to add custom functionality (e.g., tailored CI workflows, enhanced code review automation, etc.). The existing contribution model makes rapid iteration challenging. > > This leads me to wonder: Would it make sense to create a separate project that builds on opencode's extensibility, but is specifically designed to integrate with Gitea’s ecosystem? For example, such a project could: > > * Support automated code reviews for Gitea pull requests; > * Integrate static analysis tools like [Semgrep](https://github.com/semgrep/semgrep) (similar to how GitHub Copilot leverages CodeQL); > * Leverage Gitea’s tooling (e.g., MCP or other APIs) to enable richer, more customizable CI/CD pipelines. > > This approach would allow us to retain the core strengths of opencode while enabling faster, community-driven innovation without being blocked by upstream merge constraints. > > I’d love to hear your thoughts: > > * Are others facing similar limitations? > * Has anyone already explored something like this? > * Do you have suggestions for a better architecture or integration strategy? Currently, I have implemented some features without modifying the opencode source code. <img width="1236" height="1336" alt="Image" src="https://github.com/user-attachments/assets/827df1f9-fa98-462d-bd1f-8182e088168a" />
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@sebastianertz commented on GitHub (Jan 27, 2026):

Currently, I have implemented some features without modifying the opencode source code.

@ccsert I'm interested in how you did that.

@sebastianertz commented on GitHub (Jan 27, 2026): > Currently, I have implemented some features without modifying the opencode source code. @ccsert I'm interested in how you did that.
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@ccsert commented on GitHub (Jan 27, 2026):

Currently, I have implemented some features without modifying the opencode source code.

@ccsert I'm interested in how you did that.

You can create a .opencode directory in the project root and then encapsulate Gitea-related tools, agents, or skills yourself; you can even submit MCP (Model Context Protocol) configurations into it.

These files need to be placed in the project directory. To avoid conflicts between the OpenCode development environment and the build environment, you can temporarily disable tools locally by modifying .opencode/opencode.json and then enable them within the actions YAML. Currently, I have them enabled by default. A further improvement would be to encapsulate all these functions into actions; by directly referencing the corresponding actions repository, you could implement all features. However, I have been quite busy with work recently and haven't had the time to complete this yet.If there is interest, I would be happy to submit it to a GitHub repository for everyone's reference.

Then, simply create your own actions; OpenCode supports using them directly. Below is a relatively simple example of the actions I used previously:

Image 
name: opencode

on:
  issue_comment:
    types: [created]
  pull_request_review_comment:  
    types: [created]
  pull_request:
    types: [opened, synchronize]

jobs:
  opencode:
    if: |
      contains(github.event.comment.body, ' /oc') ||
      startsWith(github.event.comment.body, '/oc') ||
      contains(github.event.comment.body, ' /opencode') ||
      startsWith(github.event.comment.body, '/opencode')
    # Adjust runs-on and container to match your runner configuration
    runs-on: linux
    container: catthehacker/ubuntu:act-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: Install Bun
        run: |
          curl -fsSL https://bun.sh/install | bash
          echo "$HOME/.bun/bin" >> $GITHUB_PATH

      - name: Install opencode
        run: ~/.bun/bin/bun install -g opencode-ai

      - name: Run opencode
        env:
          MODEL: opencode/minimax-m2.1-free
          GITEA_TOKEN: ${{ secrets.OPENCODE_GIT_TOKEN }}
          GITEA_SERVER_URL: ${{ gitea.server_url }}
          DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }}
          OPENCODE_LOG_LEVEL: debug
          PR_NUMBER: ${{ github.event.issue.number }}
          REPO_OWNER: ${{ github.repository_owner }}
          REPO_NAME: ${{ github.event.repository.name }}
        run: |
          opencode run --agent code-review \
            "Please review PR #${PR_NUMBER} in ${REPO_OWNER}/${REPO_NAME}. \
             Fetch the diff, analyze the code changes, and submit a detailed review \
             with line-level comments for any issues found."
@ccsert commented on GitHub (Jan 27, 2026): > > Currently, I have implemented some features without modifying the opencode source code. > > [@ccsert](https://github.com/ccsert) I'm interested in how you did that. You can create a `.opencode` directory in the project root and then encapsulate Gitea-related tools, agents, or skills yourself; you can even submit MCP (Model Context Protocol) configurations into it. These files need to be placed in the project directory. To avoid conflicts between the OpenCode development environment and the build environment, you can temporarily disable tools locally by modifying `.opencode/opencode.json` and then enable them within the actions YAML. Currently, I have them enabled by default. A further improvement would be to encapsulate all these functions into actions; by directly referencing the corresponding actions repository, you could implement all features. However, I have been quite busy with work recently and haven't had the time to complete this yet.If there is interest, I would be happy to submit it to a GitHub repository for everyone's reference. Then, simply create your own actions; OpenCode supports using them directly. Below is a relatively simple example of the actions I used previously: <img width="454" height="1124" alt="Image" src="https://github.com/user-attachments/assets/364aabfa-1fb1-49f0-99ae-6c9da40c0421" /> ```yaml name: opencode on: issue_comment: types: [created] pull_request_review_comment: types: [created] pull_request: types: [opened, synchronize] jobs: opencode: if: | contains(github.event.comment.body, ' /oc') || startsWith(github.event.comment.body, '/oc') || contains(github.event.comment.body, ' /opencode') || startsWith(github.event.comment.body, '/opencode') # Adjust runs-on and container to match your runner configuration runs-on: linux container: catthehacker/ubuntu:act-latest steps: - name: Checkout repository uses: actions/checkout@v4 with: persist-credentials: false - name: Install Bun run: | curl -fsSL https://bun.sh/install | bash echo "$HOME/.bun/bin" >> $GITHUB_PATH - name: Install opencode run: ~/.bun/bin/bun install -g opencode-ai - name: Run opencode env: MODEL: opencode/minimax-m2.1-free GITEA_TOKEN: ${{ secrets.OPENCODE_GIT_TOKEN }} GITEA_SERVER_URL: ${{ gitea.server_url }} DEEPSEEK_API_KEY: ${{ secrets.DEEPSEEK_API_KEY }} OPENCODE_LOG_LEVEL: debug PR_NUMBER: ${{ github.event.issue.number }} REPO_OWNER: ${{ github.repository_owner }} REPO_NAME: ${{ github.event.repository.name }} run: | opencode run --agent code-review \ "Please review PR #${PR_NUMBER} in ${REPO_OWNER}/${REPO_NAME}. \ Fetch the diff, analyze the code changes, and submit a detailed review \ with line-level comments for any issues found." ```
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@opencode-agent[bot] commented on GitHub (Jan 27, 2026):

User ccsert does not have write permissions

github run

@opencode-agent[bot] commented on GitHub (Jan 27, 2026): User ccsert does not have write permissions [github run](/anomalyco/opencode/actions/runs/21423922534)
yindo commented 2026-02-16 17:30:15 -05:00
Author
Owner
Copy Link
Copy Source

@ccsert commented on GitHub (Jan 28, 2026):

@sebastianertz It has been pushed to the GitHub repository https://github.com/ccsert/opencode-review-gitea, and support for Docker images may be provided in the future.

@ccsert commented on GitHub (Jan 28, 2026): @sebastianertz It has been pushed to the GitHub repository https://github.com/ccsert/opencode-review-gitea, and support for Docker images may be provided in the future.
yindo commented 2026-02-16 17:30:16 -05:00
Author
Owner
Copy Link
Copy Source

@ramblingcoder commented on GitHub (Feb 11, 2026):

This was my approach as an alternative if it helps anyone. It does require setting up the Gitea MCP server but that is pretty easy.

I use Z.AI's coding plan but should work for anyone if you update the auth.json or opencode.json to point to what you want.

Prompt I default to is the same as the opencode example. Review the codebase for any TODO comments and create a summary. If you find issues worth addressing, open an issue to track them.
I just made it a variable to allow me to test different prompts if i manually ran the action or use the globally defined variable for an organization so all related actions get the update.

This may not be necessary but I did give it some information about Gitea in an instruction to try and prevent it from using gh cli commands instead of using the gitea mcp.

If you're not sure of the value to use for the mode id, run opencode models and choose one of the ones you've connected with on your local machine.

instruction

# Gitea

Gitea is a selfhosted GIT server.

Gitea runner's function exactly the same as GitHub runners. They're just stored in the .gitea folder instead of .github folder.

## GITHUB's gh cli

Whenever you need to use the gh cli, use an equivalent tool from the 'gitea' mcp tool instead.

**Example**
`gh issue list --repo owner/repo` should instead use list_repo_issues from gitea mcp

action

name: Process ToDo Tasks

# Required Repository Variables:
#   - GIT_MCP_URL: The URL of the Gitea MCP server
#   - PROMPT_TODO: The default prompt message for OpenCode when running on schedule
#   - OPENCODE_MODEL: (Optional) The OpenCode model to use. Defaults to 'zai-coding-plan/glm-4.7'
#
# Required Secrets:
#   - GIT_MCP_TOKEN: The API token for authenticating with the Gitea MCP server. 
#         I placed an NGINX in front of it to authenticate requests, feel free to remove this portion if you don't want that behavior.
#   - ZAI_API_KEY: The API key for the Zai AI service

on:
  schedule:
    - cron: "0 9 * * 1" # Every Monday at 9am UTC
  workflow_dispatch:
    inputs:
      message:
        description: 'The prompt message to send to OpenCode'
        required: false

jobs:
  opencode:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: write
      pull-requests: write
      issues: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v6
        with:
          persist-credentials: false

      - name: Install Bun
        run: |
          curl -fsSL https://bun.sh/install | bash
          echo "$HOME/.bun/bin" >> $GITHUB_PATH
          
      - name: Install opencode
        run: ~/.bun/bin/bun install -g opencode-ai

      - name: Configure OpenCode Config
        run: |
          mkdir -p ~/.config/opencode
          echo "GITEA_MCP_URL=$GITEA_MCP_URL"
          echo "GITEA_MCP_API_KEY is set: $( [ -n "$GITEA_MCP_API_KEY" ] && echo 'yes' || echo 'no' )"
          cat > ~/.config/opencode/opencode.json <<EOF
          {
            "\$schema": "https://opencode.ai/config.json",
            "instructions": [
              "https://SOME-PUBLIC-MARKDOWN-FOR-GITEA.md"
            ],
            "mcp": {
              "gitea": {
                "enabled": true,
                "type": "remote",
                "url": "$GITEA_MCP_URL",
                "headers": {
                  "X-API-Key": "$GITEA_MCP_API_KEY"
                }
              }
            }
          }
          EOF
          echo "Generated config:"
          cat ~/.config/opencode/opencode.json
        env:
          GITEA_MCP_URL: ${{ vars.GIT_MCP_URL }}
          GITEA_MCP_API_KEY: ${{ secrets.GIT_MCP_TOKEN }}

      - name: Configure OpenCode Auth
        run: |
          mkdir -p ~/.local/share/opencode
          echo "ZAI_API_KEY is set: $( [ -n "$ZAI_API_KEY" ] && echo 'yes' || echo 'no' )"
          cat > ~/.local/share/opencode/auth.json <<EOF
          {
            "zai-coding-plan": {
              "type": "api",
              "key": "$ZAI_API_KEY"
            }
          }
          EOF
          echo "Generated auth:"
          cat ~/.local/share/opencode/auth.json
        env:
          ZAI_API_KEY: ${{ secrets.ZAI_API_KEY }}
            
      - name: Run OpenCode command with mcp
        run: |
          opencode mcp list

      - name: Run OpenCode command with prompt
        env:
          OPENCODE_MODEL: ${{ vars.OPENCODE_MODEL || 'zai-coding-plan/glm-4.7' }}
          OPENCODE_MESSAGE: ${{ inputs.message || vars.PROMPT_TODO }}
        run: |
          opencode run \
            --model ${{ env.OPENCODE_MODEL }} \
            "${{ env.OPENCODE_MESSAGE }}"
@ramblingcoder commented on GitHub (Feb 11, 2026): This was my approach as an alternative if it helps anyone. It does require setting up the Gitea MCP server but that is pretty easy. I use Z.AI's coding plan but should work for anyone if you update the auth.json or opencode.json to point to what you want. Prompt I default to is the same as the opencode example. `Review the codebase for any TODO comments and create a summary. If you find issues worth addressing, open an issue to track them.` I just made it a variable to allow me to test different prompts if i manually ran the action or use the globally defined variable for an organization so all related actions get the update. This may not be necessary but I did give it some information about Gitea in an instruction to try and prevent it from using gh cli commands instead of using the gitea mcp. If you're not sure of the value to use for the mode id, run `opencode models` and choose one of the ones you've connected with on your local machine. **instruction** ```markdown # Gitea Gitea is a selfhosted GIT server. Gitea runner's function exactly the same as GitHub runners. They're just stored in the .gitea folder instead of .github folder. ## GITHUB's gh cli Whenever you need to use the gh cli, use an equivalent tool from the 'gitea' mcp tool instead. **Example** `gh issue list --repo owner/repo` should instead use list_repo_issues from gitea mcp ``` **action** ```markdown name: Process ToDo Tasks # Required Repository Variables: # - GIT_MCP_URL: The URL of the Gitea MCP server # - PROMPT_TODO: The default prompt message for OpenCode when running on schedule # - OPENCODE_MODEL: (Optional) The OpenCode model to use. Defaults to 'zai-coding-plan/glm-4.7' # # Required Secrets: # - GIT_MCP_TOKEN: The API token for authenticating with the Gitea MCP server. # I placed an NGINX in front of it to authenticate requests, feel free to remove this portion if you don't want that behavior. # - ZAI_API_KEY: The API key for the Zai AI service on: schedule: - cron: "0 9 * * 1" # Every Monday at 9am UTC workflow_dispatch: inputs: message: description: 'The prompt message to send to OpenCode' required: false jobs: opencode: runs-on: ubuntu-latest permissions: id-token: write contents: write pull-requests: write issues: write steps: - name: Checkout repository uses: actions/checkout@v6 with: persist-credentials: false - name: Install Bun run: | curl -fsSL https://bun.sh/install | bash echo "$HOME/.bun/bin" >> $GITHUB_PATH - name: Install opencode run: ~/.bun/bin/bun install -g opencode-ai - name: Configure OpenCode Config run: | mkdir -p ~/.config/opencode echo "GITEA_MCP_URL=$GITEA_MCP_URL" echo "GITEA_MCP_API_KEY is set: $( [ -n "$GITEA_MCP_API_KEY" ] && echo 'yes' || echo 'no' )" cat > ~/.config/opencode/opencode.json <<EOF { "\$schema": "https://opencode.ai/config.json", "instructions": [ "https://SOME-PUBLIC-MARKDOWN-FOR-GITEA.md" ], "mcp": { "gitea": { "enabled": true, "type": "remote", "url": "$GITEA_MCP_URL", "headers": { "X-API-Key": "$GITEA_MCP_API_KEY" } } } } EOF echo "Generated config:" cat ~/.config/opencode/opencode.json env: GITEA_MCP_URL: ${{ vars.GIT_MCP_URL }} GITEA_MCP_API_KEY: ${{ secrets.GIT_MCP_TOKEN }} - name: Configure OpenCode Auth run: | mkdir -p ~/.local/share/opencode echo "ZAI_API_KEY is set: $( [ -n "$ZAI_API_KEY" ] && echo 'yes' || echo 'no' )" cat > ~/.local/share/opencode/auth.json <<EOF { "zai-coding-plan": { "type": "api", "key": "$ZAI_API_KEY" } } EOF echo "Generated auth:" cat ~/.local/share/opencode/auth.json env: ZAI_API_KEY: ${{ secrets.ZAI_API_KEY }} - name: Run OpenCode command with mcp run: | opencode mcp list - name: Run OpenCode command with prompt env: OPENCODE_MODEL: ${{ vars.OPENCODE_MODEL || 'zai-coding-plan/glm-4.7' }} OPENCODE_MESSAGE: ${{ inputs.message || vars.PROMPT_TODO }} run: | opencode run \ --model ${{ env.OPENCODE_MODEL }} \ "${{ env.OPENCODE_MESSAGE }}" ```
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#1274
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?