391–400 of 468 posts
Earlier quoted context omitted.
I migrated my Gitea instance to Forgejo, it was pretty painless
I accidentally upgraded my Gitea instance beyond the fork which makes this more difficult...
Earlier quoted context omitted.
I'd also say that gitlab runners are the biggest failure point in gitlab and take some work to micro-manage. If I was setting up from scratch I would consider gitlab for source control, but some hosted service for CI
Really? I've been very happy with how easy GitLab Runners are to manage. We were running 20,000 jobs a week on 6 bare metal boxes and we had tons of spare capacity. Simple Ansible script to deploy the runner and register it. Tags for t-shirt sizes to set the amount of CPU/memory allocated to each job container. Maybe running on Kubernetes or some autoscaling solution is more painful.
When you fork a project, it's really not clear in the UI why it's stalling (because it uses your configured runner, i.e. none, not the project's).
When a runner fails, it's not really clear why. gitlab-runner logs are mostly useless in terms of connectivity to the gitlab instance, displaying what projects/repos it's effectively associated with. And i don't think it even has a simple test command to test the docker setup, you just have to trigger jobs until it fails in the middle of hundreds of lines of logs.
Earlier quoted context omitted.
If that is too long, you have an attention span problem. That is your issue to deal with, not ours. Or from another angle, how would you say it more concisely? Preferably without using AI to summarise.
If anything it seems like you are the one with an attention span problem when you can't remember that he posted the correct consise definition earlier in this thread. Being a dick when justified is counter-productive, but being a dick while also being the one who is confused is a way worse look.
As a question, not a statement of knowledge, when if they'd read that “too long” paragraph they could have stated the point confidently.
And while that description, if stated as such, is more concise, it leaves out notable details (its relationshipt to Gitea, which many may recognise, and that it isn't the full feature set of the service) so is probably too concise.
It depends on what you are after? 1. Do you want something that works and feels like GitHub? -- Forgejo and Gitea are good for this. 2. Do you want a place to host git repositories with minimal hassle? -- GitLab, CodeBerg, and others are available. 3. Do you have your own hosting infrastructure? You could use gitolite and CGit/GitWeb on that hosting platform or local hardware. 4. Do you just want to host repositories…
Hopefully a good spot to plug my own project, preloop, which is a drop-in replacement of Github actions(both the runners and control plane) that runs locally or self-hosted in isoalted microvms, and supports debug-on-failure. You can also push to the server, run CI and then optionally create a draft PR. Not quite production-ready yet(for the self-hosted part), but the local part works well. We implement the official…
The concept is marvelous, but i'm 100% not trusting slop near my infra, and i'm 100% not trusting people who are not upfront about vibecoding in their README and raise my hopes for nothing.
I suspect most sysadmins, like me, will not trust LLM-generated code within a 10-foot-pole-reach of their servers. You still might be able to convince clueless managers suffering from AI psychosis to go for your solution. But if you'd like to make actual software engineering with a human team, i'm 100% convinced there's actual desire and market for a solution like this to easily get ease the transition path out of Github.
https://tangled.org ! Founder/CEO here. We're a new forge building things from the ground up, and are fully federated -- you can host your git repos on your own infra, along with the CI runners. We've also got a pretty neat set of features (if I may say so myself): stacked PRs, Nix-based CI (if you want it), and a fully open protocol ( https://atproto.com ) to for you and your agents. Happy to answer any questions.
What's the monetization pathway here? No private repositories (because everything is on ATProto) so near zero commercial use potential - CI is free, everything is free, no pricing page... Am I the product if I use this service?
Self hosting will be free forever. That is not a threat to monetization plans because most people would pay a reasonable price ($10 month) to avoid dealing with infra. Remember that hardware is cheap so margins can get pretty high and 1000 paying customers at the lowest tier is probably enough to pay for a full time engineer. 10,000 and you can have a small team (plus unpaid open source contributors). You don't need Amazon scale and growing profits to be successful.
Earlier quoted context omitted.
It is prejudiced. If you like sending patches over email more power to you, but there’s a reason 99% of the world’s devs does not follow that workflow.
> but there’s a reason 99% of the world’s devs does not follow that workflow. Is there?
Compare that with GitHub where the workflow is push changes to fork, select branch, click to create a PR, write the description in a convenient web form and submit. Less friction and less opportunities to mess up. The solution to a centralized forge is a decentralzied forge, not no forge.
Earlier quoted context omitted.
This is pretty cool and one of the few things I couldn't find a viable alternative to in-house hosting so far. The only thing your "GitLab Runners as a Service" is missing is ISO 27001 (and optionally SOC 2) certification. That makes it again easier for your customer to get / maintain their ISO 27001. (So far I used this cloud.init script to spin up and upgrade GitLab-Runner instants: https://gitlab.com/21analytics/g…
Ha, let us look into ISO 27001 certification and see what it takes to obtain it (and SOC 2). Thank you for this valuable pointer! If you could just sign in (accounts are free and you can even try us out for the first 48h and not be charged), then we could message you to your email address once we have an update here.
> Grants complete read/write access to the API, including all groups and projects, the container registry, the dependency proxy, and the package registry.
Even more so just to stay informed about updates.