Feature request: Forgejo / Gitea actions support

[justyns]

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/

[rekram1-node]

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

[cweagans]

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

[0x7C2f]

Bumping for interest! Currently running ForgeJo.

[janmaroto]

Really interested on seeing this on Forgejo.

[Integer-Systems-NL]

This would be a great feature (Gitea)!

[ccsert]

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]

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]

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.