@ale indeed, there are plenty self-hosted #gitea servers.
This is why #forge federation will be so cool, as it wil tie them together in a large whole, and with that open the ecosystem and create a level playing field, that can weigh up to #Github network effects and #FOMO.
There's also a volunteer collective dedicated to provide easy #hosting of Gitea + #WoodpeckerCI + Pages and the ability to self-host again at any time. And they have a Clinic to help upgrade you self-hosted server: @hostea
@humanetech @hostea Btw - we are working on a k3s setup for gittea: https://gitlab.com/domaindrivenarchitecture/c4k-gitea
Interested in exchanging insights & experience ?
@humanetech - ger bounded contexts - yes, I agree. In our current "reading the DDD Book again workshop series" we are working on a rewrite 🙂
@team it is cool that you are exploring this from an architectural perspective.
@team @humanetech Very interested! I like that k3s is lightweight and easier to understand than k8s from an operator point of view.
At #Hostea the @gitea Ansible playbook is tested end to end to verify @WoodpeckerCI is able to run a job. It is just an example and you can browse the code below.
I'm curious to know what is your strategy for testing your Infrastructure as Code?
---
Authored by @dachary
@hostea @humanetech @gitea @WoodpeckerCI @dachary at some of our modules we wrote an integrationtest ala
1. spawn a k3d (k3s in docker container)
2. install our app (i think it was c4k-nextcloud)
3. do a backup
4. kill k3d & span another one
5. install app and do a restore
6. make a curl that proves a successful restore.
But I'm not sure that the aspect proven by this test is worth the effort. (1/2)
@hostea @humanetech @gitea @WoodpeckerCI @dachary
... Things may be different for a massive hosting facility provisioning thousands of git instances a day ....
Aside of full integration test we have:
1. unittest (c4k is comparable to helm - but every build in convention we can unittest)
2. we build images from (mostly stable base dsitributions) - building fresh easy compared to handling drifted long running servers.
...
@hostea @humanetech @gitea @WoodpeckerCI @dachary
...
3. image-build-time downloads we test for presence and validity.
I'm also interested in the way, you are doing tests :-)
@team @humanetech @gitea @WoodpeckerCI @dachary
The tests run with
tox -e hostea
which essentially does the following:
* create the entire infrastructure from scratch (create the virtual machines, DNS, monitoring, the whole thing)
* run the Hostea playbooks
* run tests that verify common usage scenario
I think verifying the backup as you do is very valuable: there is nothing worse than a backup that cannot be restored 😨
---
Authored by @dachary
@team @hostea
Nice! I forwarded your toot to the #matrix chatroom at #hostea:matrix.batsense.net
OT:
I read the doc on Bounded Contexts in https://gitlab.com/domaindrivenarchitecture/overview/-/blob/master/principles/boundedContextSeparation.md and I feel it misses the mark on the 'Cost' side of things.
The #DDD book is sub-titled "Tackling complexity in the heart of software", not increase it. And bounded contexts are helping improve the developer experience e.g. via Clean Architecture.
Bounded contexts are not tied to implementation, and also not to dependency hell.