Rollback aware auto-sync
# Summary Currently auto-sync and rollback do not play nicely together. To perform a rollback auto-sync has to be disabled first and if reenabled happily will sync again to the commit that was rolled back previously. If argo remembered the commit that got rolled back and excluded it from auto-sync this would improve that situation a lot. This might be the same or a similar issue as https://github.com/argoproj/argo-cd/issues/5351 but I found the issue description really unclear. # Motivation What has to happen when a rollback is needed currently entails multiple steps to get an application back on track: 1. disable auto-sync 2. perform rollback 3. revert/fix the offending commit in git 4. reenable auto-sync If auto-sync excluded the offending commit this would be reduced to 1. perform rollback 2. revert/fix the offending commit in git Apart from saving a developer a bit of manual effort, where this feature would be really useful is for automating rollbacks. We currently tinker with using a post-sync hook for running some tests against our application and would like to automatically rollback using a fail hook (via the argo api [^1]). When a developer then releases a fix, the application would automatically sync again and everything would be back to normal. [^1]: it appears this would currently not work without some level of indirection due to https://github.com/argoproj/argo-cd/issues/6494. Maybe one could use a argo-workflow that starts another workflow to do the roll
Posted by stereobutter on Jun 2, 2022, 2:18 PM
Tags
Related issues
- [BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
- Feature Request: Auto-resume CLI session when usage limit resets
- Please deobfuscate the Python
- [Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
- # 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
- [FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
reliability (Software)
[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixe
Feature Request: Auto-resume CLI session when usage limit resets
Please deobfuscate the Python
[Bug] MLX version of Gemma 4 26B fails to load: "Model type gemma4 not supported" (macOS)
# 233 Developers Discussed Abandoning the Office Add-in Platform — An Open Letter on the Office.js Stability, Security & Trust Crisis
[FEATURE] Allow users to configure which shell the Bash tool uses or inherit initial shell
Admin Materials and Surfaces
AMD Support
Rollback aware auto-sync
# Summary Currently auto-sync and rollback do not play nicely together. To perform a rollback auto-sync has to be disabled first and if reenabled happily will sync again to the commit that was rolled back previously. If argo remembered the commit that got rolled back and excluded it from auto-sync this would improve that situation a lot. This might be the same or a similar issue as https://github.com/argoproj/argo-cd/issues/5351 but I found the issue description really unclear. # Motivation What has to happen when a rollback is needed currently entails multiple steps to get an application back on track: 1. disable auto-sync 2. perform rollback 3. revert/fix the offending commit in git 4. reenable auto-sync If auto-sync excluded the offending commit this would be reduced to 1. perform rollback 2. revert/fix the offending commit in git Apart from saving a developer a bit of manual effort, where this feature would be really useful is for automating rollbacks. We currently tinker with using a post-sync hook for running some tests against our application and would like to automatically rollback using a fail hook (via the argo api [^1]). When a developer then releases a fix, the application would automatically sync again and everything would be back to normal. [^1]: it appears this would currently not work without some level of indirection due to https://github.com/argoproj/argo-cd/issues/6494. Maybe one could use a argo-workflow that starts another workflow to do the roll
Comments (0)
No comments yet. Start the discussion.