Forgejo v1.19 was published. It is the first major upgrade and was a critical milestone to verify the development strategy of the soft fork actually works. The release team was legitimized by the community in accordance to the decision making process, as promised when Forgejo was created.
Forgejo Actions, the experimental integrated CI, now runs on the new Forgejo infrastructure which includes two instance. One for experimenting and debugging and another dedicated to Forgejo development. In a spirit of dogfooding, the Forgejo runner that spawns CI jobs is now released using Forgejo Actions. A new action, setup-forgejo was also created to conveniently spawn a Forgejo instance for the duration of a test.
There also are noteworthy activities in the wider Forgejo community not covered in this update.
- The documentation is versioned and maintained in a directory that has the same name as the Forgejo release
- The Forgejo runner is released independently and tested to be compatibility with existing Forgejo releases
Forgejo v1.19 includes all of Gitea v1.19 and the upgrade went smoothly. If Gitea was a Go package with a documented API it would be as easy as upgrading one of the other Forgejo dependencies. But it is not and that’s where the difficulty of a soft fork resides.
The Forgejo strategy, since its inception, is to rebase on top of Gitea weekly. The Forgejo commit series are kept to a minimum (for instance by squashing related commits) and conflicts, if any, are resolved (for instance changing from less to css required reworking the commit implementing the Forgejo themes). It turns out to be sustainable and the associated maintenance work stays the same over time. Considering that hundreds of commits have been merged in Forgejo over the past four months, there were many opportunities for a rebase to go wrong and get stuck because of conflicts. The absence of problems during the Forgejo v1.19 release is a sign that this strategy is working.
When Forgejo started, people stepped up to create the releases. There was no decision making process at the time and no clear way for the community to agree that they could be trusted with this role. They were part of an interim governance and pledged to resign as soon as a governance was in place. They fulfilled this promise 2 March 2023 by applying to become legitimate members of the Forgejo release team in accordance to the decision making process. They got an agreement a few weeks later and there now is a Forgejo release team agreed upon by the Forgejo community.
The experimental integrated CI that comes with Forgejo v1.19 is not just a new feature, it also depends on:
- a new binary, Forgejo runner, that is responsible for running the CI jobs
- a repository of reusable Free Software Actions
They both need to be tested and it would be convenient if Forgejo Actions was enabled on Codeberg. There would be no need for Codeberg to provide a runner: it can be run and connected independently, using a token specific to a given repository. Forgejo would spawn a runner and it would work without requiring any resource from Codeberg. However, there are at least two reasons for waiting until Forgejo v1.20 or v1.21 before enabling this feature on Codeberg, even without providing runners to Codeberg users:
- it is still experimental and fragile
- it may have security issues
To solve that problem an instance of Forgejo was installed at https://code.forgejo.org. It has a registration open to Codeberg users and is dedicated to Forgejo related development. It has Actions enabled and provides a runner to selected repositories.
These machines need devops and applications to the devops team are in progress. Their role is, in a nutshell, to keep all machines Forgejo depends on in a healthy state. That includes the new machine made available to the Forgejo project, which could be used to host code.forgejo.org.
Forgejo provides some essential Actions in a dedicated organization. As one can expect of any function in Go or Python, Actions are not immune to typos, regressions or subtle misbehavior, just like the software they are designed to test. Testing is even more important in a distributed environment where each Action is maintained by different groups of people and have their own lifecycle.
The CI of the Forgejo Runner itself relies on workflows that use actions for:
- Running unit tests
- Publishing its own releases
- Integration testing to verify it performs as intended with a live Forgejo instance
The Forgejo Runner integration tests uses a new setup-forgejo action. It runs a Forgejo instance for the duration of the test, very much like a MySQL or PostgreSQL service. It can conveniently be used by software that depends on Forgejo, for instance to test interactions with the Forgejo API instead of relying on mocks.
setup-forgejo action uses itself, recursively, for integration testing with two levels of nesting:
- Forgejo 0: https://code.forgejo.org is a Forgejo instance that hosts setup-forgejo.
- Forgejo 1: when a pull request is proposed
setup-forgejo, the CI job creates a brand new Forgejo instance with a runner to experiment with the proposed change.
- Forgejo 2: The experiment consists of running
setup-forgejoand verify the Forgejo instance it creates actually works as expected.
In February 2023 someone new (who wasn’t a contributor that the project is relying on) joined the chat and issue tracker, spoke repeatedly in ways that was hurtful/painful to Forgejo community members, and did not seem to have capacity to speak more sensitively, despite offers for support and repeated requests. It was eventually decided to remove this person from the project during a year. But the tension they created did not dissipate instantly. In March 2023 it distracted community members from productive and important work on governance, strategy and development. Some community members went silent, others were on edge and more moderation actions were taken.
It is in the nature of inclusive communities to be subject to that sort of trouble in their infancy, when they are still fragile. Some can be destroyed for good, others may choose to be less inclusive to better protect the members of their inner circles. Something different is happening in Forgejo. Late March it went back to be the quiet and productive space it once was. Community members who were silent during the troubles came back. A moderation process was proposed and was field tested. It is a little early to be sure but it appears the community is healing and is now better protected from negative influence, without sacrificing on inclusiveness.
As a followup to questions sent by NLnet on a grant application to create a Forgejo distribution, potential beneficiaries worked on a detailed project plan. It was sent late March and it will take a few weeks before a reply is received to determine if it is allowed to proceed to the next step.
Another grant application focused on improving Forgejo UI/UX was declined.
Forgejo is a community of people who contribute in an inclusive environment. We forge on an equal footing, by reporting a bug, voicing an idea in the chatroom or implementing a new feature. The following list of contributors is meant to reflect this diversity and acknowledge all contributions since the last monthly report was published. If you are missing, please ask for an update.
A minority of Forgejo contributors earn a living by implementing the roadmap co-created by the Forgejo community, see the sustainability repository for the details.