feat(#2479): enable Renovate via self-hosted GitHub App

[rh-hemartin]

Summary

• Add .github/workflows/renovate.yml — runs self-hosted Renovate twice daily, authenticates via dedicated GitHub App using actions/create-github-app-token
• Update renovate.json — add gomodTidy post-update and prHourlyLimit: 1

Closes #2479

Test plan

• Trigger workflow manually with dry-run to verify app token generation works
• Verify Renovate opens dependency PRs on next scheduled run

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Enable Renovate via self-hosted GitHub App token in GitHub Actions
✨ Enhancement ⚙️ Configuration changes 🕐 10-20 Minutes

Description

• Add a scheduled GitHub Actions workflow to run Renovate twice daily.
• Authenticate Renovate using a dedicated GitHub App token (no PAT required).
• Tune Renovate behavior with gomodTidy post-update and a 1 PR/hour cap.

Diagram

graph TD
  A["Renovate workflow"] --> B["create-github-app-token"] --> C["Renovate action"] --> D{{"GitHub API"}}
  C --> E["renovate.json"]

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Use Renovate GitHub App (hosted) instead of self-hosting

• ➕ No workflow/runtime maintenance (scheduling, runner availability, action versioning)
• ➕ App updates handled by Renovate team
• ➖ Less control over execution environment and rollout cadence
• ➖ May not satisfy org requirements for self-hosting or network egress controls

2. Authenticate via fine-scoped PAT (classic or fine-grained)

• ➕ Simpler setup (no GitHub App key management)
• ➕ Easier local reproduction
• ➖ Higher secret-risk profile and rotation burden
• ➖ Often broader permissions than a dedicated App installation

3. Run Renovate as a container job (pinned image)

• ➕ Tighter control over Renovate version and runtime dependencies
• ➕ Can standardize execution across repos
• ➖ More YAML and operational complexity than the GitHub Action wrapper
• ➖ Requires Docker runtime considerations and image update process

Recommendation: The PR’s approach (self-hosted Renovate run + GitHub App token) is a strong default when you want least-privilege, revocable access without PATs and you’re already comfortable operating GitHub Actions workflows. Consider the hosted Renovate App only if you want to eliminate workflow maintenance and don’t need self-hosting controls.

Files changed (2) +39 / -0

Other (2) +39 / -0

renovate.ymlAdd scheduled Renovate workflow using GitHub App authentication +37/-0

Add scheduled Renovate workflow using GitHub App authentication

• Introduces a GitHub Actions workflow that runs on a twice-daily cron and via manual dispatch with an optional dry-run input. The workflow generates a GitHub App installation token via 'actions/create-github-app-token@v2' and runs Renovate using 'renovatebot/github-action@v42' with that token.

.github/workflows/renovate.yml

renovate.jsonLimit Renovate PR rate and enable Go module tidy post-update +2/-0

Limit Renovate PR rate and enable Go module tidy post-update

• Adds 'prHourlyLimit: 1' to reduce PR churn and enables 'postUpdateOptions: ["gomodTidy"]' so Go module updates run 'go mod tidy' after dependency changes.

renovate.json

[github-actions]

Site preview

Preview: https://f8647c66-site.fullsend-ai.workers.dev

Commit: d239601b112a5ec34e78a265e183b8319dd51a79

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (1) 📜 Skill insights (0)

Context used

✅ Tickets: 🎫 Enable Renovate via self-hosted GitHub App

✅ Compliance rules (platform): 51 rules

✅ Skills: writing-user-docs, writing-adrs

1. permissions: {} blocks checkout 📎 Requirement gap ☼ Reliability

Description

The Renovate workflow sets permissions: {}, which removes all GITHUB_TOKEN permissions but still
runs actions/checkout@v4, so checkout may be unable to read repository contents and the scheduled
Renovate run can fail before Renovate executes. This violates the requirement that the scheduled
Renovate workflow executes successfully.

Code

.github/workflows/renovate.yml[R17-30]

+permissions: {}
+
+jobs:
+  renovate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: actions/create-github-app-token@v2
+        id: app-token
+        with:
+          app-id: ${{ vars.RENOVATE_APP_ID }}
+          private-key: ${{ secrets.RENOVATE_PRIVATE_KEY }}
+

Relevance

⭐⭐⭐ High

Team previously added explicit contents: read permissions alongside actions/checkout in
workflows (e.g., PRs #2106, #1215).

PR-#2106
PR-#1215

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062108 requires that Renovate runs on schedule and executes successfully, but
.github/workflows/renovate.yml explicitly sets permissions: {} and then invokes
actions/checkout@v4, which typically relies on the default GITHUB_TOKEN and needs at least
contents: read to fetch the repository when no alternate token is supplied. Unlike other workflows
in the repo that either grant contents: read when using checkout (e.g., lint.yml) or override
permissions at the job level when workflow-level permissions are empty (e.g., e2e.yml), the
Renovate workflow does neither, making a failed scheduled execution likely.

Add Renovate GitHub Actions workflow scheduled to run twice daily using GitHub App token
.github/workflows/renovate.yml[17-30]
.github/workflows/renovate.yml[17-24]
.github/workflows/lint.yml[10-18]
.github/workflows/e2e.yml[7-58]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The Renovate workflow disables all default `GITHUB_TOKEN` permissions by setting `permissions: {}`, but still runs `actions/checkout@v4` without providing an alternate token or adding job/workflow permissions. This can prevent checkout from reading the repository contents and cause the scheduled Renovate job to fail before Renovate runs.

## Issue Context
Compliance requires not just that the Renovate workflow file exists, but that scheduled runs execute successfully (PR Compliance ID 1062108). With empty permissions, `actions/checkout@v4` commonly needs `contents: read` when using the default `GITHUB_TOKEN`; since the workflow neither grants that permission nor supplies a different token, it risks failing early. Other workflows in this repo address this by explicitly granting `contents: read` for checkout or by adding job-level permissions even when workflow-level permissions are `{}`.

## Fix Focus Areas
- .github/workflows/renovate.yml[17-30]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[fullsend-ai-review]

🤖 Review · ⚠️ Cancelled · Started 8:21 AM UTC · Ended 8:25 AM UTC
Commit: 4e21a60 · View workflow run →

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 8:32 AM UTC · Completed 8:47 AM UTC
Commit: 721a5f5 · View workflow run →

[fullsend-ai-review]

Review

Findings

Medium

• [protected-path] .github/workflows/renovate.yml — This PR adds a file under .github/, which is a protected path requiring human approval. The PR links to issue Enable Renovate via self-hosted GitHub App #2479 and provides rationale for the change. Human review is required regardless of automated review outcome.

Low

• [architectural-coherence] .github/workflows/renovate.yml — The PR introduces dependency update automation (Renovate bot). The security-threat-model.md document explicitly addresses dependency updates ("Dependency update PRs should be treated with the same scrutiny as external PRs") and raises an open question about whether they should be in a separate autonomy tier. There is no documentation on how fullsend's own dependency updates fit into the threat model and intent framework.
  Remediation: Consider documenting how fullsend's own dependency updates fit into the threat model. Alternatively, confirm that CODEOWNERS coverage (currently wildcard to @fullsend-ai/core) provides sufficient human oversight for Renovate-generated PRs.

Previous run

Review

Findings

Medium

• [protected-path] .github/workflows/renovate.yml — This PR adds a file under .github/, which is a protected path requiring human approval. The PR links to issue Enable Renovate via self-hosted GitHub App #2479 and provides rationale for the change. Human review is required regardless of automated review outcome.

• [action-version-pinning] .github/workflows/renovate.yml:23 — The workflow uses major-only tag references (@v7, @v3, @v46). While the repository does not uniformly use SHA pinning, most workflows pin to specific semver tags (e.g., @v6.0.2, @v5.0.0). Major-only tags are mutable and can shift without notice.
  Remediation: Pin to specific semver tags (e.g., @v7.2.0) matching the pattern in lint.yml and release.yml.

• [workflow-naming-convention] .github/workflows/renovate.yml:10 — The workflow_dispatch input uses dry_run (snake_case), but branch-cleanup.yml uses dry-run (kebab-case) for an equivalent input. Inconsistent naming across workflows.
  Remediation: Rename the input to dry-run and update the reference on line 37 to inputs.dry-run.

• [architectural-misalignment] .github/workflows/renovate.yml:23 — Uses actions/checkout@v7 while all other workflows use @v6 or @v6.0.2. This would be the only workflow on v7, creating a version inconsistency.
  Remediation: Use actions/checkout@v6.0.2 to match existing workflows, or coordinate a repo-wide upgrade.

Low

• [permission-expansion] .github/workflows/renovate.yml:31 — The GitHub App installation token passed to Renovate has permissions determined by the App's installation config, which cannot be verified from the diff. Verify the App is scoped to only the permissions Renovate requires (contents:write, pull-requests:write, issues:read|write, checks:write).

• [documentation-gap] .github/workflows/renovate.yml — No documentation explains the RENOVATE_APP_ID and RENOVATE_PRIVATE_KEY secrets or how to set up the Renovate GitHub App for new installations.
  Remediation: Add operational setup instructions in docs/guides/infrastructure/ or as a comment block in the workflow file.

---

Labels: PR adds a CI workflow for dependency management via Renovate.

[fullsend-ai-review]

See the review comment for full details.

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 11:40 AM UTC · Completed 11:50 AM UTC
Commit: d239601 · View workflow run →

[ralphbean]

LGTM.

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 9:29 AM UTC · Completed 9:43 AM UTC
Commit: d239601 · View workflow run →

[fullsend-ai-retro]

Retro: PR #2480 — Enable Renovate via self-hosted GitHub App

Timeline

1. 08:17 UTC — PR opened by rh-hemartin (2 files: new .github/workflows/renovate.yml + renovate.json update)
2. 08:18 UTC — First review dispatched (run 27939130151) — cancelled due to force push at 08:24
3. 08:25 UTC — Second review dispatched (run 27939498755) — completed successfully
4. 08:47 UTC — Review posted 4 medium + 2 low findings; requires-manual-review label applied
5. 11:33 UTC — Author dismissed version-pinning and naming-convention findings as "Won't fix"
6. 11:37 UTC — Author force-pushed; third review dispatched (run 27949826229) — completed, re-applied requires-manual-review
7. 13:48 UTC — Human reviewer (ralphbean) approved with "LGTM"
8. 09:25 UTC +1d — PR merged

Assessment

All 4 inline review comments were dismissed or irrelevant, meaning the review agent added friction without catching real issues on this PR. Three of the four dismissed findings map to recently-addressed or already-tracked issues:

• Version skew (checkout@v7 vs @v6 in other workflows) → covered by #2499 (closed 2026-06-22)
• Naming convention factual accuracy → covered by #1835 (closed 2026-06-22)
• Re-review re-applying labels → tracked in #2116 and #963 (both open)

One finding has no existing coverage: the review agent flagging major-version GitHub Actions tags (@v7, @v3, @v46) as needing exact semver pins. This is standard practice and creates unnecessary noise. A proposal is filed below.

Proposals filed

• Review agent should accept major-version GitHub Actions tags as valid pinning strategy (in fullsend-ai/fullsend)