feat: add GitHub Actions support #75

Closed
rodin wants to merge 1 commits from github-support into main
Owner

Adds GitHub Actions support alongside existing Gitea Actions.

Changes

  • Copy .gitea/ to .github/ for GitHub Actions compatibility
  • Update .github/workflows to use GITHUB_SERVER_URL/GITHUB_REPOSITORY
  • Update main.go to accept both GITEA_* and GITHUB_* env vars

Testing

  • Works on Gitea (existing)
  • Will be tested on github.com via push mirror to aweiker/ai-core-review-bot

No breaking changes for existing Gitea users.

Adds GitHub Actions support alongside existing Gitea Actions. ## Changes - Copy `.gitea/` to `.github/` for GitHub Actions compatibility - Update `.github/workflows` to use `GITHUB_SERVER_URL`/`GITHUB_REPOSITORY` - Update `main.go` to accept both `GITEA_*` and `GITHUB_*` env vars ## Testing - Works on Gitea (existing) - Will be tested on github.com via push mirror to aweiker/ai-core-review-bot No breaking changes for existing Gitea users.
rodin added 1 commit 2026-05-11 15:42:48 +00:00
feat: add GitHub Actions support
PR Ready Gate / clear-labels (pull_request) Successful in 2s
CI / test (pull_request) Successful in 18s
CI / review (anthropic--claude-4.6-sonnet, sonnet, SONNET_REVIEW_TOKEN) (pull_request) Successful in 38s
CI / review (gpt-5, security, ., rodin/security-patterns, SECURITY_REVIEW.md, SECURITY_REVIEW_TOKEN) (pull_request) Successful in 1m21s
CI / review (gpt-5, gpt, GPT_REVIEW_TOKEN) (pull_request) Successful in 2m14s
dd003c66d5
- Copy .gitea/ to .github/ for GitHub Actions compatibility
- Update .github/workflows to use GITHUB_SERVER_URL/GITHUB_REPOSITORY
- Update main.go to accept both GITEA_* and GITHUB_* env vars

Works on both Gitea and GitHub without code changes.
sonnet-review-bot approved these changes 2026-05-11 15:43:42 +00:00
sonnet-review-bot left a comment
First-time contributor

Original review

Supersededsee current review for up-to-date findings.

Previous findings (commit dd003c66)

Sonnet Review

Summary

This PR adds GitHub Actions support alongside existing Gitea Actions by copying the workflow files to .github/ and updating main.go to fall back to GITHUB_SERVER_URL/GITHUB_REPOSITORY env vars. The Go change is minimal and correct. CI passed.

Findings

