feat: git hash arg for deploy #434
Reference in New Issue
Block a user
No description provided.
Delete Branch "git-hash-arg"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
See coop-cloud/organising#517.
I changed the design and actually don't allow git hashes on
upgrade/rollback.This is due to there being loooooads of logic which does comparisons, release notes, etc. for versions in those commands. It's hard to separate that all from this chaos commit path. Also, the UI is unclear: do I
deploy/upgrade/rollbackto deploy a chaos commit? And when is a chaos commit arollbackand not anupgradein relation to aversion?This could technically be worked out but I think it's easier to just say "you're on your own" for chaos commits on
deploy. And the UI surface fordeployis the "center for chaos". Thenupgrade/rollbackdeals exclusively with recipe versions and deployments which remove "chaos".Some additional cleaning commits re: docstrings. Stuff was out-of-date or duplicated elsewhere, so I made it more terse. Also additional tests for stuff when I was poking around in the
upgrade/rollbackcode.Nice stuff! And I agree with the design decision
Finally 🚀 I really like this feature 🥳
But I'm not sure if it's a good idea if you're not able to
upgradeto any arbitrary version. Especially to test a version before releasing it.Can you not test the new version using abra app deploy --chaos?
Sorry you are right, I forgot that
abra app deploy --chaosis mostly doing the same likeabra app upgarde --chaos, as it also doing an in-place upgrade and I don't need to undeploy the app.Nice! afair
abra app deploy <hash>will trigger a chaos deploy, no--chaosrequired 😌 And yes, the behaviour ofupgrade/rollbackis now finally changing fromdeploy. which is IMHO a good thing and less confusing. just we need to change our habits 🙃