AFAIK because "act", the tool to run github actions locally, was there and there was no need to create something else. Also makes it easier for people to switch from github.
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.
However, as noted in the article, Forgejo's implementation currently has all the same "package manager" problems.