# Severity File Line Finding
1 [MINOR] .github/actions/review/action.yml 1 The action comment says 'This composite action is designed for Gitea Actions runners' but this file is now in .github/ for GitHub Actions. The comment is misleading for GitHub Actions users who encounter this file. Consider updating the comment to reflect dual-platform support.
2 [MINOR] .github/workflows/pr-ready-gate.yml 23 The Gitea API URL is hardcoded as https://gitea.weiker.me rather than using github.server_url. This workflow will fail silently (curl will hit the Gitea instance) when running on GitHub.com, since secrets.RODIN_TOKEN won't be a valid GitHub token and the API path (/api/v1/) is Gitea-specific. If this workflow is intended to be a no-op on GitHub, that should be explicitly documented or the job should be conditioned on the server URL.
3 [NIT] .github/workflows/ci.yml 14 Go version is specified as 1.26, which does not exist yet (latest stable is 1.24.x as of mid-2025). This may cause actions/setup-go to fail or resolve to an unexpected version on GitHub Actions. Recommend pinning to a known stable version like 1.24.
4 [NIT] .github/actions/review/action.yml 87 The REPO default for the binary download is hardcoded to rodin/review-bot. When running on GitHub.com (mirrored as aweiker/ai-core-review-bot), the download will still attempt to fetch from the Gitea instance at github.server_url (which would be https://github.com) using the Gitea API path /api/v1/repos/rodin/review-bot/releases. This will 404. The action works for Gitea runners but will break if actually invoked as a reusable action on GitHub.com. Consider documenting that gitea-url must be explicitly set when using from GitHub.

Recommendation

APPROVE — The Go code change in main.go is correct and minimal — it simply adds GITHUB_SERVER_URL and GITHUB_REPOSITORY as fallback env vars with proper nesting, which is the right approach. CI passed. The main concern is that pr-ready-gate.yml hardcodes the Gitea API URL and will not function correctly on GitHub.com (it will either fail or silently do nothing useful). However, based on the PR description this is being pushed as a mirror to aweiker/ai-core-review-bot for testing, and the PR-ready-gate may be intentionally Gitea-only. The Go version 1.26 in ci.yml is a NIT since actions/setup-go may handle non-existent versions gracefully or resolve to latest. Overall this is a reasonable infrastructure addition and can be approved with the expectation that GitHub-specific workflows (especially pr-ready-gate) may need adjustment after testing.


Review by sonnet


Evaluated against dd003c66

~~Original review~~ **Superseded** — [see current review](https://gitea.weiker.me/rodin/review-bot/pulls/75#pullrequestreview-2553) for up-to-date findings. <details><summary>Previous findings (commit dd003c66)</summary> # Sonnet Review ## Summary This PR adds GitHub Actions support alongside existing Gitea Actions by copying the workflow files to `.github/` and updating `main.go` to fall back to `GITHUB_SERVER_URL`/`GITHUB_REPOSITORY` env vars. The Go change is minimal and correct. CI passed. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MINOR] | `.github/actions/review/action.yml` | 1 | The action comment says 'This composite action is designed for Gitea Actions runners' but this file is now in `.github/` for GitHub Actions. The comment is misleading for GitHub Actions users who encounter this file. Consider updating the comment to reflect dual-platform support. | | 2 | [MINOR] | `.github/workflows/pr-ready-gate.yml` | 23 | The Gitea API URL is hardcoded as `https://gitea.weiker.me` rather than using `github.server_url`. This workflow will fail silently (curl will hit the Gitea instance) when running on GitHub.com, since `secrets.RODIN_TOKEN` won't be a valid GitHub token and the API path (`/api/v1/`) is Gitea-specific. If this workflow is intended to be a no-op on GitHub, that should be explicitly documented or the job should be conditioned on the server URL. | | 3 | [NIT] | `.github/workflows/ci.yml` | 14 | Go version is specified as `1.26`, which does not exist yet (latest stable is 1.24.x as of mid-2025). This may cause `actions/setup-go` to fail or resolve to an unexpected version on GitHub Actions. Recommend pinning to a known stable version like `1.24`. | | 4 | [NIT] | `.github/actions/review/action.yml` | 87 | The `REPO` default for the binary download is hardcoded to `rodin/review-bot`. When running on GitHub.com (mirrored as `aweiker/ai-core-review-bot`), the download will still attempt to fetch from the Gitea instance at `github.server_url` (which would be `https://github.com`) using the Gitea API path `/api/v1/repos/rodin/review-bot/releases`. This will 404. The action works for Gitea runners but will break if actually invoked as a reusable action on GitHub.com. Consider documenting that `gitea-url` must be explicitly set when using from GitHub. | ## Recommendation **APPROVE** — The Go code change in `main.go` is correct and minimal — it simply adds `GITHUB_SERVER_URL` and `GITHUB_REPOSITORY` as fallback env vars with proper nesting, which is the right approach. CI passed. The main concern is that `pr-ready-gate.yml` hardcodes the Gitea API URL and will not function correctly on GitHub.com (it will either fail or silently do nothing useful). However, based on the PR description this is being pushed as a mirror to `aweiker/ai-core-review-bot` for testing, and the PR-ready-gate may be intentionally Gitea-only. The Go version `1.26` in ci.yml is a NIT since `actions/setup-go` may handle non-existent versions gracefully or resolve to latest. Overall this is a reasonable infrastructure addition and can be approved with the expectation that GitHub-specific workflows (especially pr-ready-gate) may need adjustment after testing. --- *Review by sonnet* <!-- review-bot:sonnet --> --- *Evaluated against dd003c66* </details> <!-- review-bot:sonnet -->
@@ -0,0 +1,200 @@
# This composite action is designed for Gitea Actions runners.
First-time contributor

[MINOR] The action comment says 'This composite action is designed for Gitea Actions runners' but this file is now in .github/ for GitHub Actions. The comment is misleading for GitHub Actions users who encounter this file. Consider updating the comment to reflect dual-platform support.

**[MINOR]** The action comment says 'This composite action is designed for Gitea Actions runners' but this file is now in `.github/` for GitHub Actions. The comment is misleading for GitHub Actions users who encounter this file. Consider updating the comment to reflect dual-platform support.
aweiker marked this conversation as resolved
@@ -0,0 +84,4 @@
description: 'review-bot version to install (e.g. v0.1.0, defaults to latest)'
required: false
default: 'latest'
dry-run:
First-time contributor

[NIT] The REPO default for the binary download is hardcoded to rodin/review-bot. When running on GitHub.com (mirrored as aweiker/ai-core-review-bot), the download will still attempt to fetch from the Gitea instance at github.server_url (which would be https://github.com) using the Gitea API path /api/v1/repos/rodin/review-bot/releases. This will 404. The action works for Gitea runners but will break if actually invoked as a reusable action on GitHub.com. Consider documenting that gitea-url must be explicitly set when using from GitHub.

**[NIT]** The `REPO` default for the binary download is hardcoded to `rodin/review-bot`. When running on GitHub.com (mirrored as `aweiker/ai-core-review-bot`), the download will still attempt to fetch from the Gitea instance at `github.server_url` (which would be `https://github.com`) using the Gitea API path `/api/v1/repos/rodin/review-bot/releases`. This will 404. The action works for Gitea runners but will break if actually invoked as a reusable action on GitHub.com. Consider documenting that `gitea-url` must be explicitly set when using from GitHub.
aweiker marked this conversation as resolved
@@ -0,0 +11,4 @@
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
First-time contributor

[NIT] Go version is specified as 1.26, which does not exist yet (latest stable is 1.24.x as of mid-2025). This may cause actions/setup-go to fail or resolve to an unexpected version on GitHub Actions. Recommend pinning to a known stable version like 1.24.

**[NIT]** Go version is specified as `1.26`, which does not exist yet (latest stable is 1.24.x as of mid-2025). This may cause `actions/setup-go` to fail or resolve to an unexpected version on GitHub Actions. Recommend pinning to a known stable version like `1.24`.
@@ -0,0 +20,4 @@
# Remove ready label if present
curl -sS -X DELETE \
-H "Authorization: token $GITEA_TOKEN" \
First-time contributor

[MINOR] The Gitea API URL is hardcoded as https://gitea.weiker.me rather than using github.server_url. This workflow will fail silently (curl will hit the Gitea instance) when running on GitHub.com, since secrets.RODIN_TOKEN won't be a valid GitHub token and the API path (/api/v1/) is Gitea-specific. If this workflow is intended to be a no-op on GitHub, that should be explicitly documented or the job should be conditioned on the server URL.

**[MINOR]** The Gitea API URL is hardcoded as `https://gitea.weiker.me` rather than using `github.server_url`. This workflow will fail silently (curl will hit the Gitea instance) when running on GitHub.com, since `secrets.RODIN_TOKEN` won't be a valid GitHub token and the API path (`/api/v1/`) is Gitea-specific. If this workflow is intended to be a no-op on GitHub, that should be explicitly documented or the job should be conditioned on the server URL.
security-review-bot requested review from security-review-bot 2026-05-11 15:45:08 +00:00
security-review-bot requested changes 2026-05-11 15:45:08 +00:00
Dismissed
security-review-bot left a comment
Collaborator

Original review

Supersededsee current review for up-to-date findings.

Previous findings (commit dd003c66)

Security Review

Summary

The changes largely add GitHub Actions support and minor env var fallbacks, but the CI workflow introduces a high-risk secret exposure pattern. The review job runs code built from the pull request while injecting multiple secrets, allowing a malicious PR to exfiltrate them.

Findings

# Severity File Line Finding
1 [MAJOR] .github/workflows/ci.yml 55 Secrets are provided to a pull_request job that builds and executes code from the PR (e.g., REVIEWER_TOKEN and multiple AICORE_* secrets). A malicious PR could modify the code to exfiltrate these secrets. Best practice is to avoid using secrets in workflows that run untrusted PR code.

Recommendation

REQUEST_CHANGES — Do not pass secrets into workflows that build and run untrusted pull request code. Mitigations:

  • Use a trusted, prebuilt binary (e.g., via a reusable/composite action pinned to a specific commit or signed release) for PR reviews instead of building from the PR; or run the self-review only after merge.
  • If self-review must run on PRs, avoid secrets entirely or gate execution to trusted actors only (e.g., repository members) and avoid running PR-modified code with those secrets. Alternatively, use pull_request_target and ensure the job uses the base repository workflow and trusted code, checking out the PR contents only as data after strict validation (be aware of pull_request_target risks).
  • Restrict workflows so secrets are never exposed on forked PRs and consider additional policy checks (e.g., actor allowlists) before injecting secrets.
    Once the workflow is hardened to prevent secret exposure, the remaining changes appear reasonable from a security perspective.

Review by security


Evaluated against dd003c66

~~Original review~~ **Superseded** — [see current review](https://gitea.weiker.me/rodin/review-bot/pulls/75#pullrequestreview-2556) for up-to-date findings. <details><summary>Previous findings (commit dd003c66)</summary> # Security Review ## Summary The changes largely add GitHub Actions support and minor env var fallbacks, but the CI workflow introduces a high-risk secret exposure pattern. The review job runs code built from the pull request while injecting multiple secrets, allowing a malicious PR to exfiltrate them. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MAJOR] | `.github/workflows/ci.yml` | 55 | Secrets are provided to a pull_request job that builds and executes code from the PR (e.g., REVIEWER_TOKEN and multiple AICORE_* secrets). A malicious PR could modify the code to exfiltrate these secrets. Best practice is to avoid using secrets in workflows that run untrusted PR code. | ## Recommendation **REQUEST_CHANGES** — Do not pass secrets into workflows that build and run untrusted pull request code. Mitigations: - Use a trusted, prebuilt binary (e.g., via a reusable/composite action pinned to a specific commit or signed release) for PR reviews instead of building from the PR; or run the self-review only after merge. - If self-review must run on PRs, avoid secrets entirely or gate execution to trusted actors only (e.g., repository members) and avoid running PR-modified code with those secrets. Alternatively, use pull_request_target and ensure the job uses the base repository workflow and trusted code, checking out the PR contents only as data after strict validation (be aware of pull_request_target risks). - Restrict workflows so secrets are never exposed on forked PRs and consider additional policy checks (e.g., actor allowlists) before injecting secrets. Once the workflow is hardened to prevent secret exposure, the remaining changes appear reasonable from a security perspective. --- *Review by security* <!-- review-bot:security --> --- *Evaluated against dd003c66* </details> <!-- review-bot:security -->
@@ -0,0 +52,4 @@
GITHUB_SERVER_URL: ${{ github.server_url }}
GITHUB_REPOSITORY: ${{ github.repository }}
PR_NUMBER: ${{ github.event.pull_request.number }}
REVIEWER_TOKEN: ${{ secrets[matrix.token_secret] }}
Collaborator

[MAJOR] Secrets are provided to a pull_request job that builds and executes code from the PR (e.g., REVIEWER_TOKEN and multiple AICORE_* secrets). A malicious PR could modify the code to exfiltrate these secrets. Best practice is to avoid using secrets in workflows that run untrusted PR code.

**[MAJOR]** Secrets are provided to a pull_request job that builds and executes code from the PR (e.g., REVIEWER_TOKEN and multiple AICORE_* secrets). A malicious PR could modify the code to exfiltrate these secrets. Best practice is to avoid using secrets in workflows that run untrusted PR code.
security-review-bot marked this conversation as resolved
gpt-review-bot requested changes 2026-05-11 15:45:57 +00:00
gpt-review-bot left a comment
First-time contributor

Original review

Supersededsee current review for up-to-date findings.

Previous findings (commit dd003c66)

Gpt Review

Summary

The Go code change to accept GITHUB_* env vars is straightforward and fine, but the new GitHub Actions workflows and composite action are wired to Gitea-specific endpoints while defaulting to GitHub server URLs. As written, key workflows (review, release, and the composite action’s version resolution) will fail or be no-ops on GitHub. These are correctness issues that block expected GitHub support.

Findings

# Severity File Line Finding
1 [MAJOR] .github/workflows/ci.yml 53 The review job sets GITHUB_SERVER_URL to github.server_url and runs ./review-bot, which initializes a Gitea client using this URL. GitHub’s REST API is not Gitea-compatible, so PR metadata/diff retrieval will fail on GitHub. Either set GITEA_URL to your Gitea instance (if targeting Gitea) or implement/use a GitHub client path.
2 [MAJOR] .github/workflows/release.yml 54 Release step uses GITEA_URL="${{ github.server_url }}" and calls /api/v1 (Gitea API). On GitHub this endpoint is invalid; release creation and asset upload will fail. If releases are intended on GitHub, switch to GitHub’s Releases API (api.github.com/repos/:owner/:repo/releases) or use actions like actions/create-release. If releases are intended on Gitea, set GITEA_URL explicitly to the Gitea server.
3 [MAJOR] .github/actions/review/action.yml 114 Determine version step defaults GITEA_URL to github.server_url and queries "${GITEA_URL}/api/v1/repos/${REPO}/releases" (Gitea API). On GitHub (https://github.com) this fails. Make gitea-url required when targeting Gitea releases or add logic to detect GitHub vs Gitea and call the correct API.
4 [MINOR] .github/workflows/pr-ready-gate.yml 20 Workflow targets Gitea API using GitHub PR number and repository. PR numbers generally won’t match across GitHub and Gitea, so operations will likely be no-ops. Consider gating this workflow to only run where the PR exists (or map PR numbers), or explicitly document that it manipulates the Gitea mirror.
5 [MINOR] .github/actions/review/action.yml 68 Input docs say repo defaults to current, but Determine version sets REPO to "${{ inputs.repo
6 [NIT] .github/workflows/release.yml 83 The upload script uses jq for URL-encoding without ensuring it’s present. ubuntu-24.04 runners typically include jq, but adding an explicit install or a pure-shell URL-encode avoids environment dependence.
7 [NIT] cmd/review-bot/main.go 55 The fallback to GITHUB_SERVER_URL/GITHUB_REPOSITORY is fine, but note that the client remains Gitea-specific. Consider clarifying in help text that GitHub support requires pointing to a Gitea-compatible API or implementing a GitHub client path.

Recommendation

REQUEST_CHANGES — The Go change to support GITHUB_* environment fallbacks looks good. However, the GitHub Actions additions currently default to GitHub server URLs while invoking Gitea-specific APIs, which will break on GitHub. To proceed:

  1. In .github/workflows/ci.yml (review job):
  • If the intent is to review GitHub PRs, implement/use a GitHub API client in review-bot and switch the code path based on server type; or
  • If the intent is to review Gitea PRs from GitHub runners, set GITEA_URL to your Gitea instance (not github.server_url) and ensure repo/PR references point to the Gitea repo/PR.
  1. In .github/workflows/release.yml:
  • Decide target release platform. For GitHub: use actions/create-release or GitHub REST API (api.github.com) with GITHUB_TOKEN. For Gitea: set GITEA_URL to the Gitea server and keep /api/v1 usage.
  1. In .github/actions/review/action.yml:
  • Make gitea-url required or auto-detect GitHub vs Gitea and call the appropriate API when determining the latest version and downloading artifacts. Also align the repo default with the input description (default to current repository).
  1. In .github/workflows/pr-ready-gate.yml:
  • Clarify intent or conditionally run only when acting on a Gitea PR; otherwise this is likely a no-op.

After these fixes, the workflows should function reliably on GitHub. The Go change itself does not need modifications.


Review by gpt


Evaluated against dd003c66

~~Original review~~ **Superseded** — [see current review](https://gitea.weiker.me/rodin/review-bot/pulls/75#pullrequestreview-2554) for up-to-date findings. <details><summary>Previous findings (commit dd003c66)</summary> # Gpt Review ## Summary The Go code change to accept GITHUB_* env vars is straightforward and fine, but the new GitHub Actions workflows and composite action are wired to Gitea-specific endpoints while defaulting to GitHub server URLs. As written, key workflows (review, release, and the composite action’s version resolution) will fail or be no-ops on GitHub. These are correctness issues that block expected GitHub support. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MAJOR] | `.github/workflows/ci.yml` | 53 | The review job sets GITHUB_SERVER_URL to github.server_url and runs ./review-bot, which initializes a Gitea client using this URL. GitHub’s REST API is not Gitea-compatible, so PR metadata/diff retrieval will fail on GitHub. Either set GITEA_URL to your Gitea instance (if targeting Gitea) or implement/use a GitHub client path. | | 2 | [MAJOR] | `.github/workflows/release.yml` | 54 | Release step uses GITEA_URL="${{ github.server_url }}" and calls /api/v1 (Gitea API). On GitHub this endpoint is invalid; release creation and asset upload will fail. If releases are intended on GitHub, switch to GitHub’s Releases API (api.github.com/repos/:owner/:repo/releases) or use actions like actions/create-release. If releases are intended on Gitea, set GITEA_URL explicitly to the Gitea server. | | 3 | [MAJOR] | `.github/actions/review/action.yml` | 114 | Determine version step defaults GITEA_URL to github.server_url and queries "${GITEA_URL}/api/v1/repos/${REPO}/releases" (Gitea API). On GitHub (https://github.com) this fails. Make gitea-url required when targeting Gitea releases or add logic to detect GitHub vs Gitea and call the correct API. | | 4 | [MINOR] | `.github/workflows/pr-ready-gate.yml` | 20 | Workflow targets Gitea API using GitHub PR number and repository. PR numbers generally won’t match across GitHub and Gitea, so operations will likely be no-ops. Consider gating this workflow to only run where the PR exists (or map PR numbers), or explicitly document that it manipulates the Gitea mirror. | | 5 | [MINOR] | `.github/actions/review/action.yml` | 68 | Input docs say repo defaults to current, but Determine version sets REPO to "${{ inputs.repo || 'rodin/review-bot' }}". This contradicts the description and may download binaries from the wrong repo by default. Align the default and docs (prefer defaulting to the current repository). | | 6 | [NIT] | `.github/workflows/release.yml` | 83 | The upload script uses jq for URL-encoding without ensuring it’s present. ubuntu-24.04 runners typically include jq, but adding an explicit install or a pure-shell URL-encode avoids environment dependence. | | 7 | [NIT] | `cmd/review-bot/main.go` | 55 | The fallback to GITHUB_SERVER_URL/GITHUB_REPOSITORY is fine, but note that the client remains Gitea-specific. Consider clarifying in help text that GitHub support requires pointing to a Gitea-compatible API or implementing a GitHub client path. | ## Recommendation **REQUEST_CHANGES** — The Go change to support GITHUB_* environment fallbacks looks good. However, the GitHub Actions additions currently default to GitHub server URLs while invoking Gitea-specific APIs, which will break on GitHub. To proceed: 1) In .github/workflows/ci.yml (review job): - If the intent is to review GitHub PRs, implement/use a GitHub API client in review-bot and switch the code path based on server type; or - If the intent is to review Gitea PRs from GitHub runners, set GITEA_URL to your Gitea instance (not github.server_url) and ensure repo/PR references point to the Gitea repo/PR. 2) In .github/workflows/release.yml: - Decide target release platform. For GitHub: use actions/create-release or GitHub REST API (api.github.com) with GITHUB_TOKEN. For Gitea: set GITEA_URL to the Gitea server and keep /api/v1 usage. 3) In .github/actions/review/action.yml: - Make gitea-url required or auto-detect GitHub vs Gitea and call the appropriate API when determining the latest version and downloading artifacts. Also align the repo default with the input description (default to current repository). 4) In .github/workflows/pr-ready-gate.yml: - Clarify intent or conditionally run only when acting on a Gitea PR; otherwise this is likely a no-op. After these fixes, the workflows should function reliably on GitHub. The Go change itself does not need modifications. --- *Review by gpt* <!-- review-bot:gpt --> --- *Evaluated against dd003c66* </details> <!-- review-bot:gpt -->
@@ -0,0 +65,4 @@
required: false
default: ''
patterns-repo:
description: 'Comma-separated repos with language patterns (e.g. rodin/elixir-patterns,rodin/phoenix-conventions)'
First-time contributor

[MINOR] Input docs say repo defaults to current, but Determine version sets REPO to "${{ inputs.repo || 'rodin/review-bot' }}". This contradicts the description and may download binaries from the wrong repo by default. Align the default and docs (prefer defaulting to the current repository).

**[MINOR]** Input docs say repo defaults to current, but Determine version sets REPO to "${{ inputs.repo || 'rodin/review-bot' }}". This contradicts the description and may download binaries from the wrong repo by default. Align the default and docs (prefer defaulting to the current repository).
aweiker marked this conversation as resolved
@@ -0,0 +111,4 @@
- name: Determine version
id: version
shell: bash
run: |
First-time contributor

[MAJOR] Determine version step defaults GITEA_URL to github.server_url and queries "${GITEA_URL}/api/v1/repos/${REPO}/releases" (Gitea API). On GitHub (https://github.com) this fails. Make gitea-url required when targeting Gitea releases or add logic to detect GitHub vs Gitea and call the correct API.

**[MAJOR]** Determine version step defaults GITEA_URL to github.server_url and queries "${GITEA_URL}/api/v1/repos/${REPO}/releases" (Gitea API). On GitHub (https://github.com) this fails. Make gitea-url required when targeting Gitea releases or add logic to detect GitHub vs Gitea and call the correct API.
aweiker marked this conversation as resolved
@@ -0,0 +50,4 @@
- name: Run ${{ matrix.name }} review
env:
GITHUB_SERVER_URL: ${{ github.server_url }}
GITHUB_REPOSITORY: ${{ github.repository }}
First-time contributor

[MAJOR] The review job sets GITHUB_SERVER_URL to github.server_url and runs ./review-bot, which initializes a Gitea client using this URL. GitHub’s REST API is not Gitea-compatible, so PR metadata/diff retrieval will fail on GitHub. Either set GITEA_URL to your Gitea instance (if targeting Gitea) or implement/use a GitHub client path.

**[MAJOR]** The review job sets GITHUB_SERVER_URL to github.server_url and runs ./review-bot, which initializes a Gitea client using this URL. GitHub’s REST API is not Gitea-compatible, so PR metadata/diff retrieval will fail on GitHub. Either set GITEA_URL to your Gitea instance (if targeting Gitea) or implement/use a GitHub client path.
@@ -0,0 +17,4 @@
AUTHOR=${{ github.event.pull_request.user.login }}
READY_LABEL_ID=38
SELF_REVIEWED_LABEL_ID=37
First-time contributor

[MINOR] Workflow targets Gitea API using GitHub PR number and repository. PR numbers generally won’t match across GitHub and Gitea, so operations will likely be no-ops. Consider gating this workflow to only run where the PR exists (or map PR numbers), or explicitly document that it manipulates the Gitea mirror.

**[MINOR]** Workflow targets Gitea API using GitHub PR number and repository. PR numbers generally won’t match across GitHub and Gitea, so operations will likely be no-ops. Consider gating this workflow to only run where the PR exists (or map PR numbers), or explicitly document that it manipulates the Gitea mirror.
@@ -0,0 +51,4 @@
echo "Release for ${VERSION} already exists, fetching existing..."
curl -sSf -o /tmp/release_response.json \
-H "Authorization: token ${GITEA_TOKEN}" \
"${GITEA_URL}/api/v1/repos/${REPO}/releases/tags/${VERSION}"
First-time contributor

[MAJOR] Release step uses GITEA_URL="${{ github.server_url }}" and calls /api/v1 (Gitea API). On GitHub this endpoint is invalid; release creation and asset upload will fail. If releases are intended on GitHub, switch to GitHub’s Releases API (api.github.com/repos/:owner/:repo/releases) or use actions like actions/create-release. If releases are intended on Gitea, set GITEA_URL explicitly to the Gitea server.

**[MAJOR]** Release step uses GITEA_URL="${{ github.server_url }}" and calls /api/v1 (Gitea API). On GitHub this endpoint is invalid; release creation and asset upload will fail. If releases are intended on GitHub, switch to GitHub’s Releases API (api.github.com/repos/:owner/:repo/releases) or use actions like actions/create-release. If releases are intended on Gitea, set GITEA_URL explicitly to the Gitea server.
aweiker marked this conversation as resolved
@@ -0,0 +80,4 @@
"${GITEA_URL}/api/v1/repos/${REPO}/releases/${RELEASE_ID}/assets" \
| python3 -c "import json,sys,os; name=os.environ['ASSET_NAME']; assets=json.load(sys.stdin); print(next((str(a['id']) for a in assets if a['name']==name),''))" 2>/dev/null)
if [ -n "$EXISTING_ID" ]; then
First-time contributor

[NIT] The upload script uses jq for URL-encoding without ensuring it’s present. ubuntu-24.04 runners typically include jq, but adding an explicit install or a pure-shell URL-encode avoids environment dependence.

**[NIT]** The upload script uses jq for URL-encoding without ensuring it’s present. ubuntu-24.04 runners typically include jq, but adding an explicit install or a pure-shell URL-encode avoids environment dependence.
aweiker marked this conversation as resolved
@@ -54,8 +54,8 @@ func main() {
logFormat := flag.String("log-format", envOrDefault("LOG_FORMAT", "text"), "Log output format: text or json")
verbosity := flag.String("verbosity", envOrDefault("LOG_VERBOSITY", "info"), "Log verbosity: debug, info, warn, error")
First-time contributor

[NIT] The fallback to GITHUB_SERVER_URL/GITHUB_REPOSITORY is fine, but note that the client remains Gitea-specific. Consider clarifying in help text that GitHub support requires pointing to a Gitea-compatible API or implementing a GitHub client path.

**[NIT]** The fallback to GITHUB_SERVER_URL/GITHUB_REPOSITORY is fine, but note that the client remains Gitea-specific. Consider clarifying in help text that GitHub support requires pointing to a Gitea-compatible API or implementing a GitHub client path.
aweiker marked this conversation as resolved
Author
Owner

Review Findings Addressed

Commit 29ab19c addresses all review findings:

MAJOR (4 fixed)

  1. security-review: Added fork protection to ci.yml review job with github.event.pull_request.head.repo.full_name == github.repository check. Added security comment explaining the trust model.

  2. gpt-review #1: Changed ci.yml to set GITHUB_SERVER_URL to explicit https://gitea.weiker.me since reviews are posted to Gitea, not GitHub.

  3. gpt-review #2: Changed release.yml to use explicit Gitea URL instead of github.server_url.

  4. gpt-review #3: Changed action.yml gitea-url input default from empty (fallback to github.server_url) to explicit https://gitea.weiker.me. All internal uses now rely on this default.

MINOR (4 fixed)

  1. sonnet-review #1: Updated action.yml header comment to reflect dual-platform support (Gitea Actions + GitHub Actions).

  2. sonnet-review #2: Added comment to pr-ready-gate.yml explaining the intentional hardcoded Gitea URL.

  3. gpt-review #4: Added comment to pr-ready-gate.yml about PR number matching assumption between GitHub mirror and Gitea.

  4. gpt-review #5: Updated action.yml repo input description to say it defaults to rodin/review-bot for version lookup, matching actual code behavior.

## Review Findings Addressed Commit 29ab19c addresses all review findings: ### MAJOR (4 fixed) 1. **security-review**: Added fork protection to ci.yml review job with `github.event.pull_request.head.repo.full_name == github.repository` check. Added security comment explaining the trust model. 2. **gpt-review #1**: Changed ci.yml to set `GITHUB_SERVER_URL` to explicit `https://gitea.weiker.me` since reviews are posted to Gitea, not GitHub. 3. **gpt-review #2**: Changed release.yml to use explicit Gitea URL instead of `github.server_url`. 4. **gpt-review #3**: Changed action.yml `gitea-url` input default from empty (fallback to `github.server_url`) to explicit `https://gitea.weiker.me`. All internal uses now rely on this default. ### MINOR (4 fixed) 1. **sonnet-review #1**: Updated action.yml header comment to reflect dual-platform support (Gitea Actions + GitHub Actions). 2. **sonnet-review #2**: Added comment to pr-ready-gate.yml explaining the intentional hardcoded Gitea URL. 3. **gpt-review #4**: Added comment to pr-ready-gate.yml about PR number matching assumption between GitHub mirror and Gitea. 4. **gpt-review #5**: Updated action.yml repo input description to say it defaults to `rodin/review-bot` for version lookup, matching actual code behavior.
sonnet-review-bot approved these changes 2026-05-11 15:53:21 +00:00
sonnet-review-bot left a comment
First-time contributor

Original review

Supersededsee current review for up-to-date findings.

Previous findings (commit 29ab19c9)

Sonnet Review

Summary

This PR adds GitHub Actions support by creating .github/ workflow files and updating main.go to accept GITHUB_* env vars as fallbacks for GITEA_* vars. The changes are well-structured, CI passes, and the design is sound.

Findings

# Severity File Line Finding
1 [MINOR] .github/actions/review/action.yml 163 The GITHUB_REPOSITORY env var is set to `${{ inputs.repo
2 [MINOR] .github/workflows/pr-ready-gate.yml 23 Label IDs 38 and 37 are hardcoded without explanation. If the Gitea instance label IDs ever change (e.g., after a data migration or re-creation), this silently does nothing. The comment explains WHY we use Gitea but not WHY these specific numeric IDs are correct. A brief comment naming which labels these IDs correspond to (e.g., # 38 = ready, 37 = self-reviewed) would improve maintainability.
3 [NIT] .github/workflows/ci.yml 12 Go version 1.26 is specified. As of early 2025, Go 1.26 is not yet released (latest stable is 1.23/1.24). If actions/setup-go resolves this to a future version that doesn't exist yet, the job would fail. This likely works today if setup-go tolerates forward-looking versions, but it's worth confirming and possibly pinning to a released version. (The Gitea CI presumably already uses this same version and passes, so this may be a non-issue in practice.)

Recommendation

APPROVE — The PR is well-implemented. The core Go change (two-line envOrDefault fallback chain for GITEA_URL/GITEA_REPOGITHUB_SERVER_URL/GITHUB_REPOSITORY) is minimal and correct. The workflow files are clearly commented about the intentional Gitea-posting-from-GitHub design. The one MINOR concern worth addressing before relying heavily on the composite action is the GITHUB_REPOSITORY fallback in action.yml — if a caller omits repo, the bot will silently target the wrong Gitea repo. This is low-risk for the described use case (aweiker's mirror explicitly sets the Gitea repo), but could surprise future users of the action. The other findings are documentation/robustness nits. Approve with the suggestion to address the repo fallback logic.


Review by sonnet


Evaluated against 29ab19c9

~~Original review~~ **Superseded** — [see current review](https://gitea.weiker.me/rodin/review-bot/pulls/75#pullrequestreview-2557) for up-to-date findings. <details><summary>Previous findings (commit 29ab19c9)</summary> # Sonnet Review ## Summary This PR adds GitHub Actions support by creating `.github/` workflow files and updating `main.go` to accept `GITHUB_*` env vars as fallbacks for `GITEA_*` vars. The changes are well-structured, CI passes, and the design is sound. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MINOR] | `.github/actions/review/action.yml` | 163 | The `GITHUB_REPOSITORY` env var is set to `${{ inputs.repo || github.repository }}`. When running from GitHub Actions on the mirror repo, `github.repository` would be `aweiker/ai-core-review-bot` (or similar), not `rodin/review-bot`. This means if `inputs.repo` is not explicitly provided, the review-bot would try to post to the wrong Gitea repository. The composite action's `repo` input has no default (`default: ''`), which means the fallback to `github.repository` is always in play when callers don't pass `repo`. This could silently produce incorrect behavior rather than a clear error. Consider either making `repo` required or defaulting it to `rodin/review-bot` to match the documented intent. | | 2 | [MINOR] | `.github/workflows/pr-ready-gate.yml` | 23 | Label IDs 38 and 37 are hardcoded without explanation. If the Gitea instance label IDs ever change (e.g., after a data migration or re-creation), this silently does nothing. The comment explains WHY we use Gitea but not WHY these specific numeric IDs are correct. A brief comment naming which labels these IDs correspond to (e.g., `# 38 = ready, 37 = self-reviewed`) would improve maintainability. | | 3 | [NIT] | `.github/workflows/ci.yml` | 12 | Go version `1.26` is specified. As of early 2025, Go 1.26 is not yet released (latest stable is 1.23/1.24). If `actions/setup-go` resolves this to a future version that doesn't exist yet, the job would fail. This likely works today if setup-go tolerates forward-looking versions, but it's worth confirming and possibly pinning to a released version. (The Gitea CI presumably already uses this same version and passes, so this may be a non-issue in practice.) | ## Recommendation **APPROVE** — The PR is well-implemented. The core Go change (two-line `envOrDefault` fallback chain for `GITEA_URL`/`GITEA_REPO` → `GITHUB_SERVER_URL`/`GITHUB_REPOSITORY`) is minimal and correct. The workflow files are clearly commented about the intentional Gitea-posting-from-GitHub design. The one MINOR concern worth addressing before relying heavily on the composite action is the `GITHUB_REPOSITORY` fallback in `action.yml` — if a caller omits `repo`, the bot will silently target the wrong Gitea repo. This is low-risk for the described use case (aweiker's mirror explicitly sets the Gitea repo), but could surprise future users of the action. The other findings are documentation/robustness nits. Approve with the suggestion to address the `repo` fallback logic. --- *Review by sonnet* <!-- review-bot:sonnet --> --- *Evaluated against 29ab19c9* </details> <!-- review-bot:sonnet -->
@@ -0,0 +160,4 @@
fi
if [ "$EXPECTED" != "$ACTUAL" ]; then
echo "Error: checksum mismatch!" >&2
echo " Expected: $EXPECTED" >&2
First-time contributor

[MINOR] The GITHUB_REPOSITORY env var is set to ${{ inputs.repo || github.repository }}. When running from GitHub Actions on the mirror repo, github.repository would be aweiker/ai-core-review-bot (or similar), not rodin/review-bot. This means if inputs.repo is not explicitly provided, the review-bot would try to post to the wrong Gitea repository. The composite action's repo input has no default (default: ''), which means the fallback to github.repository is always in play when callers don't pass repo. This could silently produce incorrect behavior rather than a clear error. Consider either making repo required or defaulting it to rodin/review-bot to match the documented intent.

**[MINOR]** The `GITHUB_REPOSITORY` env var is set to `${{ inputs.repo || github.repository }}`. When running from GitHub Actions on the mirror repo, `github.repository` would be `aweiker/ai-core-review-bot` (or similar), not `rodin/review-bot`. This means if `inputs.repo` is not explicitly provided, the review-bot would try to post to the wrong Gitea repository. The composite action's `repo` input has no default (`default: ''`), which means the fallback to `github.repository` is always in play when callers don't pass `repo`. This could silently produce incorrect behavior rather than a clear error. Consider either making `repo` required or defaulting it to `rodin/review-bot` to match the documented intent.
@@ -0,0 +9,4 @@
jobs:
test:
runs-on: ubuntu-24.04
steps:
First-time contributor

[NIT] Go version 1.26 is specified. As of early 2025, Go 1.26 is not yet released (latest stable is 1.23/1.24). If actions/setup-go resolves this to a future version that doesn't exist yet, the job would fail. This likely works today if setup-go tolerates forward-looking versions, but it's worth confirming and possibly pinning to a released version. (The Gitea CI presumably already uses this same version and passes, so this may be a non-issue in practice.)

**[NIT]** Go version `1.26` is specified. As of early 2025, Go 1.26 is not yet released (latest stable is 1.23/1.24). If `actions/setup-go` resolves this to a future version that doesn't exist yet, the job would fail. This likely works today if setup-go tolerates forward-looking versions, but it's worth confirming and possibly pinning to a released version. (The Gitea CI presumably already uses this same version and passes, so this may be a non-issue in practice.)
@@ -0,0 +20,4 @@
AUTHOR=${{ github.event.pull_request.user.login }}
READY_LABEL_ID=38
SELF_REVIEWED_LABEL_ID=37
First-time contributor

[MINOR] Label IDs 38 and 37 are hardcoded without explanation. If the Gitea instance label IDs ever change (e.g., after a data migration or re-creation), this silently does nothing. The comment explains WHY we use Gitea but not WHY these specific numeric IDs are correct. A brief comment naming which labels these IDs correspond to (e.g., # 38 = ready, 37 = self-reviewed) would improve maintainability.

**[MINOR]** Label IDs 38 and 37 are hardcoded without explanation. If the Gitea instance label IDs ever change (e.g., after a data migration or re-creation), this silently does nothing. The comment explains WHY we use Gitea but not WHY these specific numeric IDs are correct. A brief comment naming which labels these IDs correspond to (e.g., `# 38 = ready, 37 = self-reviewed`) would improve maintainability.
Author
Owner

Self-review: PASS

No issues found — ready for human review.

Coherence:

  • The change addresses exactly 8 review findings (4 MAJOR, 4 MINOR) with clear, targeted fixes
  • Each fix is documented in the commit message with specific line references
  • The scope is right: only the files mentioned in the findings are modified

Fit:

  • The codebase already hardcodes gitea.weiker.me in several places (README.md, .gitea/workflows/)
  • The security comment pattern follows the style of existing comments in ci.yml
  • The .gitea/ directory is intentionally different from .github/ - one runs on Gitea (where github.server_url is already Gitea), one runs on GitHub (where it's GitHub's URL)

Solution:

  • Fork protection via github.event.pull_request.head.repo.full_name == github.repository is the standard GitHub Actions pattern
  • Hardcoding https://gitea.weiker.me is appropriate since this is a repo-specific tool, not a general-purpose action
  • The comments explain the "why" for each intentional hardcoding

Completeness:

  • All 4 MAJOR findings addressed
  • All 4 MINOR findings addressed
  • Go code already supports both env var naming conventions (GITEA_URL/GITHUB_SERVER_URL, GITEA_REPO/GITHUB_REPOSITORY)
  • No tests to add (workflow config changes, not code logic)
## Self-review: PASS No issues found — ready for human review. **Coherence:** - The change addresses exactly 8 review findings (4 MAJOR, 4 MINOR) with clear, targeted fixes - Each fix is documented in the commit message with specific line references - The scope is right: only the files mentioned in the findings are modified **Fit:** - The codebase already hardcodes `gitea.weiker.me` in several places (README.md, .gitea/workflows/) - The security comment pattern follows the style of existing comments in ci.yml - The `.gitea/` directory is intentionally different from `.github/` - one runs on Gitea (where `github.server_url` is already Gitea), one runs on GitHub (where it's GitHub's URL) **Solution:** - Fork protection via `github.event.pull_request.head.repo.full_name == github.repository` is the standard GitHub Actions pattern - Hardcoding `https://gitea.weiker.me` is appropriate since this is a repo-specific tool, not a general-purpose action - The comments explain the "why" for each intentional hardcoding **Completeness:** - All 4 MAJOR findings addressed - All 4 MINOR findings addressed - Go code already supports both env var naming conventions (GITEA_URL/GITHUB_SERVER_URL, GITEA_REPO/GITHUB_REPOSITORY) - No tests to add (workflow config changes, not code logic)
rodin added the self-reviewed label 2026-05-11 15:53:51 +00:00
gpt-review-bot approved these changes 2026-05-11 15:54:23 +00:00
gpt-review-bot left a comment
First-time contributor

Original review

Supersededsee current review for up-to-date findings.

Previous findings (commit 29ab19c9)

Gpt Review

Summary

The changes cleanly add GitHub Actions support while preserving existing Gitea behavior. The Go change correctly falls back to GITHUB_* env vars, and the new workflows/composite action appear sound. I found a few minor issues around cache key robustness and a potentially unused input, but nothing blocking.

Findings

# Severity File Line Finding
1 [MINOR] .github/actions/review/action.yml 104 The cache key for the downloaded binary only uses the version (review-bot-linux-amd64-${{ steps.version.outputs.version }}). If inputs.gitea-url or inputs.repo differ between runs but the tag is the same, a stale or wrong binary could be reused without checksum revalidation. Consider including gitea-url and repo in the cache key or validating checksum on cache hits.
2 [MINOR] .github/actions/review/action.yml 169 The environment variable UPDATE_EXISTING is set from the action input, but the main program (cmd/review-bot/main.go) does not currently read or honor this flag. Either wire this through as a flag/env in the application or remove the input to avoid confusion.
3 [MINOR] .github/workflows/release.yml 86 The release job uses jq to URL-encode asset names but doesn't ensure jq is installed. While Ubuntu runners often include jq, it's safer to either install it explicitly or replace this with a Python-based encoding to avoid environment drift.

Recommendation

APPROVE — Overall, this PR achieves its goal of adding GitHub Actions support alongside Gitea with minimal and clear changes. The Go code update to fall back to GITHUB_SERVER_URL and GITHUB_REPOSITORY is straightforward and safe. Please consider hardening the composite action cache key by including the gitea-url and repo so the correct binary is always used, or verify checksums even on cache hits. Also, either plumb the update-existing behavior through to the application or remove the input from the action to keep behavior consistent with configuration. Optionally, ensure jq is present in the release workflow or switch to a Python-based URL encoding for resilience. With these small adjustments, the setup will be more robust; as-is, it's acceptable to merge.


Review by gpt


Evaluated against 29ab19c9

~~Original review~~ **Superseded** — [see current review](https://gitea.weiker.me/rodin/review-bot/pulls/75#pullrequestreview-2561) for up-to-date findings. <details><summary>Previous findings (commit 29ab19c9)</summary> # Gpt Review ## Summary The changes cleanly add GitHub Actions support while preserving existing Gitea behavior. The Go change correctly falls back to GITHUB_* env vars, and the new workflows/composite action appear sound. I found a few minor issues around cache key robustness and a potentially unused input, but nothing blocking. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MINOR] | `.github/actions/review/action.yml` | 104 | The cache key for the downloaded binary only uses the version (review-bot-linux-amd64-${{ steps.version.outputs.version }}). If inputs.gitea-url or inputs.repo differ between runs but the tag is the same, a stale or wrong binary could be reused without checksum revalidation. Consider including gitea-url and repo in the cache key or validating checksum on cache hits. | | 2 | [MINOR] | `.github/actions/review/action.yml` | 169 | The environment variable UPDATE_EXISTING is set from the action input, but the main program (cmd/review-bot/main.go) does not currently read or honor this flag. Either wire this through as a flag/env in the application or remove the input to avoid confusion. | | 3 | [MINOR] | `.github/workflows/release.yml` | 86 | The release job uses `jq` to URL-encode asset names but doesn't ensure `jq` is installed. While Ubuntu runners often include jq, it's safer to either install it explicitly or replace this with a Python-based encoding to avoid environment drift. | ## Recommendation **APPROVE** — Overall, this PR achieves its goal of adding GitHub Actions support alongside Gitea with minimal and clear changes. The Go code update to fall back to GITHUB_SERVER_URL and GITHUB_REPOSITORY is straightforward and safe. Please consider hardening the composite action cache key by including the gitea-url and repo so the correct binary is always used, or verify checksums even on cache hits. Also, either plumb the update-existing behavior through to the application or remove the input from the action to keep behavior consistent with configuration. Optionally, ensure jq is present in the release workflow or switch to a Python-based URL encoding for resilience. With these small adjustments, the setup will be more robust; as-is, it's acceptable to merge. --- *Review by gpt* <!-- review-bot:gpt --> --- *Evaluated against 29ab19c9* </details> <!-- review-bot:gpt -->
@@ -0,0 +101,4 @@
required: false
default: ''
persona-file:
description: 'Path to custom persona JSON file'
First-time contributor

[MINOR] The cache key for the downloaded binary only uses the version (review-bot-linux-amd64-${{ steps.version.outputs.version }}). If inputs.gitea-url or inputs.repo differ between runs but the tag is the same, a stale or wrong binary could be reused without checksum revalidation. Consider including gitea-url and repo in the cache key or validating checksum on cache hits.

**[MINOR]** The cache key for the downloaded binary only uses the version (review-bot-linux-amd64-${{ steps.version.outputs.version }}). If inputs.gitea-url or inputs.repo differ between runs but the tag is the same, a stale or wrong binary could be reused without checksum revalidation. Consider including gitea-url and repo in the cache key or validating checksum on cache hits.
aweiker marked this conversation as resolved
@@ -0,0 +166,4 @@
fi
chmod +x "${{ runner.temp }}/review-bot"
echo "Installed review-bot ${VERSION} (checksum verified)"
First-time contributor

[MINOR] The environment variable UPDATE_EXISTING is set from the action input, but the main program (cmd/review-bot/main.go) does not currently read or honor this flag. Either wire this through as a flag/env in the application or remove the input to avoid confusion.

**[MINOR]** The environment variable UPDATE_EXISTING is set from the action input, but the main program (cmd/review-bot/main.go) does not currently read or honor this flag. Either wire this through as a flag/env in the application or remove the input to avoid confusion.
@@ -0,0 +83,4 @@
if [ -n "$EXISTING_ID" ]; then
echo " Asset ${filename} already exists (id=${EXISTING_ID}), deleting..."
curl -sSf -X DELETE \
First-time contributor

[MINOR] The release job uses jq to URL-encode asset names but doesn't ensure jq is installed. While Ubuntu runners often include jq, it's safer to either install it explicitly or replace this with a Python-based encoding to avoid environment drift.

**[MINOR]** The release job uses `jq` to URL-encode asset names but doesn't ensure `jq` is installed. While Ubuntu runners often include jq, it's safer to either install it explicitly or replace this with a Python-based encoding to avoid environment drift.
aweiker marked this conversation as resolved
security-review-bot requested review from security-review-bot 2026-05-11 15:56:09 +00:00
security-review-bot approved these changes 2026-05-11 15:56:09 +00:00
Dismissed
security-review-bot left a comment
Collaborator

Original review

Supersededsee current review for up-to-date findings.

Previous findings (commit 29ab19c9)

Security Review

Summary

The changes add GitHub Actions support and adapt environment variable handling to work across Gitea and GitHub. CI passed and the modifications do not introduce direct exploitable vulnerabilities, though there are a few defense-in-depth improvements recommended around binary download hardening and network timeouts.

Findings

# Severity File Line Finding
1 [MINOR] .github/actions/review/action.yml 147 The action downloads and executes a binary based on user-provided inputs (gitea-url and repo), and verifies integrity using checksums fetched from the same source. If an untrusted workflow configuration can change these inputs, this allows executing arbitrary code with workflow secrets. Pin the source repository/host, or verify signatures with a trusted key, and avoid allowing untrusted overrides for repo/host.
2 [MINOR] .github/actions/review/action.yml 119 curl invocations lack explicit timeouts, which could lead to hung jobs and potential denial-of-service on runners if the endpoint stalls. Add --connect-timeout and --max-time to bound network operations.
3 [MINOR] .github/actions/review/action.yml 149 Additional curl downloads of the binary and checksums also lack explicit timeouts. Apply connection and overall timeouts to these requests to prevent job hangs.
4 [MINOR] .github/workflows/release.yml 45 Multiple curl API calls (creating/fetching releases and listing/uploading/deleting assets) do not set explicit timeouts, increasing risk of runner hangs. Add --connect-timeout and --max-time to these requests (and subsequent ones at lines ~53, ~79, ~86, ~91) to mitigate DoS via stalled endpoints.
5 [NIT] .github/workflows/pr-ready-gate.yml 40 The JSON payload in the curl PATCH command inlines the AUTHOR variable directly. While GitHub usernames are restricted to safe characters, using a robust JSON encoder or printf %q-style escaping would further reduce injection risk if assumptions change.

Recommendation

APPROVE — Overall the PR is sound and CI has passed. To harden security, consider: (1) pinning the binary download source to a trusted repo/host and/or verifying signatures with a trusted key rather than checksums fetched from the same source, and avoid allowing untrusted overrides to gitea-url and repo for the composite action; (2) adding explicit network timeouts (e.g., --connect-timeout and --max-time) to all curl calls in the composite action and release workflow to prevent runner hangs (DoS); and (3) in the PR ready gate workflow, JSON-encoding dynamic values for defense in depth. These are defense-in-depth improvements and do not block merging.


Review by security


Evaluated against 29ab19c9

~~Original review~~ **Superseded** — [see current review](https://gitea.weiker.me/rodin/review-bot/pulls/75#pullrequestreview-2559) for up-to-date findings. <details><summary>Previous findings (commit 29ab19c9)</summary> # Security Review ## Summary The changes add GitHub Actions support and adapt environment variable handling to work across Gitea and GitHub. CI passed and the modifications do not introduce direct exploitable vulnerabilities, though there are a few defense-in-depth improvements recommended around binary download hardening and network timeouts. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MINOR] | `.github/actions/review/action.yml` | 147 | The action downloads and executes a binary based on user-provided inputs (gitea-url and repo), and verifies integrity using checksums fetched from the same source. If an untrusted workflow configuration can change these inputs, this allows executing arbitrary code with workflow secrets. Pin the source repository/host, or verify signatures with a trusted key, and avoid allowing untrusted overrides for repo/host. | | 2 | [MINOR] | `.github/actions/review/action.yml` | 119 | curl invocations lack explicit timeouts, which could lead to hung jobs and potential denial-of-service on runners if the endpoint stalls. Add --connect-timeout and --max-time to bound network operations. | | 3 | [MINOR] | `.github/actions/review/action.yml` | 149 | Additional curl downloads of the binary and checksums also lack explicit timeouts. Apply connection and overall timeouts to these requests to prevent job hangs. | | 4 | [MINOR] | `.github/workflows/release.yml` | 45 | Multiple curl API calls (creating/fetching releases and listing/uploading/deleting assets) do not set explicit timeouts, increasing risk of runner hangs. Add --connect-timeout and --max-time to these requests (and subsequent ones at lines ~53, ~79, ~86, ~91) to mitigate DoS via stalled endpoints. | | 5 | [NIT] | `.github/workflows/pr-ready-gate.yml` | 40 | The JSON payload in the curl PATCH command inlines the AUTHOR variable directly. While GitHub usernames are restricted to safe characters, using a robust JSON encoder or printf %q-style escaping would further reduce injection risk if assumptions change. | ## Recommendation **APPROVE** — Overall the PR is sound and CI has passed. To harden security, consider: (1) pinning the binary download source to a trusted repo/host and/or verifying signatures with a trusted key rather than checksums fetched from the same source, and avoid allowing untrusted overrides to gitea-url and repo for the composite action; (2) adding explicit network timeouts (e.g., --connect-timeout and --max-time) to all curl calls in the composite action and release workflow to prevent runner hangs (DoS); and (3) in the PR ready gate workflow, JSON-encoding dynamic values for defense in depth. These are defense-in-depth improvements and do not block merging. --- *Review by security* <!-- review-bot:security --> --- *Evaluated against 29ab19c9* </details> <!-- review-bot:security -->
@@ -0,0 +116,4 @@
GITEA_URL="${{ inputs.gitea-url }}"
REPO="${{ inputs.repo || 'rodin/review-bot' }}"
if [ "${{ inputs.version }}" = "latest" ]; then
VERSION=$(curl -sSf "${GITEA_URL}/api/v1/repos/${REPO}/releases?limit=1" \
Collaborator

[MINOR] curl invocations lack explicit timeouts, which could lead to hung jobs and potential denial-of-service on runners if the endpoint stalls. Add --connect-timeout and --max-time to bound network operations.

**[MINOR]** curl invocations lack explicit timeouts, which could lead to hung jobs and potential denial-of-service on runners if the endpoint stalls. Add --connect-timeout and --max-time to bound network operations.
security-review-bot marked this conversation as resolved
@@ -0,0 +144,4 @@
VERSION="${{ steps.version.outputs.version }}"
BINARY="review-bot-linux-amd64"
curl -sSfL "${GITEA_URL}/${REPO}/releases/download/${VERSION}/${BINARY}" \
Collaborator

[MINOR] The action downloads and executes a binary based on user-provided inputs (gitea-url and repo), and verifies integrity using checksums fetched from the same source. If an untrusted workflow configuration can change these inputs, this allows executing arbitrary code with workflow secrets. Pin the source repository/host, or verify signatures with a trusted key, and avoid allowing untrusted overrides for repo/host.

**[MINOR]** The action downloads and executes a binary based on user-provided inputs (gitea-url and repo), and verifies integrity using checksums fetched from the same source. If an untrusted workflow configuration can change these inputs, this allows executing arbitrary code with workflow secrets. Pin the source repository/host, or verify signatures with a trusted key, and avoid allowing untrusted overrides for repo/host.
security-review-bot marked this conversation as resolved
@@ -0,0 +146,4 @@
curl -sSfL "${GITEA_URL}/${REPO}/releases/download/${VERSION}/${BINARY}" \
-o "${{ runner.temp }}/review-bot"
curl -sSfL "${GITEA_URL}/${REPO}/releases/download/${VERSION}/checksums.txt" \
Collaborator

[MINOR] Additional curl downloads of the binary and checksums also lack explicit timeouts. Apply connection and overall timeouts to these requests to prevent job hangs.

**[MINOR]** Additional curl downloads of the binary and checksums also lack explicit timeouts. Apply connection and overall timeouts to these requests to prevent job hangs.
security-review-bot marked this conversation as resolved
@@ -0,0 +37,4 @@
curl -sS -X PATCH \
-H "Authorization: token $GITEA_TOKEN" \
-H "Content-Type: application/json" \
-d "{\"assignees\": [\"${AUTHOR}\"]}" \
Collaborator

[NIT] The JSON payload in the curl PATCH command inlines the AUTHOR variable directly. While GitHub usernames are restricted to safe characters, using a robust JSON encoder or printf %q-style escaping would further reduce injection risk if assumptions change.

**[NIT]** The JSON payload in the curl PATCH command inlines the AUTHOR variable directly. While GitHub usernames are restricted to safe characters, using a robust JSON encoder or printf %q-style escaping would further reduce injection risk if assumptions change.
security-review-bot marked this conversation as resolved
@@ -0,0 +42,4 @@
REPO="rodin/review-bot"
# Create release (or find existing one for this tag)
HTTP_CODE=$(curl -s -o /tmp/release_response.json -w "%{http_code}" -X POST \
Collaborator

[MINOR] Multiple curl API calls (creating/fetching releases and listing/uploading/deleting assets) do not set explicit timeouts, increasing risk of runner hangs. Add --connect-timeout and --max-time to these requests (and subsequent ones at lines ~53, ~79, ~86, ~91) to mitigate DoS via stalled endpoints.

**[MINOR]** Multiple curl API calls (creating/fetching releases and listing/uploading/deleting assets) do not set explicit timeouts, increasing risk of runner hangs. Add --connect-timeout and --max-time to these requests (and subsequent ones at lines ~53, ~79, ~86, ~91) to mitigate DoS via stalled endpoints.
security-review-bot marked this conversation as resolved
rodin force-pushed github-support from 29ab19c94d to dd003c66d5 2026-05-11 15:59:30 +00:00 Compare
sonnet-review-bot approved these changes 2026-05-11 16:00:15 +00:00
sonnet-review-bot left a comment
First-time contributor

Sonnet Review

Summary

This PR adds GitHub Actions support by copying the .gitea/ workflow structure to .github/ and updating main.go to fall back to GITHUB_SERVER_URL/GITHUB_REPOSITORY environment variables when Gitea-specific ones are absent. The changes are minimal, correct, and non-breaking for existing Gitea users. CI passed.

Findings

# Severity File Line Finding
1 [MINOR] .github/actions/review/action.yml 1 The comment at the top says 'This composite action is designed for Gitea Actions runners' but the file is now in .github/ and intended to run on GitHub Actions as well. The comment is misleading for GitHub Actions users who discover this action.
2 [MINOR] .github/workflows/pr-ready-gate.yml 24 The label IDs (READY_LABEL_ID=38, SELF_REVIEWED_LABEL_ID=37) and the hardcoded Gitea URL (https://gitea.weiker.me) are Gitea-specific and will silently no-op (via `
3 [NIT] .github/workflows/ci.yml 14 Go version is set to 1.26 which does not yet exist (current latest stable is 1.24.x). This may cause actions/setup-go to fail on github.com if it cannot resolve the version, whereas Gitea's runner may be more lenient. Consider pinning to an actual released version or using stable.
4 [NIT] .github/actions/review/action.yml 100 The Determine version step hardcodes REPO as 'rodin/review-bot' for the download source. On GitHub, this repo may not exist or be accessible, meaning the Install review-bot step would fail for GitHub Actions users trying to use this composite action from the public mirror. This is likely intentional (the composite action is primarily for Gitea) but deserves a comment.

Recommendation

APPROVE — The core change in main.go is correct and idiomatic — using nested envOrDefault calls to fall back from Gitea-specific to GitHub-specific environment variables is clean and backward-compatible. The workflow files are valid YAML and structurally correct for their intended environments. The MINOR findings are documentation/clarity issues rather than functional bugs; the NIT about Go version 1.26 is worth fixing if this repo is actually being mirrored to github.com and CI needs to pass there. Overall this is a safe, well-scoped change that achieves its goal.


Review by sonnet


Evaluated against dd003c66

# Sonnet Review ## Summary This PR adds GitHub Actions support by copying the `.gitea/` workflow structure to `.github/` and updating `main.go` to fall back to `GITHUB_SERVER_URL`/`GITHUB_REPOSITORY` environment variables when Gitea-specific ones are absent. The changes are minimal, correct, and non-breaking for existing Gitea users. CI passed. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MINOR] | `.github/actions/review/action.yml` | 1 | The comment at the top says 'This composite action is designed for Gitea Actions runners' but the file is now in `.github/` and intended to run on GitHub Actions as well. The comment is misleading for GitHub Actions users who discover this action. | | 2 | [MINOR] | `.github/workflows/pr-ready-gate.yml` | 24 | The label IDs (READY_LABEL_ID=38, SELF_REVIEWED_LABEL_ID=37) and the hardcoded Gitea URL (`https://gitea.weiker.me`) are Gitea-specific and will silently no-op (via `|| true`) on GitHub Actions. This is acceptable for now since the workflow is a Gitea-only feature, but it means the workflow is essentially a dead stub on GitHub. A comment explaining this would reduce confusion. | | 3 | [NIT] | `.github/workflows/ci.yml` | 14 | Go version is set to `1.26` which does not yet exist (current latest stable is 1.24.x). This may cause `actions/setup-go` to fail on github.com if it cannot resolve the version, whereas Gitea's runner may be more lenient. Consider pinning to an actual released version or using `stable`. | | 4 | [NIT] | `.github/actions/review/action.yml` | 100 | The `Determine version` step hardcodes `REPO` as `'rodin/review-bot'` for the download source. On GitHub, this repo may not exist or be accessible, meaning the `Install review-bot` step would fail for GitHub Actions users trying to use this composite action from the public mirror. This is likely intentional (the composite action is primarily for Gitea) but deserves a comment. | ## Recommendation **APPROVE** — The core change in `main.go` is correct and idiomatic — using nested `envOrDefault` calls to fall back from Gitea-specific to GitHub-specific environment variables is clean and backward-compatible. The workflow files are valid YAML and structurally correct for their intended environments. The MINOR findings are documentation/clarity issues rather than functional bugs; the NIT about Go version 1.26 is worth fixing if this repo is actually being mirrored to github.com and CI needs to pass there. Overall this is a safe, well-scoped change that achieves its goal. --- *Review by sonnet* <!-- review-bot:sonnet --> --- *Evaluated against dd003c66*
@@ -0,0 +1,200 @@
# This composite action is designed for Gitea Actions runners.
First-time contributor

[MINOR] The comment at the top says 'This composite action is designed for Gitea Actions runners' but the file is now in .github/ and intended to run on GitHub Actions as well. The comment is misleading for GitHub Actions users who discover this action.

**[MINOR]** The comment at the top says 'This composite action is designed for Gitea Actions runners' but the file is now in `.github/` and intended to run on GitHub Actions as well. The comment is misleading for GitHub Actions users who discover this action.
@@ -0,0 +97,4 @@
required: false
default: ''
persona:
description: 'Built-in persona name (security, architect, docs)'
First-time contributor

[NIT] The Determine version step hardcodes REPO as 'rodin/review-bot' for the download source. On GitHub, this repo may not exist or be accessible, meaning the Install review-bot step would fail for GitHub Actions users trying to use this composite action from the public mirror. This is likely intentional (the composite action is primarily for Gitea) but deserves a comment.

**[NIT]** The `Determine version` step hardcodes `REPO` as `'rodin/review-bot'` for the download source. On GitHub, this repo may not exist or be accessible, meaning the `Install review-bot` step would fail for GitHub Actions users trying to use this composite action from the public mirror. This is likely intentional (the composite action is primarily for Gitea) but deserves a comment.
aweiker marked this conversation as resolved
@@ -0,0 +11,4 @@
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-go@v5
First-time contributor

[NIT] Go version is set to 1.26 which does not yet exist (current latest stable is 1.24.x). This may cause actions/setup-go to fail on github.com if it cannot resolve the version, whereas Gitea's runner may be more lenient. Consider pinning to an actual released version or using stable.

**[NIT]** Go version is set to `1.26` which does not yet exist (current latest stable is 1.24.x). This may cause `actions/setup-go` to fail on github.com if it cannot resolve the version, whereas Gitea's runner may be more lenient. Consider pinning to an actual released version or using `stable`.
@@ -0,0 +21,4 @@
# Remove ready label if present
curl -sS -X DELETE \
-H "Authorization: token $GITEA_TOKEN" \
"https://gitea.weiker.me/api/v1/repos/${{ github.repository }}/issues/${PR_NUMBER}/labels/${READY_LABEL_ID}" || true
First-time contributor

[MINOR] The label IDs (READY_LABEL_ID=38, SELF_REVIEWED_LABEL_ID=37) and the hardcoded Gitea URL (https://gitea.weiker.me) are Gitea-specific and will silently no-op (via || true) on GitHub Actions. This is acceptable for now since the workflow is a Gitea-only feature, but it means the workflow is essentially a dead stub on GitHub. A comment explaining this would reduce confusion.

**[MINOR]** The label IDs (READY_LABEL_ID=38, SELF_REVIEWED_LABEL_ID=37) and the hardcoded Gitea URL (`https://gitea.weiker.me`) are Gitea-specific and will silently no-op (via `|| true`) on GitHub Actions. This is acceptable for now since the workflow is a Gitea-only feature, but it means the workflow is essentially a dead stub on GitHub. A comment explaining this would reduce confusion.
security-review-bot requested review from security-review-bot 2026-05-11 16:01:09 +00:00
security-review-bot approved these changes 2026-05-11 16:01:09 +00:00
security-review-bot left a comment
Collaborator

Security Review

Summary

Changes add GitHub Actions support and environment fallbacks without introducing clear security vulnerabilities. Secrets are handled via environment variables, downloads are over HTTPS with checksum verification, and input parsing/validation logic in Go remains safe.

Recommendation

APPROVE — CI passed and the changes appear security-conscious: no hardcoded secrets, no dangerous deserialization, and sensible validation for workspace paths and reviewer names. The composite action verifies checksums and avoids logging sensitive values. As a defense-in-depth improvement for future work, consider pinning versions explicitly in workflows and limiting the source host for binary downloads where feasible, or using signed artifacts. Otherwise, this PR is good to merge.


Review by security


Evaluated against dd003c66

# Security Review ## Summary Changes add GitHub Actions support and environment fallbacks without introducing clear security vulnerabilities. Secrets are handled via environment variables, downloads are over HTTPS with checksum verification, and input parsing/validation logic in Go remains safe. ## Recommendation **APPROVE** — CI passed and the changes appear security-conscious: no hardcoded secrets, no dangerous deserialization, and sensible validation for workspace paths and reviewer names. The composite action verifies checksums and avoids logging sensitive values. As a defense-in-depth improvement for future work, consider pinning versions explicitly in workflows and limiting the source host for binary downloads where feasible, or using signed artifacts. Otherwise, this PR is good to merge. --- *Review by security* <!-- review-bot:security --> --- *Evaluated against dd003c66*
aweiker approved these changes 2026-05-11 16:01:52 +00:00
gpt-review-bot requested changes 2026-05-11 16:02:02 +00:00
gpt-review-bot left a comment
First-time contributor

Gpt Review

Summary

The Go code change to accept GITHUB_* fallbacks is small and idiomatic, but the overall GitHub Actions integration mixes GitHub context with Gitea-specific APIs and clients. As written, the review and release workflows will attempt to talk to GitHub using Gitea endpoints, which will fail outside your Gitea instance. Please separate provider handling or adjust URLs and clients accordingly.

Findings

# Severity File Line Finding
1 [MAJOR] cmd/review-bot/main.go 56 Defaults now fall back to GITHUB_SERVER_URL/GITHUB_REPOSITORY for --gitea-url/--repo, but the bot constructs a Gitea client and calls Gitea v1 APIs. On GitHub, GITHUB_SERVER_URL is https://github.com and lacks /api/v1; this will cause API calls to fail. Either keep requiring explicit GITEA_URL/GITEA_REPO when targeting Gitea, or add a GitHub client and switch on provider.
2 [MAJOR] .github/workflows/ci.yml 49 The review job sets GITHUB_SERVER_URL and GITHUB_REPOSITORY and runs ./review-bot, which will use those to target a Gitea client. On GitHub PRs this points to github.com and will not match Gitea APIs, leading to failures when fetching PRs/diffs and posting reviews. Pass a real Gitea URL if the bot should review on Gitea, or implement a GitHub path.
3 [MAJOR] .github/workflows/release.yml 48 Release step uses GITEA_URL="${{ github.server_url }}" and then calls "${GITEA_URL}/api/v1/repos/.../releases". On GitHub, server_url is https://github.com (GitHub releases live at api.github.com and use different endpoints). This will not work on GitHub. Use GitHub's REST API (or an action like softprops/action-gh-release) when running on GitHub, and keep the Gitea API for Gitea.
4 [MINOR] .github/actions/review/action.yml 91 The composite action constructs download and release URLs assuming a Gitea server (e.g., /api/v1 and /releases/download paths). If this action is intended to run on GitHub, it should detect the provider and use GitHub's API for version discovery and asset downloads; otherwise document it as Gitea-only to avoid confusion.
5 [MINOR] .github/workflows/pr-ready-gate.yml 23 This job calls a hardcoded Gitea instance (https://gitea.weiker.me) using GitHub event data. On GitHub PRs, the PR number and repo may not exist on that instance, which could fail the job. Consider scoping this job to your Gitea environment or guarding it with conditions so it doesn't run (or fail) on GitHub.

Recommendation

REQUEST_CHANGES — The Go code change itself is fine, but the current approach conflates GitHub context with Gitea-specific APIs and clients, which will break when running on GitHub. To resolve:

  • In cmd/review-bot/main.go, do not implicitly treat GITHUB_SERVER_URL/REPOSITORY as a Gitea endpoint. Either keep Gitea-only defaults (require GITEA_URL/GITEA_REPO when targeting Gitea) or introduce a provider flag and implement a GitHub client path for GitHub PRs (select client based on provider).
  • In .github/workflows/release.yml, detect the platform: use GitHub's release API (or an existing action) when running on GitHub; keep the current Gitea API when running on Gitea. Do not rely on github.server_url with Gitea /api/v1 endpoints.
  • In .github/workflows/ci.yml review job, either pass explicit GITEA_URL/GITEA_REPO to target your Gitea instance (if reviews are posted there), or add a GitHub-aware bot path and switch behavior based on provider.
  • If the composite action is intended to be Gitea-only, clearly document it and avoid using GitHub context variables as fallbacks. If it should also work on GitHub, add provider detection and separate code paths for version discovery and asset retrieval.
  • Consider guarding pr-ready-gate to run only in your Gitea environment or make its calls conditional so it can't fail on GitHub.
    These changes will make the GitHub Actions integration reliable and align the bot's API usage with the actual hosting provider.

Review by gpt


Evaluated against dd003c66

# Gpt Review ## Summary The Go code change to accept GITHUB_* fallbacks is small and idiomatic, but the overall GitHub Actions integration mixes GitHub context with Gitea-specific APIs and clients. As written, the review and release workflows will attempt to talk to GitHub using Gitea endpoints, which will fail outside your Gitea instance. Please separate provider handling or adjust URLs and clients accordingly. ## Findings | # | Severity | File | Line | Finding | |---|----------|------|------|--------| | 1 | [MAJOR] | `cmd/review-bot/main.go` | 56 | Defaults now fall back to GITHUB_SERVER_URL/GITHUB_REPOSITORY for --gitea-url/--repo, but the bot constructs a Gitea client and calls Gitea v1 APIs. On GitHub, GITHUB_SERVER_URL is https://github.com and lacks /api/v1; this will cause API calls to fail. Either keep requiring explicit GITEA_URL/GITEA_REPO when targeting Gitea, or add a GitHub client and switch on provider. | | 2 | [MAJOR] | `.github/workflows/ci.yml` | 49 | The review job sets GITHUB_SERVER_URL and GITHUB_REPOSITORY and runs ./review-bot, which will use those to target a Gitea client. On GitHub PRs this points to github.com and will not match Gitea APIs, leading to failures when fetching PRs/diffs and posting reviews. Pass a real Gitea URL if the bot should review on Gitea, or implement a GitHub path. | | 3 | [MAJOR] | `.github/workflows/release.yml` | 48 | Release step uses GITEA_URL="${{ github.server_url }}" and then calls "${GITEA_URL}/api/v1/repos/.../releases". On GitHub, server_url is https://github.com (GitHub releases live at api.github.com and use different endpoints). This will not work on GitHub. Use GitHub's REST API (or an action like softprops/action-gh-release) when running on GitHub, and keep the Gitea API for Gitea. | | 4 | [MINOR] | `.github/actions/review/action.yml` | 91 | The composite action constructs download and release URLs assuming a Gitea server (e.g., /api/v1 and /releases/download paths). If this action is intended to run on GitHub, it should detect the provider and use GitHub's API for version discovery and asset downloads; otherwise document it as Gitea-only to avoid confusion. | | 5 | [MINOR] | `.github/workflows/pr-ready-gate.yml` | 23 | This job calls a hardcoded Gitea instance (https://gitea.weiker.me) using GitHub event data. On GitHub PRs, the PR number and repo may not exist on that instance, which could fail the job. Consider scoping this job to your Gitea environment or guarding it with conditions so it doesn't run (or fail) on GitHub. | ## Recommendation **REQUEST_CHANGES** — The Go code change itself is fine, but the current approach conflates GitHub context with Gitea-specific APIs and clients, which will break when running on GitHub. To resolve: - In cmd/review-bot/main.go, do not implicitly treat GITHUB_SERVER_URL/REPOSITORY as a Gitea endpoint. Either keep Gitea-only defaults (require GITEA_URL/GITEA_REPO when targeting Gitea) or introduce a provider flag and implement a GitHub client path for GitHub PRs (select client based on provider). - In .github/workflows/release.yml, detect the platform: use GitHub's release API (or an existing action) when running on GitHub; keep the current Gitea API when running on Gitea. Do not rely on github.server_url with Gitea /api/v1 endpoints. - In .github/workflows/ci.yml review job, either pass explicit GITEA_URL/GITEA_REPO to target your Gitea instance (if reviews are posted there), or add a GitHub-aware bot path and switch behavior based on provider. - If the composite action is intended to be Gitea-only, clearly document it and avoid using GitHub context variables as fallbacks. If it should also work on GitHub, add provider detection and separate code paths for version discovery and asset retrieval. - Consider guarding pr-ready-gate to run only in your Gitea environment or make its calls conditional so it can't fail on GitHub. These changes will make the GitHub Actions integration reliable and align the bot's API usage with the actual hosting provider. --- *Review by gpt* <!-- review-bot:gpt --> --- *Evaluated against dd003c66*
@@ -0,0 +88,4 @@
description: 'Print review to stdout instead of posting'
required: false
default: 'false'
update-existing:
First-time contributor

[MINOR] The composite action constructs download and release URLs assuming a Gitea server (e.g., /api/v1 and /releases/download paths). If this action is intended to run on GitHub, it should detect the provider and use GitHub's API for version discovery and asset downloads; otherwise document it as Gitea-only to avoid confusion.

**[MINOR]** The composite action constructs download and release URLs assuming a Gitea server (e.g., /api/v1 and /releases/download paths). If this action is intended to run on GitHub, it should detect the provider and use GitHub's API for version discovery and asset downloads; otherwise document it as Gitea-only to avoid confusion.
@@ -0,0 +46,4 @@
- uses: actions/setup-go@v5
with:
go-version: '1.26'
- run: go build -o review-bot ./cmd/review-bot
First-time contributor

[MAJOR] The review job sets GITHUB_SERVER_URL and GITHUB_REPOSITORY and runs ./review-bot, which will use those to target a Gitea client. On GitHub PRs this points to github.com and will not match Gitea APIs, leading to failures when fetching PRs/diffs and posting reviews. Pass a real Gitea URL if the bot should review on Gitea, or implement a GitHub path.

**[MAJOR]** The review job sets GITHUB_SERVER_URL and GITHUB_REPOSITORY and runs ./review-bot, which will use those to target a Gitea client. On GitHub PRs this points to github.com and will not match Gitea APIs, leading to failures when fetching PRs/diffs and posting reviews. Pass a real Gitea URL if the bot should review on Gitea, or implement a GitHub path.
@@ -0,0 +20,4 @@
# Remove ready label if present
curl -sS -X DELETE \
-H "Authorization: token $GITEA_TOKEN" \
First-time contributor

[MINOR] This job calls a hardcoded Gitea instance (https://gitea.weiker.me) using GitHub event data. On GitHub PRs, the PR number and repo may not exist on that instance, which could fail the job. Consider scoping this job to your Gitea environment or guarding it with conditions so it doesn't run (or fail) on GitHub.

**[MINOR]** This job calls a hardcoded Gitea instance (https://gitea.weiker.me) using GitHub event data. On GitHub PRs, the PR number and repo may not exist on that instance, which could fail the job. Consider scoping this job to your Gitea environment or guarding it with conditions so it doesn't run (or fail) on GitHub.
@@ -0,0 +45,4 @@
-H "Authorization: token ${GITEA_TOKEN}" \
-H "Content-Type: application/json" \
"${GITEA_URL}/api/v1/repos/${REPO}/releases" \
-d "{\"tag_name\": \"${VERSION}\", \"name\": \"${VERSION}\", \"body\": \"Release ${VERSION}\", \"draft\": false, \"prerelease\": false}")
First-time contributor

[MAJOR] Release step uses GITEA_URL="${{ github.server_url }}" and then calls "${GITEA_URL}/api/v1/repos/.../releases". On GitHub, server_url is https://github.com (GitHub releases live at api.github.com and use different endpoints). This will not work on GitHub. Use GitHub's REST API (or an action like softprops/action-gh-release) when running on GitHub, and keep the Gitea API for Gitea.

**[MAJOR]** Release step uses GITEA_URL="${{ github.server_url }}" and then calls "${GITEA_URL}/api/v1/repos/.../releases". On GitHub, server_url is https://github.com (GitHub releases live at api.github.com and use different endpoints). This will not work on GitHub. Use GitHub's REST API (or an action like softprops/action-gh-release) when running on GitHub, and keep the Gitea API for Gitea.
@@ -54,8 +54,8 @@ func main() {
logFormat := flag.String("log-format", envOrDefault("LOG_FORMAT", "text"), "Log output format: text or json")
verbosity := flag.String("verbosity", envOrDefault("LOG_VERBOSITY", "info"), "Log verbosity: debug, info, warn, error")
// CLI flags
First-time contributor

[MAJOR] Defaults now fall back to GITHUB_SERVER_URL/GITHUB_REPOSITORY for --gitea-url/--repo, but the bot constructs a Gitea client and calls Gitea v1 APIs. On GitHub, GITHUB_SERVER_URL is https://github.com and lacks /api/v1; this will cause API calls to fail. Either keep requiring explicit GITEA_URL/GITEA_REPO when targeting Gitea, or add a GitHub client and switch on provider.

**[MAJOR]** Defaults now fall back to GITHUB_SERVER_URL/GITHUB_REPOSITORY for --gitea-url/--repo, but the bot constructs a Gitea client and calls Gitea v1 APIs. On GitHub, GITHUB_SERVER_URL is https://github.com and lacks /api/v1; this will cause API calls to fail. Either keep requiring explicit GITEA_URL/GITEA_REPO when targeting Gitea, or add a GitHub client and switch on provider.
rodin closed this pull request 2026-05-11 16:08:42 +00:00
Author
Owner

Converting to long-lived feature branch. The workflows alone won't work without the VCS abstraction (#76).

Will merge as one unit when complete:

  • .github/ workflows
  • github/ client package (ported from strat fork)
  • vcs/ abstraction layer
  • cmd/review-bot wiring

Branch: github-support

Converting to long-lived feature branch. The workflows alone won't work without the VCS abstraction (#76). Will merge as one unit when complete: - `.github/` workflows - `github/` client package (ported from strat fork) - `vcs/` abstraction layer - `cmd/review-bot` wiring Branch: `github-support`
Some checks are pending
PR Ready Gate / clear-labels (pull_request) Successful in 2s
CI / test (pull_request) Successful in 18s
CI / review (anthropic--claude-4.6-sonnet, sonnet, SONNET_REVIEW_TOKEN) (pull_request) Successful in 38s
CI / review (gpt-5, security, ., rodin/security-patterns, SECURITY_REVIEW.md, SECURITY_REVIEW_TOKEN) (pull_request) Successful in 1m21s
CI / review (gpt-5, gpt, GPT_REVIEW_TOKEN) (pull_request) Successful in 2m14s

Pull request closed

Sign in to join this conversation.
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rodin/review-bot#75