[KCM-6031] FinOps Agent release automation - #210
Conversation
|
hey @thomasvn are we still looking to drop this in? |
|
@peatey Still need to validate that it works. Also, the current implementation uses a PAT, which we may want to move away from. Update it to use Github Apps instead. |
There was a problem hiding this comment.
This workflow automates the FinOps Agent release across three repositories with appropriate security controls (scoped GitHub App tokens, tag collision checks, dry-run mode). The orchestration logic is sound with proper polling and error handling for cross-repo dependencies. Two medium-severity issues warrant attention: hardcoded workflow names create fragile cross-repo dependencies that will timeout silently if renamed, and the dry-run mode skips Chart.lock regeneration, creating a validation gap for dependency resolution.
Overall: Looks good with minor comments.
No CI evidence was available for this review (Release automation workflow; no test coverage expected for GHA workflows themselves.).
A couple of observations for the reviewer:
- The workflow's dry-run mode is well-designed: it uses
git push --dry-runto validate auth and ref updates without landing changes, and skips side-effect-dependent steps. This is a good pattern for testing release automation. - The polling logic for cross-repo workflow starts uses a 2-minute timeout with 5-second intervals, which is reasonable for GitHub Actions dispatch latency. The
${RUN_ID:?...}bash expansion ensures the script fails loudly if the workflow never appears. - The workflow correctly uses
needs:dependencies to enforce the release sequence (tag → build → chart → kubecost), preventing partial releases if an earlier step fails.
Posting this with high confidence. Both findings confirmed through direct file inspection; workflow structure and cross-repo contract are well-understood.
Reviewed by the Redline bot. This is an automated first-pass review;
a human reviewer is still required.
Addresses KCM-6031