Conditional deployment based on version changes

[mucsi96]

Summary

Updated the CI/CD pipeline to only trigger deployments when actual version changes are detected in either the server or client packages, and removed unnecessary tool setup steps from the deploy job.

Key Changes

• Added outputs to both publish-server and publish-client jobs to expose the hasNextVersion flag from the version detection step
• Modified the deploy job's conditional to only run when at least one of the published packages has a new version (hasNextVersion == 'true')
• Removed azure/setup-helm and azure/setup-kubectl actions from the deploy job as they are no longer needed

Implementation Details

The deploy job now depends on the output of the publish jobs to determine if a deployment is necessary. This prevents unnecessary deployments when there are no version changes, optimizing CI/CD resource usage and reducing noise in deployment logs.

https://claude.ai/code/session_01Nmah5EbZ3m52ot23XTaf5e

[claude]

Code Review

Overall this is a clean, focused change that improves CI/CD efficiency. A few observations:

Positive

• Smart use of job outputs to propagate hasNextVersion — the pattern is idiomatic for GitHub Actions.
• The || condition correctly handles the case where only one of the two packages has a version bump.
• Removing redundant setup steps is good housekeeping.

Concerns

1. Removing setup-helm / setup-kubectl — verify the deploy job still works

The deploy job presumably still runs helm or kubectl commands in steps not shown in this diff. If those commands are present and the tools are no longer installed by the runner image by default, deployments will silently fail at runtime rather than at the setup step.

Recommendation: confirm that either (a) the remaining deploy steps no longer invoke helm/kubectl directly, or (b) the runner image (ubuntu-latest) has the required versions pre-installed and pinned to acceptable versions. Azure's setup-helm/setup-kubectl actions allow version pinning — removing them trades reproducibility for speed.

2. Output availability when a job fails

If publish-server or publish-client exits with a non-zero status, GitHub Actions marks the job as failed and its outputs are empty strings. The deploy job is already blocked via needs, so the condition == 'true' would be falsy anyway — this is safe. Just worth being aware of so future debugging of a blocked deploy looks at the publish job logs first.

3. Minor: condition line length

The if: line in the deploy job is now quite long. Consider extracting the version-check logic into a dedicated check-versions job that outputs a single shouldDeploy flag, keeping the deploy job's if: readable:

if: github.event_name == 'push' && github.ref == 'refs/heads/main' && needs.check-versions.outputs.shouldDeploy == 'true'

This is purely cosmetic but pays off as more services are added.

Summary

The core logic is correct and the optimization is worthwhile. The main thing to verify before merging is that the deploy job's remaining steps don't depend on the removed tool-setup actions.