chore(ci): remove stale public-api from build and deploy workflows

[maskarb]

Summary

• Remove all public-api references from components-build-deploy.yml and prod-release-deploy.yaml
• The public-api component is no longer used; its presence in the workflows was stale

Test plan

• Verify workflow syntax is valid (GitHub Actions lint)
• Confirm no other workflows reference public-api

🤖 Generated with Claude Code

[coderabbitai]

Walkthrough

This PR removes all references to the public-api component from two CI/CD workflow files. Changes include excluding public-api from build matrices, image tagging, Dockerfile paths, deployment conditions, and kustomize image updates across component build/deploy and production release workflows.

Changes

Cohort / File(s)	Summary
CI/CD Workflow Component Removal .github/workflows/components-build-deploy.yml, .github/workflows/prod-release-deploy.yaml	Removed public-api component from build matrices, image tagging logic, deployment steps, and kustomize overlays. Updated workflow descriptions and conditions to eliminate public-api references across path filters, build outputs, and environment configuration.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• fix(ci): add ambient-api-server to deploy-to-openshift workflow #867 — Modifies the same workflow files' component build/deploy matrix, with inverse changes (adding/adjusting public-api and introducing ambient-api-server).

Suggested reviewers

• Gkrumbach07

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: removing stale public-api references from CI workflows.
Description check	✅ Passed	The description is directly related to the changeset, explaining what public-api references were removed and why, with a test plan included.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch fix/ci-remove-stale-public-api

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/components-build-deploy.yml (1)

276-279: ⚠️ Potential issue | 🟠 Major

Remove public-api from production deployment or manage its release cycle separately.

The production overlay will deploy public-api because:

• Line 14 includes ../../base, which contains public-api-deployment.yaml (base/kustomization.yaml:15)
• Line 18 explicitly includes public-api-route.yaml
• Lines 110-115 override the image to use unpinned latest tag with pull policy Always

This means oc apply -k . will continuously deploy public-api with an unpinned tag that is never updated by the build workflow, leaving it stale in production.

Either remove public-api from the base kustomization (line 15) and production route resource (line 18), or establish a separate release process for public-api image builds (currently lines 193-197 in Makefile still reference it).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/components-build-deploy.yml around lines 276 - 279, The
production overlay currently deploys public-api via
components/manifests/overlays/production (oc apply -k .) because the base
kustomization includes public-api-deployment.yaml and the production overlay
includes public-api-route.yaml, and image overrides use an unpinned "latest" tag
with imagePullPolicy: Always; remove public-api from the base kustomization and
from the production overlay (remove public-api-deployment.yaml and
public-api-route.yaml references) OR implement a separate release process for
public-api (pin image tags in the production overlay kustomize imageTransformer
or kustomization.yaml and change imagePullPolicy to IfNotPresent/Always only
when appropriate), and update the Makefile references to public-api so the build
workflow no longer assumes production auto-deploys that image.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In @.github/workflows/components-build-deploy.yml:
- Around line 276-279: The production overlay currently deploys public-api via
components/manifests/overlays/production (oc apply -k .) because the base
kustomization includes public-api-deployment.yaml and the production overlay
includes public-api-route.yaml, and image overrides use an unpinned "latest" tag
with imagePullPolicy: Always; remove public-api from the base kustomization and
from the production overlay (remove public-api-deployment.yaml and
public-api-route.yaml references) OR implement a separate release process for
public-api (pin image tags in the production overlay kustomize imageTransformer
or kustomization.yaml and change imagePullPolicy to IfNotPresent/Always only
when appropriate), and update the Makefile references to public-api so the build
workflow no longer assumes production auto-deploys that image.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: ea01d0dc-99a6-4e09-937f-df591bc1eff5

📥 Commits

Reviewing files that changed from the base of the PR and between 5d96404 and c424d15.

📒 Files selected for processing (2)

• .github/workflows/components-build-deploy.yml
• .github/workflows/prod-release-deploy.yaml

[github-actions]

Claude Code Review

Summary

