Consider migrating Recipes to own Gitea organization #569
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
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#569
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?
So instead of:
https://git.coopcloud.tech/coop-cloud/wordpress
It wold be
https://git.coopcloud.tech/recipes/wordpress
I think this would achieve a few things:
coop-cloud
will be unaffected as that's in the domain name.Related to point 5 is #377 which probably would be solved by this. I'm kind out of ideas about how to fix this recipe list generation, so, tbh, this would make that easier.
I really shudder to think of the amount of churn this would cause... 🙈 Perhaps if we renamed the current
coop-cloud
org torecipes
then Gitea would handle the re-direct? Then creating a new separatecoop-cloud
organisation again afterwards? Probably something breaks anyway.Perhaps with a 301 redirect rule in proxy (if Gitea doesn't support it) and then make
abra
have a--ff-redirect
flag could work?I was thinking about this while out for a walk. Yah maybe renaming Gitea does some undocumented (by my search) redirect 🤔 we make new org named
tools
or something.Huge support for this plan @basebuilder, I previously opened this as #377 before that was renamed / refocused on performance problems.
Gitea does HTTP redirects from moved repos (or probably renamed orgs?) by default, but:
RE @decentral1se's comment in #256 (#256-20291), I think moving SSH remotes is "not too bad" on reflection, a bash one-liner should do it for those of us who don't want to drop our whole
.abra/recipes
dir, redownloading it should work for the rest.BUT!
Any way anyone can think of to migrate Drone configs (and ideally build history) en masse? 🤔
Perhaps it would be not so much effort to make something like:
Which would then useful for future cases of "good idea, but oh noes, this will suck for Reason X" ??
@basebuilder pure gold!
~/.abra/migrations
perhaps which could then be BASH SCRIPTS to be executed. We could have some UI to say "check this shit yall before running because we are about to do shit on your local" and point to the file?