Consolidate Manifest Deployment Steps in Deploy Template Workflow

[RachalCassity]

Keep your PR as a Draft until it's ready for Platform review. A PR is ready for Platform review when it has a teammate approval and tests, linting, and settings checks pass CI. See these tips on how to avoid common delays in getting your PR merged.

Summary

Two separate workflow steps that updated image tags and DataDog version secrets in the manifest repo have been merged into a single unified step.

Previously the workflow used two hardcoded steps — one targeting dev and staging using the vets-api-parent chart key, and a second targeting prod and sandbox using vets-api. This was brittle because the chart key was assumed based on environment name rather than verified against the actual values.yaml.

The new step iterates over all four environments and uses yq's has() function to detect which chart key is present in each environment's values.yaml at runtime, storing the results in variables rather than piping through grep to avoid pipefail interaction issues. If both keys are found in the same file the workflow exits with a non-zero code rather than silently applying the wrong key. If neither key is found the environment is skipped with a warning.

Expected behavior:

• Removes duplicated yq commands across two steps into a single shared block
• Eliminates hardcoded environment-to-chart-key assumptions — the correct key is detected from the file itself
• Fails loudly if both keys are present rather than silently defaulting to one
• Removes unused ECR_REGISTRY and ECR_REPOSITORY env vars that were never referenced in the run block

Related issue(s)

• Move Vets-API Parent Helm Chart from vets-api repo to vsp-infra-application-manifests va.gov-team#134551
• Deploy SHA tags to vets-api-parent for dev and staging #27573

Testing done

• New code is covered by unit tests
• Describe what the old behavior was prior to the change
• Describe the steps required to verify your changes are working as expected. Exclusively stating 'Specs run' is NOT acceptable as appropriate testing
• If this work is behind a flipper:
  • Tests need to be written for both the flipper on and flipper off scenarios. Docs.
  • What is the testing plan for rolling out the feature?

Screenshots

Note: Optional

What areas of the site does it impact?

(Describe what parts of the site are impacted andifcode touched other areas)

Acceptance criteria

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No error nor warning in the console.
• Events are being sent to the appropriate logging solution
• Documentation has been updated (link to documentation)
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Feature/bug has a monitor built into Datadog (if applicable)
• If app impacted requires authentication, did you login to a local build and verify all authenticated routes work as expected
• I added a screenshot of the developed feature

Requested Feedback

(OPTIONAL)What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[Copilot]

Pull request overview

This PR refactors the GitHub Actions deploy workflow template to consolidate how the manifests repo is updated with the new image tag and Datadog version/commit values across multiple environments.

Changes:

• Combine the previous per-environment update loops into a single loop over dev, staging, prod, and sandbox.
• Add logic to detect whether values.yaml uses vets-api-parent vs vets-api as the chart key and update accordingly.
• Keep a single git diff output after applying all yq edits.

[jweissman]

Looks good -- happy to approve but left some comments that might be good to reflect on. The only big-picture suggestion might be incorporating -e flag to set exit code (in which case we could add || exit 1 to bail if something is missing but you're handling that otherwise so maybe fine!)