chore(deps): update ghcr.io/doublewordai/control-layer docker tag to v8

[renovate]

This PR contains the following updates:

Package	Update	Change
ghcr.io/doublewordai/control-layer	major	0.25.0 → 8.50.0

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[doubleword-code]

Summary

This PR is an automated dependency update from Renovate that bumps the appVersion in Chart.yaml from 0.25.0 to 8.46.0. This is a major version upgrade (0.x → 8.x) for the underlying ghcr.io/doublewordai/control-layer application image. The change affects the default image tag used in deployments since the template references .Chart.AppVersion when no explicit tag is provided.

Findings

• Non-blocking Chart.yaml:6: Major version upgrade (0.25.0 → 8.46.0) without accompanying documentation about breaking changes or migration requirements. Consider adding a note in the PR description or updating CHANGELOG.md with a link to the upstream application's release notes.

• Non-blocking CHANGELOG.md: The changelog tracks chart version history but does not document application version updates. Consider adding an entry noting the appVersion bump to help users track what application version each chart release deploys.

• Nit tests/control_layer_deployment_test.yaml:7-23: The test "should create control-layer deployment with default appVersion" only validates the image format regex but doesn't assert the specific version. Adding a version assertion would catch unintended appVersion changes during review.

• Nit values.yaml:52: The image.tag is set to "" (empty string), which relies on the default .Chart.AppVersion behavior in the template. This is correct but could be clearer with a comment noting this intentional defaulting behavior.

Suggested next steps

This is a straightforward automated dependency update. Before merging:

1. Verify the upstream control-layer v8 release notes for any breaking changes that might affect deployments (e.g., configuration schema changes, required environment variables, or database migration requirements).
2. Optionally update CHANGELOG.md to document this appVersion update for user visibility.
3. Ensure any downstream environments are prepared for the major version upgrade if they rely on the default image tag.

[doubleword-code]

Summary

This PR updates the appVersion in Chart.yaml from 0.25.0 to 8.46.1, which controls the default Docker image tag for the control-layer deployment. This is an automated Renovate dependency update.

Verdict: The chart change itself is correct and follows the established pattern. However, this is a major version jump (0.x → 8.x) in the application version, which warrants verification that the new image version is compatible with the existing chart templates and default values before merging.

Research Notes

• Fetched renovate.json configuration confirming the appVersion is automatically updated from the Docker registry (datasourceTemplate: docker)
• Verified in templates/deployment.yaml:42 that Chart.AppVersion is used as the default image tag when image.tag is not explicitly set
• Checked existing tests in tests/control_layer_deployment_test.yaml - they validate image format but not specific version compatibility
• Reviewed CHANGELOG.md showing historical appVersion updates have been routine
• Attempted to fetch available Docker tags from GHCR but authentication was required

Suggested Next Steps

1. Review control-layer application changelog (if available) for breaking changes between v0.25.0 and v8.46.1 - particularly around:

   • Configuration file format changes
   • Environment variable changes
   • Health check endpoint changes (/healthz)
   • Database schema migrations

2. Test the new image in a non-production environment to verify:

   • Pod starts successfully with current default values
   • Health probes pass
   • Secret mounting works correctly
   • ConfigMap configuration is compatible

3. Consider pinning image.tag in production values files rather than relying on appVersion defaults if you need more control over rollout timing.

General Findings

No issues found with the actual code change. The single-line modification to Chart.yaml is the correct approach for updating the default container image version in a Helm chart.

[doubleword-code]

Summary

This PR updates the appVersion in Chart.yaml from 0.25.0 to 8.46.3, representing a major version jump (v0 → v8) of the control-layer Docker image. The change is automatically generated by Renovate.

Verdict: Needs changes - While the dependency update itself is straightforward, there are several concerns with this major version bump that should be addressed before merging.

Research notes

• Fetched https://github.com/doublewordai/control-layer - confirms v8.46.3 was released today (May 7, 2026)
• Fetched https://docs.doubleword.ai/control-layer/ - Control Layer is an AI model gateway written in Rust
• The repository uses Renovate with Docker versioning for appVersion tracking (renovate.json lines 9-14)
• Image tag resolution in deployment templates uses .Values.image.tag | default .Chart.AppVersion

Suggested next steps

1. Blocking: Increment the chart version in Chart.yaml alongside this major appVersion change (Helm best practice)
2. Non-blocking: Review control-layer v8 release notes for breaking changes that might affect deployments
3. Non-blocking: Consider testing the rendered Helm templates with the new version before deploying to production

General findings

Major version jump without changelog review

The jump from 0.25.0 to 8.46.3 crosses multiple major versions. Per semantic versioning, major version increments can include breaking changes. The PR description doesn't include any migration notes or changelog references. Teams deploying this should verify compatibility with their existing configurations, especially:

• Database schema migrations (control-layer uses PostgreSQL)
• Configuration file format changes
• API endpoint compatibility
• Authentication/session handling changes

Chart version should be incremented

Per Helm chart best practices, when updating appVersion (especially across major versions), the chart version should also be incremented. This allows users to distinguish between chart releases and ensures proper version tracking in Helm repositories.

[doubleword-code]

Summary

This PR updates the appVersion in Chart.yaml from 0.25.0 to 8.49.0, which controls the default Docker image tag for the control-layer service. This is a major version jump (0.x → 8.x) managed by Renovate bot.

The change is mechanically correct - only the single version field is modified, and the Helm templates will correctly use this new version as the default image tag. No code changes required; ready to merge pending operational validation.

Research notes

• Fetched the GitHub repository page to confirm this is a Helm chart for deploying the Doubleword control layer service
• Verified templates/deployment.yaml:42 uses .Chart.AppVersion as the default image tag when image.tag is not explicitly set
• Confirmed renovate.json is configured with regexManager to track Docker image versions via the appVersion field
• Test suite (tests/control_layer_deployment_test.yaml) validates image format but not specific version compatibility

Suggested next steps

1. Verify upstream changelog: Review release notes for control-layer versions 0.25.0 → 8.49.0 to identify any breaking changes that might require configuration updates (environment variables, config schema, database migrations, etc.)
2. Test deployment in non-production environment: Deploy with the new image version and verify:
   • Application starts successfully
   • Health checks pass (/healthz endpoint)
   • Database migrations run correctly (if applicable)
   • Existing configuration remains compatible
3. Check resource requirements: Major version jumps may change CPU/memory requirements - verify current resource limits are still appropriate

General findings

Non-blocking consideration: The test at tests/control_layer_deployment_test.yaml:7 is named "should create control-layer deployment with default appVersion" but only validates that the image matches the pattern ^ghcr\.io/doublewordai/control-layer:.*$ - it doesn't assert the specific version. This is acceptable for a generic test, but teams relying on tests to catch version mismatches may want to add a test that explicitly validates the Chart.yaml appVersion field propagates correctly to the deployment image.