feat: git hash arg for deploy #434

2024-07-09T09:42:39Z

decentral1se commented

2024-07-09 09:42:39 +00:00

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/rollback to deploy a chaos commit? And when is a chaos commit a rollback and not an upgrade in relation to a version?

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 for deploy is the "center for chaos". Then upgrade/rollback deals 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/rollback code.

See https://git.coopcloud.tech/coop-cloud/organising/issues/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`/`rollback` to deploy a chaos commit? And when is a chaos commit a `rollback` and not an `upgrade` in relation to a `version`? 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 for `deploy` is the "center for chaos". Then `upgrade`/`rollback` deals 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`/`rollback` code.

🎉 2

decentral1se added 6 commits 2024-07-09 09:42:39 +00:00

docs: pass on sub-command help 0ff8e49cfd

feat: support chaos commits on deploy 2fb5493ab5

See coop-cloud/organising#517

refactor: debug logging and errors for version issues 71d93cbbea

fix: ensure force upgrade/rollback works 00d60f7114

refactor: make IsChaos an actual bool b82ac3bd63

test: recipe test fixups

continuous-integration/drone/pr Build is passing

Details

continuous-integration/drone/push Build is passing

Details

7f910b4e5b

decentral1se merged commit 7f910b4e5b into main

2024-07-09 09:42:57 +00:00

decentral1se deleted branch git-hash-arg

2024-07-09 09:42:58 +00:00

decentral1se referenced this pull request from toolshed/organising

2024-07-09 09:43:24 +00:00

deploy/upgrade/rollback version arguments can be git hash #517

p4u1 commented

2024-07-09 16:50:59 +00:00

Nice stuff! And I agree with the design decision

❤️ 1

moritz commented

2024-07-15 16:10:49 +00:00

Finally 🚀 I really like this feature 🥳
But I'm not sure if it's a good idea if you're not able to upgrade to any arbitrary version. Especially to test a version before releasing it.

Finally 🚀 I really like this feature 🥳 But I'm not sure if it's a good idea if you're not able to `upgrade` to any arbitrary version. Especially to test a version before releasing it.

🎉 1

p4u1 commented

2024-07-15 16:51:04 +00:00

Can you not test the new version using abra app deploy --chaos?

moritz commented

2024-07-15 17:22:02 +00:00

Can you not test the new version using abra app deploy --chaos?

Sorry you are right, I forgot that abra app deploy --chaos is mostly doing the same like abra app upgarde --chaos, as it also doing an in-place upgrade and I don't need to undeploy the app.

> Can you not test the new version using abra app deploy --chaos? Sorry you are right, I forgot that `abra app deploy --chaos` is mostly doing the same like `abra app upgarde --chaos`, as it also doing an in-place upgrade and I don't need to undeploy the app.

👍 1

decentral1se commented

2024-07-15 20:41:37 +00:00

Nice! afair abra app deploy <hash> will trigger a chaos deploy, no --chaos required 😌 And yes, the behaviour of upgrade/rollback is now finally changing from deploy. which is IMHO a good thing and less confusing. just we need to change our habits 🙃

Nice! afair `abra app deploy <hash>` will trigger a chaos deploy, no `--chaos` required 😌 And yes, the behaviour of `upgrade`/`rollback` is now finally changing from `deploy`. which is IMHO a good thing and less confusing. just we need to change our habits 🙃

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: toolshed/abra#434