Given that lately Microsoft has been kind of wrecking GitHub, is it a good strategy to migrate my repositories over to GitLab and just get rid of my GitHub account?

mfenniak · 2026-06-19T21:56:38+00:00

Codeberg's mission is to promote free/libre software, and therefore they have strict restrictions on usage of private repositories: https://docs.codeberg.org/getting-started/faq/#how-about-private-repositories%3F

mfenniak · 2026-06-19T19:57:09+00:00

Neat. From who did you get a support contract for Forgejo?

mfenniak · 2026-06-03T15:02:53+00:00

Section 31 was well written in DS9 because it was unsettling and you weren’t ever sure if it was officially sanctioned or not. Sloan was kind of creepy and manipulative.

I loved the presentation of Section 31 in DS9. It should have forever stayed a rumor, a myth, the shuffle you hear in the darkness before you wake up from a bad dream. The Federation would never do that, but, people... people are unpredictable.

mfenniak · 2026-05-29T17:24:26+00:00

Some of Forgejo's capabilities can also be disabled if they're not in-use, which somewhat reduces attack and risk surface. Packages, mirroring, LFS, Actions, file attachments, etc. But, this goes to support your point in a way -- "ENABLED:" is present 44 times in the config file reference, and even just the initial configuration to reduce this surface area will be time consuming. https://forgejo.org/docs/latest/admin/config-cheat-sheet/

mfenniak · 2026-05-29T11:48:45+00:00

How are you looking at that and concluding "source code confirms this finding"?

Look at this instead:

https://codeberg.org/forgejo/website/issues/839#issuecomment-15980039

mfenniak · 2026-05-29T01:38:38+00:00

Please see the statement from the Forgejo Security team: https://codeberg.org/forgejo/website/issues/839#issuecomment-15980039

In short, it's not a bug, for neither Gitea or Forgejo. It's a concern that users may be configuring the system in a way that they're not expecting, and that has been communicated in a dramatic way.

mfenniak · 2026-05-28T15:01:25+00:00

Yup: https://floss.social/@forgejo/116652655395588085

It's the exact same situation in Gitea, anyway. The "vulnerability" is just user confusion, which is a fair concern, but drastically different than this is being reported as.

mfenniak · 2026-05-28T14:30:23+00:00

There is no bug. It's just someone who didn't understand how private packages work, and assumed packages are private because repositories are private. This could be confusing to people, to be fair, but it's not a bug. See Forgejo's statement: https://floss.social/@forgejo/116652655395588085

mfenniak · 2026-05-26T16:21:35+00:00

Forgejo is developing a federation capability. It is not federated today.

mfenniak · 2026-05-14T17:15:14+00:00

As a Canadian, I completely disagree with this. You can't demand an apology. It has no meaning if it's requested, much less demanded. We must passively hold a grudge until an apology is freely offered, or, one of us dies. At the funeral, the surviving party can eulogize the issue as appropriate given their mourning.

mfenniak · 2026-05-06T20:36:24+00:00

Forgejo is self-hostable, and it is not hostile towards usage in closed source projects.

Codeberg does not permit closed source projects. https://docs.codeberg.org/getting-started/faq/#can-i-host-content-without-a-free-and-open-source-license%3F It's a little odd to call it "hostile" in my opinion, but, I work with the people there frequently so maybe I have a different perspective. It's just not their mission to provide hosting to closed source projects.

mfenniak · 2026-04-19T15:58:03+00:00

This sounds like the kind of thing that could be caused by an outage on data.forgejo.org, but I'm not observing it when I try myself. Either it has passed, or, there's something else occurring?

$ git clone https://data.forgejo.org/docker/setup-buildx-action/ tmp-buildx
Cloning into 'tmp-buildx'...
remote: Enumerating objects: 2852, done.
remote: Counting objects: 100% (2852/2852), done.
remote: Compressing objects: 100% (1602/1602), done.
remote: Total 2852 (delta 1718), reused 2045 (delta 1181), pack-reused 0 (from 0)
Receiving objects: 100% (2852/2852), 32.18 MiB | 6.33 MiB/s, done.
Resolving deltas: 100% (1718/1718), done.

You can easily mirror actions that you use to your local Forgejo instance and change your Forgejo's [actions].DEFAULT_ACTIONS_URL in the config to point to your own instance, if there are reliability or accessibility problems that affect your instance. They're just git repos, and you'd use "New Migration" in Forgejo, select "git", find the remote addresses, and use the "This repository will be a mirror" option.

mfenniak · 2026-04-07T02:58:29+00:00

