kelos-dev / kelos-dev/kelos

New use case: Intelligent dependency upgrade validation with Dependabot/Renovate PR agent workflows

Open
#722 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

generated-by-kelos kind/feature needs-actor priority/backlog triage-accepted
Dominant language
Go
Stars
331
Forks
40
Avg merge
1d 21h
Merged PRs (30d)
70

Description

🤖 Kelos Strategist Agent @gjkim42

Summary

Propose a new use case for Kelos: automated dependency upgrade validation that goes beyond what Dependabot and Renovate provide. While those tools create PRs for version bumps, they cannot analyze breaking changes, adapt application code, run contextual tests, or provide risk assessments. Kelos agents can fill this gap by watching for dependency update PRs and performing intelligent validation and migration.

This is a high-value workflow that nearly every team faces weekly but currently handles manually.

Problem

Dependabot and Renovate are excellent at detecting outdated dependencies and creating version bump PRs. But they stop there. Developers still need to:

  1. Read the changelog and release notes for the new version
  2. Identify breaking changes and their impact on the codebase
  3. Update code to adapt to API changes, renamed functions, or changed behavior
  4. Verify the update doesn't break tests or introduce regressions
  5. Assess risk and decide whether to merge immediately or defer

For active repositories with many dependencies, this manual review cycle consumes significant developer time. Most Dependabot PRs sit unmerged for weeks because the review burden is too high.

Proposed Solution

Use a Kelos TaskSpawner with githubPullRequests source to watch for Dependabot/Renovate PRs and automatically validate them. The existing author filter on GitHubPullRequests (api/v1alpha1/taskspawner_types.go:233) already supports filtering by bot username.

Example TaskSpawner Configuration
apiVersion: kelos.dev/v1alpha1
kind: TaskSpawner
metadata:
  name: dependency-upgrade-validator
spec:
  when:
    githubPullRequests:
      author: "dependabot[bot]"  # or "renovate[bot]"
      state: open
      labels:
        - "dependencies"
      reporting:
        enabled: true
  taskTemplate:
    type: claude-code
    credentials:
      type: api-key
      secretRef:
        name: anthropic-credentials
    model: sonnet
    workspaceRef:
      name: my-app
    branch: "{{.Branch}}"
    ttlSecondsAfterFinished: 3600
    promptTemplate: |
      You are a dependency upgrade validation agent. A dependency update PR has been created automatically.

      PR #{{.Number}}: {{.Title}}
      URL: {{.URL}}
      Branch: {{.Branch}}

      {{if .Body}}
      PR Description:
      {{.Body}}
      {{end}}

      Your task:
      1. **Identify the dependency and version change** from the PR diff
      2. **Fetch and analyze the changelog** — use `gh api` or the package registry to read
         release notes between the old and new versions
      3. **Assess breaking changes** — search the codebase for usage of any deprecated or
         removed APIs mentioned in the changelog
      4. **Adapt code if needed** — if the upgrade introduces breaking changes that affect
         this codebase, update the code to be compatible with the new version
      5. **Run the test suite** — execute `make test` and report results
      6. **Post a structured review** on the PR with:
         - Risk assessment (low / medium / high)
         - Summary of changes in the new version
         - Breaking changes found (if any) and how they were resolved
         - Test results
         - Recommendation (safe to merge / needs human review / defer)

      If you made code changes to adapt to the upgrade, commit them to the PR branch.
      If no code changes are needed and tests pass, approve the PR.
      If tests fail or breaking changes require human judgment, request changes with details.
  pollInterval: "15m"
  maxConcurrency: 2
Alternative: Renovate Bot
  when:
    githubPullRequests:
      author: "renovate[bot]"
      labels:
        - "renovate"
Multi-ecosystem variant with label-based routing

For repositories with many dependency types, use separate spawners with label filters:

# Major version upgrades get Opus for deeper analysis
apiVersion: kelos.dev/v1alpha1
kind: TaskSpawner
metadata:
  name: dep-validator-major
spec:
  when:
    githubPullRequests:
      author: "dependabot[bot]"
      labels: ["dependencies", "major"]
  taskTemplate:
    type: claude-code
    model: opus  # More capable model for major upgrades
    # ... (deeper analysis prompt)
---
# Minor/patch upgrades get Sonnet for quick validation
apiVersion: kelos.dev/v1alpha1
kind: TaskSpawner
metadata:
  name: dep-validator-minor
spec:
  when:
    githubPullRequests:
      author: "dependabot[bot]"
      excludeLabels: ["major"]
      labels: ["dependencies"]
  taskTemplate:
    type: claude-code
    model: sonnet  # Faster model for low-risk updates
    # ... (lightweight validation prompt)

Why This Is Different From Existing Tools

Capability Dependabot/Renovate Kelos Agent
Detect outdated deps ❌ (relies on Dependabot)
Create version bump PR ❌ (relies on Dependabot)
Read and analyze changelog
Detect breaking changes in codebase
Adapt code to breaking changes
Run tests with contextual understanding
Provide risk assessment
Auto-approve safe updates

The key insight is that Kelos complements Dependabot/Renovate rather than replacing them. Dependabot handles the discovery and version bump; Kelos handles the intelligent validation and code adaptation.

Evidence From Codebase

This use case is well-supported by existing Kelos features:

  1. author filter on GitHubPullRequests source (api/v1alpha1/taskspawner_types.go:233, internal/source/github_pr.go:203) — already supports filtering by bot username
  2. excludeLabels filter — enables routing major vs minor upgrades to different agents
  3. branch template with {{.Branch}} — agent works directly on Dependabot's branch
  4. reporting.enabled — agent posts status back to the PR
  5. model selection — risk-appropriate model selection per upgrade severity
  6. Existing pattern: The kelos-pr-responder self-development TaskSpawner already demonstrates the pattern of agents iterating on PRs created by other actors

Potential API Enhancements

While the current API supports the basic workflow, these enhancements (some already proposed) would make it more powerful:

  • #563 (failurePolicy with model escalation) — if Sonnet can't resolve a breaking change, automatically retry with Opus
  • #540 (retriggerOn) — re-run validation when Dependabot force-pushes a rebase
  • reviewState filter — skip PRs the agent already approved (use reviewState: any and check in prompt, or add agent-aware review state tracking)

Target Audience

  • Application teams with 20+ dependencies getting weekly Dependabot PRs
  • Platform teams managing dependency policies across multiple repositories
  • Open-source maintainers who receive Dependabot PRs on many repos
  • Regulated industries that need documented risk assessment for every dependency change

/kind feature

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with api/v1alpha1/taskspawner_types.go:233 and internal/source/github_pr.go:203 to understand the existing GitHub pull-request filters, then inspect the kelos-pr-responder TaskSpawner pattern. Determine which parts of the proposed dependency-validation workflow are already supported and which API or controller changes are required. Done means the supported workflow and any required enhancements are implemented with relevant validation and tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, go, kubernetes, yaml
Domain
ai, ci-cd, devops
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.