PR 870 removes stale public-api references from two CI/CD workflow files (components-build-deploy.yml and prod-release-deploy.yaml). The changes are internally consistent and the CI/CD cleanup is executed correctly — all trigger paths, change-detection outputs, build matrix entries, deploy conditions, and image-tag overrides are removed in both files. However, the Kustomize manifests still fully declare and deploy the public-api component, creating a meaningful disconnect between CI/CD and the actual deployed workload.

Issues by Severity

Blocker Issues

None

Critical Issues

None

Major Issues

1. Kustomize manifests still deploy public-api — image will no longer be updated

The public-api component is removed from CI/CD but the Kustomize manifests still include it in every overlay:

• components/manifests/base/kustomization.yaml includes public-api-deployment.yaml as a resource and declares a vteam_public_api image
• components/manifests/overlays/production/kustomization.yaml has image overrides for vteam_public_api (lines 110-114) and includes public-api-route.yaml
• components/manifests/overlays/kind/kustomization.yaml has an image override (line 100) and a nodeport patch (lines 49, 52)
• components/manifests/overlays/kind-local/kustomization.yaml has a local image override (lines 53-54)

Before this PR the deploy workflow applied a kustomize edit set image command to pin vteam_public_api to the current commit SHA. After this PR that line is gone, so public-api will continue to be deployed on every production push using whatever tag was last written into the overlay — potentially a stale or latest tag — while no new image is ever built.

Required resolution (pick one):

• Preferred (if truly deprecated): Remove public-api manifests in the same PR or a closely-coupled follow-up, so the component is not deployed at all.
• Alternative (if still needed): Keep the component in CI/CD and keep building it.

This is Major rather than Blocker because the running pod itself keeps serving (stale image, no crash), but it creates a real maintenance gap: security patches to public-api can no longer be shipped automatically.

Minor Issues

1. CLAUDE.md still lists public-api as an active component

CLAUDE.md line 15 describes components/public-api/ as an active component. If this component is deprecated, the documentation should be updated to reflect that.

2. PR test-plan item not verified

The test plan includes an unchecked item: "Confirm no other workflows reference public-api". This is verifiable (a search confirms no remaining references in .github/workflows/) but should be checked off before merge to signal explicit validation.

Positive Highlights

• Thorough sweep across both workflow files. Every location where public-api appeared — push-trigger paths, PR-trigger paths, dorothy path filter, change-detection outputs, build matrix, deploy if condition, image-tag computation block, and kustomize edit set image commands — is consistently removed from both workflow files. No dangling references remain in .github/workflows/.
• Clean conventional commit message (chore(ci):) aligned with the project squash-merge conventions.
• Good PR description clearly states intent and provides a lightweight test plan.

Recommendations

1. (Most important) Decide the fate of public-api explicitly. If it is deprecated, remove its manifests (components/manifests/base/public-api-deployment.yaml, the overlay patches, and the kustomization entries) so the pod is not deployed. If it is still needed, revert its removal from CI/CD.
2. Update CLAUDE.md to remove or annotate the public-api component entry.
3. Check off the test-plan verification item — the search confirms it is clean.

---

Review performed by Claude Code using repository-specific standards from the Amber memory system.

---

🔍 View AI decision process (logs available for 90 days)

📋 View memory system files loaded (click to expand)

What Amber Loaded for Code Review

Amber automatically loaded these repository standards from the memory system:

1. CLAUDE.md - Master project instructions, development standards
2. backend-development.md - Go backend, K8s integration patterns
3. frontend-development.md - NextJS, Shadcn UI, React Query patterns
4. security-standards.md - Auth, RBAC, token handling
5. k8s-client-usage.md - User token vs service account patterns
6. error-handling.md - Consistent error patterns
7. react-query-usage.md - Data fetching patterns

Impact: This review used your repository's specific code quality standards, security patterns, and best practices from the memory system (PRs #359, #360) - not just generic code review guidelines.

[markturansky]

hold until the new API is fully functional

[ambient-code]

Review Queue — Not Ready to Merge

@markturansky requested to hold this PR until the new API is fully functional (comment from March 10). The PR correctly removes public-api from CI/CD workflows, but the Kustomize manifests still reference it, which means the deployed image won't receive updates.

CI is passing and there are no merge conflicts, but this is a coordination issue — we're removing the old API from builds before the new replacement is production-ready.

To unblock: @markturansky needs to confirm the new API is ready and lift the hold request.