Inheriting AnalysisTemplates from deployed files

[lantern-sam]

Checklist

• [x] I've searched the issue queue to verify this is not a duplicate feature request.
• [x] I've pasted the output of kargo version, if applicable.
• [ ] I've pasted logs, if applicable.

Version: v1.3.2

Proposed Feature

I would like a Kargo Stage to be able to inherit an Analysis Template from an Argo rollout which is deployed via Kargo rather than it being a predefined template that is triggered by Kargo.

Motivation

When deploying our applications we use a flow like this:

• Builds a Helm Chart with specific values
• That Helm Chart will create an Argo Rollout with an AnalysisTemplate
• The rollout will only deploy the new pod if the AnalysisRun comes back successfully

Currently we infer that the AnalysisRun has passed due to the ArgoCD health check however it's possible that it could pass the AnalysisRun and then some other resource is failing.

Ideally I'd like to make it so that the stage inherits the AnalysisRun from the rollout so it can be seen in the Kargo application, especially with the possible addition of logs coming in the (near?) future.

I assume that specifying the AnalysisTemplate in the Stage would cause a duplicate to run which is not desired.

Suggested Implementation

If there is a way I could work around this by appending labels / annotations to the AnalysisRuns then I would be happy with that tbh 👀 Long term there might be an optional setting where it will automatically patch those annotations / labels onto AnalysisRuns/AnalysisTemplates. it could essentially just do a kustomize patch targeting Analysis resources.

[krancour]

I'll let @jessesuen weigh in here, but imho, there might be a misunderstanding of why or how Kargo uses AnalysisTemplates.

WRT to Argo Rollouts Rollout resources, AnalysisTemplates are used to answer the question "How's the Rollout (deployment) going?"

Kargo isn't really about deployments. It is specifically about promotions -- doing the behind-the-scenes work to, stage-by-stage, put your desired state (stored in your repo) in, well... the desired state. (A meta-deployment, if you will.)

Verification, which happens to be implemented using AnalysisTemplates (because they were designed for reuse in other contexts), isn't intended to answer the question of "How's the deployment going?" It's intended to answer an entirely different, higher-level question, which is "Is the new state satisfactory?" This makes verification a good fit for things like smoke tests or automated acceptance tests.

In short, any AnalysisTemplates you use with verification and any you use along with your Rollouts are addressing entirely different use cases, and in light of this, the proposed feature may not be as useful as presumed.

[github-actions[bot]]

This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again.