Forgejo is lightweight relative to some other options, but it is not resilient to scraping. Scrapers can access, commit-by-commit, each individual file, each file's "git blame", and each commit's repository archive... and they do. Most public Forgejo instances need to rely on a reverse proxy like Anubis or Iocaine in order to prevent server resources from being exhausted by bad actors. Or require sign-in for all access.
It is kinda incorrect and kinda correct. Codeberg allows you to create private repositories. However, their rules are clear that the intent of private repositories must be in support of Free software projects: https://docs.codeberg.org/getting-started/faq/#how-about-pri..., which for many people is effectively not allowing private repositories.
Forgejo is committed to using exclusively Free Software for it's own project development. Windows and Mac versions of the Forgejo Runner are built in the project's CI system as a minimal check to ensure platform compatibility, but due to the project's commitment, the project doesn't do integration testing on these platform. And therefore doesn't distribute untested software.
It probably depends on your scale, but I'd suggest self-hosting a Forgejo instance, if it's within your domain expertise to run a service like that. It's not hard to operate, it will be blazing fast, it provides most of the same capabilities, and you'll be in complete control over the costs and reliability.
A people have replied to you mentioning Codeberg, but that service is intended for Open Source projects, not private commercial work.
This will occur if you have a `forgejo-runner daemon` running while you try to use `exec` -- both are trying to open the cache database, and only the first to open it can operate. You could avoid this by changing the cache directory of the daemon by changing `cache.dir` in the config file, or run the two processes as different users.
> It's a bit strange there are two files IMHO.
The `.runner` file isn't a config file, it's a state file -- not intended for user editing. But yes, it's a bit odd.
The Forgejo project has been gently trying to redirect new contributors into fixing bugs before trying to jump into the project to implement big features (https://codeberg.org/forgejo/discussions/issues/337). This allows a new contributor to get into the community, get used to working with the codebase, do something of clear value... but for the project a lot of it is about establishing reputation.
Will the contributor respond to code-review feedback? Will they follow-up on work? Will they work within the code-of-conduct and learn the contributor guidelines? All great things to figure out on small bugs, rather than after the contributor has done significant feature work.
If you're running a public Forgejo instance and upgrading to v13, please take note of the post-release recommendation to run the `avatar-strip-exif` command to enhance user privacy.
If you're running a Forgejo instance and upgrading to v13 today (or soon), note the post-release recommendation to run the `avatar-strip-exif` command to enhance user privacy.
People having trouble getting this configured is a common issue for self-hosting Forgejo Runner. As a Forgejo contributor, I'm currently polishing up new documentation to try to support people with configuring this; here's the draft page: https://forgejo.codeberg.page/@docs_pull_1421/docs/next/admi...
I don't think jujutsu woild help with this use case -- jujutsu will not save everything because it is not running constantly on your repo. It snapshots the working tree only when you run a `jj` command. Ineffective if an agent is doing work.
If a program is built with strong software architecture, then a lot of it will fit that definition. As an analogy, electricity in your home is delivered by electrical outlets that are standardized -- you can have high confidence that when you buy a new electrical appliance, it can plug into those outlets and work. But someone had to design that standard and apply it universally to the outlets and the appliances. Software architecture within a program is about creating those standards on how things work and applying them universally. If you do this well, then yes, you can have a lot of code that is testable and verifiable.
But you'll always have side-effects. Programs do things -- they create files, they open network connections, they communicate with other programs, they display things on the screen. Some of those side-effects create "state" -- once a file is created, it's still present. These things are much harder to test because they're not just a function with an input and an output -- their behavior changes between the first run and the second run.
"was previously known as gitea" is slightly confusing wording since it makes it sound like the project was renamed, which isn't the case. Gitea is still an active project known as Gitea. Forgejo is a fork of Gitea.
https://docs.codeberg.org/getting-started/faq/#how-about-pri...