Offline support needs more work #471
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#471
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Finally got to the core of #432 and it's related to the changes around trying to make
abra
more resilient to git.coopcloud.tech downtime. I'm reverting parts of the original implementation now to get backabra
ops to their original state.Reviewing the code, there are actually very few cases when offline is possible considering our reliance on collective operations from several co-operatives. Sometimes you only want to fallback to offline when the network is not up and try to salvage something if possible. The code tries to make that decision for us currently but it needs to be refined.
I think perhaps a
--offline
flag would be a better approach, to trigger it. Then it is more explicit. For the clear cut cases where git.coopcloud.tech is not needed, i.e. streaming logs, those can do "offline" by default still.Previous discussion: #292
We're still resilient to the catalogue going offline, that is unrelated to these changes.