mfenniak

You may be violating Codeberg's rules. They are not a service for developmental of closed-source software.

https://docs.codeberg.org/getting-started/faq/#how-about-pri...

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.

https://codeberg.org/forgejo/discussions/issues/320

That's not an API tool. It performs direct database access for administrative functions on the Forgejo server.

But there is a different tool that is an API accessing CLI: https://codeberg.org/forgejo-contrib/forgejo-cli

The other way around; Forgejo is a fork of Gitea.

Forgejo 15 was just released last week with repo-specific access tokens. More to come in the future.

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.

A contributor maintains a tested re-release of Forgejo Runner for Windows: https://github.com/Crown0815/Forgejo-runner-windows-builder

But, pull it down and build it, and it will work.

As a developer working on Forgejo -- glad you like it!

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.

On the plus side, Forgejo Action's implementation is still actively improving, where it seems that for GitHub if it's not AI, it's not being touched.

However, as noted in the article, Forgejo's implementation currently has all the same "package manager" problems.

* Strange error: "Error: Open(/home/runner/.cache/actcache/bolt.db): timeout"

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.

Although it's not a writeup, most of the problems can be traced through this "moving-to-forgejo" meta-issue: https://codeberg.org/forgejo-contrib/moving-to-forgejo/issue...

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.

https://forgejo.org/2025-10-release-v13-0/#avatar-image-priv...

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.

https://forgejo.org/2025-10-release-v13-0/#avatar-image-priv...

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...

(Should live at https://forgejo.org/docs/v12.0/admin/actions/docker-access/ once it is finished up, if anyone runs into the comment after the draft is gone.)

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.

Not really.

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.

Great idea, more capacity for LLMs!

/s

There are two approaches to using compose w/ podman:

Replace docker-compose with podman-compose -- somewhat limited capabilities, but works in a lot of cases.

Use docker-compose against podman w/ podman's system service, which provides a docker compatible API endpoint (https://docs.podman.io/en/v5.2.1/markdown/podman-system-serv...). This basically has full docker-compose capabilities, but, you do need run the socket service as a specific user account which end up running all the pods.

I believe this is reference to Go's approach, where code can be written in a linear straightforward fashion with normal function calls, but, if they are syscalls then they become async automatically.

I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.

DoH uses HTTPS; it solves redirects because you can use a trusted server, and not have the request intercepted and the response spoofed.

Since Excel 2010 that limit is 1,048,576.

Be aware that AWS Config is not free. https://aws.amazon.com/config/pricing/

I like that idea quite a bit. I wonder if there's an algorithm that doesn't get completely screwed up by circles... since it is subjective, A > B > C > A is a valid input and shouldn't cause a complete algorithmic failure.

They're super annoying if you have flaky tests. If the tests are such that you can automate retrying and get to a reasonably low false-positive rate, it can be usable.

The branch protection rules that you apply are both used to determine if you can add a PR to the merge queue, and if the merged commit passes the merge queue checks and is OK. This isn't documented, but based upon experience using the beta.

I was surprised by this weird limitation as well. However I found its easy to workaround -- I made my CI checks provide the skipped status when they run on the PR, and then provide the success/failure status when they run on the merge-queue branch.

In a GitHub Action, this is was very easy:

  on:
    pull_request:
    merge_group:
  jobs:
    build:
      name: Whatever...
      if: github.event_name == 'merge_group'

It looks really easy in their product preview: https://www.youtube.com/watch?v=km3MVZ8HZeY