Live data from Hacker News

OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

onedev.io

31–40 of 67 posts

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#31
post #6

Why do people self-host things like this instead of Github or Gitlab? I don't want to maintain more services for my services. Who has time for that.

A better question is why does it take any time to maintain a tool like this? I spend zero time maintaining my open-source browser (Firefox). It just periodically updates itself and everything just works. I maybe spend a bit of time maintaining my IDE by updating settings and installing plugins for it, but nothing onerous.

A tool like this is not fundamentally more complex than a browser or a full-fledged IDE.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#32
post #24

Earlier quoted context omitted.

You’re assuming people are self-hosting open source projects on their gut servers. That’s often not the case. Even if it were, GitHub irked a lot of people using their code to train Copilot. I self-host gitea. It took maybe 5 minutes to set up on TrueNAS and even that was only because I wanted to set up different datasets so I could snapshot independently. I love it. I have privacy. Integrating into a backup strategy…

Microsoft/GitHub has no model training. How do you think Copilot works? Also if you provide open source, people and companies are gonna use it.

> Microsoft/GitHub has no model training. How do you think Copilot works?

I'm sure if you used that big, smug brain of yours you'd piece together exactly what I meant. Here's a search query to get the juices flowing:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Whether you agree with why someone may be opting to self-host a git server is immaterial to why they've done so. Likewise, I'm not going to rehash the debate over fair use vs software licenses. Pretending like you don't understand why someone that published code under a copyleft license is displeased with it being locked in a proprietary model being used to build proprietary software is willful ignorance. But, again, it makes no difference whether you're right or they're right; no one is obligated to continue pushing open source code to GitHub or any other service.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#34

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary. I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose…

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose.

I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically everything does it this way and there isn't really a good alternative without a ton of additional complexity the vast majority of people won't need.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#35

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary. I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose…

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically ever…

Isn't kaniko designed to solve this?

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#36

Earlier quoted context omitted.

Fossil started as "not invented here", but it has grown into something I like a lot more than Git. Knowing how to use a version control system should be an incidental skill (akin to simple shell commands like "cp" and "ln"), not something that needs to be mentioned in a job posting's role description. I also appreciate that the default workflow for undoing bad merges is a whiteout rather than a true "delete". To each…

I was turned off by the necessity of using users and permissions; it feels unnecessary for local development and kind of a PITA if you have many repos. It works exactly as advertised though; my gripes aren't technical.

I can understand that, but it sounds more like an argument in favor of ye-olde CVS than git... Not that I ever have nor desire to manage my own git server, which would involve its own authentication and administrative tasks.

Note: Before some third person pitches in their condescending two cents on the limitations of CVS, nobody here is recommending CVS.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#37

Earlier quoted context omitted.

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically ever…

Isn't kaniko designed to solve this?

As far as I know kaniko handles the "I'm a CI job inside a container and I want to build a container image" part. The reason CI/CD runners need socket access is to create those job containers in the first place. Using Podman to create job containers inside the app Docker container would be a solution, but Podman containers have many subtle incompatibilities with Docker and its ecosystem, so it makes sense they wouldn't want to use that, at least by default.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#38

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary. I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose…

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically ever…

> It breaks the isolation for that one container, the rest are just fine.

Wrong. A container with access to the socket can compromise any other container, and start new containers with privileged access to the host system.

It compromises everything. This is a risk worth flagging.

Re: OneDev – Self-hosted Git server with CI/CD, Kanban, and packages

#39

The docker quickstart asks me to mount the docker socket, an incredibly dangerous act that fundamentally breaks the isolation that containers are supposed to provide. I see no attempt to explain why this level of access is necessary. I can guess why you think you need it, but whatever the reason it's not good enough. If you need job workers or some other kind of container, tell me how to run those with docker compose…

It breaks the isolation for that one container, the rest are just fine. That's clearly done in order to dynamically spin up CI/CD containers, which you obviously can't do with something like compose. I get why you don't want to do that on a machine running other things and I wouldn't either, but you're pretending like this is such a strange, unnecessary and unexpected thing to require, when in reality, basically ever…

It's poor security practice that shouldn't be overlooked. Mounting the Docker socket effectively allows the entire application to run with root privileges on the host. Given that this seems to be a multi-tenant application, the implications are even more concerning. The component responsible for spinning up CI/CD containers shouldn't operate within the security boundary of the rest of the application.

On a related note, I believe Docker's design contributes to this issue. Its inflexible sandboxing model encourages such risky practices.

Post reply on HN