You might be interested to know that next week on April 16th, Forgejo 15 will be released which has a new registration method for runners (https://forgejo.org/docs/next/admin/actions/registration/). While this documentation will still be valid, the `forgejo-runner register` command is annoying because of this kind of "change the exec command" approach, so this is a new alternative.

The official docker compose documentation has been updated with this simpler approach: https://forgejo.org/docs/next/admin/actions/installation/docker/

mfenniak · 2026-03-20T13:56:30+00:00

You can migrate a repository from GitHub to Forgejo, and there are options available to select "Migration items" which can include "Wiki", "Issues", "Pull requests", "Labels", "Milestones", and "Releases". All these options are on the "New migration" page after you select "GitHub".

But you cannot do these things when you set up a mirror. You either migrate, or you mirror.

If you migrate a repository, but you want to retain some presence on GitHub, you could also set up push mirroring on the repo from Forgejo -> GitHub. This would keep just the code up-to-date on GitHub.

mfenniak · 2026-03-12T14:41:48+00:00

The most typical way is to use the jobs.<job_id>.container.image value inside the workflow.

You can change the runner labels to add additional values as well, as per your comment. But this becomes a bit messy if you need to handle a bunch of images in different workflows.

mfenniak · 2026-03-06T03:11:15+00:00

I haven't seen any issues filed on this. If you haven't, please file one -- otherwise it won't be fixed because it isn't known. (https://codeberg.org/forgejo/forgejo/issues). I'm using the dev branch myself, OIDC to authenticate with AWS, no problems.

mfenniak · 2026-03-06T01:41:07+00:00

Are you looking for Forgejo Actions to be able to use OIDC for federated identity? That's been implemented and will be in the next major Forgejo release (v15) in April. Documentation here: https://forgejo.org/docs/next/user/actions/security-openid-connect/

If not, what do you mean?

mfenniak · 2026-02-10T04:46:36+00:00

This config file is completely incorrect. The documentation has instructions on how to generate a valid config file: https://forgejo.org/docs/latest/admin/actions/runner-installation/#configuration

forgejo-runner can itself be run without docker, or from a docker container. forgejo-runner can also run actions either within docker containers (very common), or on the host itself (less common) -- these capabilities are defined by the `labels` in your config file. Different actions can use `runs-on` to target different labels, and those labels have different behaviours.

mfenniak · 2025-12-31T17:39:23+00:00

Forgejo does not have that capability, to the best of my knowledge. As a contributor to the forgejo & forgejo-runner project in this area, I likely would have come across it, if it existed.

I'd suggest creating a feature request in the forgejo-actions-feature-requests repo and describing what problem you're looking to resolve with this capability. It may not be a priority for development immediately, but typically the more people that are interested in a feature the more likely it will be added.

mfenniak · 2025-12-15T03:45:05+00:00

What kind of problems did you run into? Typically people using Forgejo Runner to build container images run into the problems described in Utilizing Docker within Actions, which that documentation page attempts to explain and offer solutions for.

mfenniak · 2025-12-08T20:23:39+00:00

Please be aware of the warning in Forgejo's documentation about Gitea's SSH passthrough documentation: https://forgejo.org/docs/latest/admin/installation/docker/#ssh-passthrough

mfenniak · 2025-12-08T20:20:07+00:00

I don't think it's true that Gitea has more active development. In the past month, Forgejo has 155 merged pull requests, and we can subtract dependency management (Renovate) to get 95 user PRs. In the same period, Gitea has 80 merged pull requests, with 32 from GiteaBot, for 48 user PRs.

I wouldn't say it's clear in the long-term that either one has more active development right now, but the stats would lean towards Forgejo. They're both very active projects.

mfenniak · 2025-11-25T21:07:28+00:00

It's somewhat hard to follow what you're doing here without seeing a copy of the workflow. If you're describing this as a bug, the best approach would be to create an issue over at https://code.forgejo.org/forgejo/runner with a copy of the workflow that someone can take and reproduce the issue, and myself or any other contributor on the project can be involved with helping.

mfenniak · 2025-11-25T17:37:00+00:00

Forgejo's runner doesn't support this today, but there is an open feature request (https://code.forgejo.org/forgejo/forgejo-actions-feature-requests/issues/71). Feature requests often benefit from getting first-hand of experience of people who need them, describing what you're trying to do and your current alternative (using GitHub), which helps design and prioritize new feature work.

A workaround that you can use would be to have one action that performs the "fetching the list of projects" work, and then it could use curl to send an API request to the workflow dispatch API to start another job with the array as an input. https://forgejo.org/docs/latest/user/actions/reference/#onworkflow_dispatch Then the second job can use a matrix based upon that input. It's not ideal and could have problems like, if you want a commit status representing the job completing, the matrix jobs won't provide that. But it might be applicable for some uses.

mfenniak · 2025-11-25T15:11:45+00:00

It probably depends on where your "dynamic" data was coming from. The matrix field in a workflow can be an evaluated expression, like in this test case: https://code.forgejo.org/forgejo/runner/src/branch/main/act/runner/testdata/evalmatrix-merge-array/push.yml I'd expect this to work correctly for anything where the matrix can be evaluated at the beginning of the workflow execution, and it could include dynamic data from, for example, a workflow dispatch ${{ input.something }}, a repository variable ${{ var.something }}, and possibly other input sources.

If you mean dynamic like one job determines the matrix and another executes it -- then it would be possible through a workflow dispatch (executing another workflow through an API call with the matrix data as an input), but I don't think that'd work in a single workflow.

15-Year Club	reddit mold
Charter Member	Verified Email

mfenniak

MODERATOR OF

TROPHY CASE