Problem
Currently, the Helm release process is completely manual and decoupled from the main application release.
After building and releasing a new version of the application, anyone can enter any version number freely when triggering a Helm release. This makes it very easy to:
- Use a version that doesn't match the actual application release
- Introduce typos or incorrect versions
- Cause a mismatch between the application version and the Helm chart version
These inconsistencies lead to deployment confusion, troubleshooting difficulties, and potential production issues.
Expected Behavior
The Helm release dispatch workflow should be improved to ensure the Helm chart version always stays in sync with the application release.
Proposed Solution:
- When triggering a Helm release, instead of a free-text input field, provide a dropdown list containing all available versions from the existing releases.
- Users should only be able to select a version that has already been successfully released.
- The selected version should be automatically used as the Helm chart version.
This change will eliminate manual errors and guarantee that the Helm version remains perfectly synchronized with the application version.
Acceptance Criteria
Problem
Currently, the Helm release process is completely manual and decoupled from the main application release.
After building and releasing a new version of the application, anyone can enter any version number freely when triggering a Helm release. This makes it very easy to:
These inconsistencies lead to deployment confusion, troubleshooting difficulties, and potential production issues.
Expected Behavior
The Helm release dispatch workflow should be improved to ensure the Helm chart version always stays in sync with the application release.
Proposed Solution:
This change will eliminate manual errors and guarantee that the Helm version remains perfectly synchronized with the application version.
Acceptance Criteria