Ludovic Courtès <l...@gnu.org> writes: > Anyway, the proposal is about migrating repositories, issues, and > patches to Codeberg. You’ll find the rationale, plan, and open issues > in the attached draft. I already found two “sponsors” for the proposal > (meaning they agree with the general direction and are willing to > participate in discussions) but if anyone else would like to sponsor it, > I’m happy to add them. > > Feedback welcome! > > Ludo’. > > title: Migrating repositories, issues, and patches to Codeberg > id: 002 > status: draft > discussion: https://issues.guix.gnu.org/<number assigned by issue tracker> > authors: Ludovic Courtès > sponsors: Tobias Geerinckx-Rice, Ricardo Wurmus > date-submitted: <date when you send the first draft> > date: <date when the discussion period starts> > SPDX-License-Identifier: CC-BY-SA-4.0 OR GFDL-1.3-no-invariants-only > ---
... > ## Continuous Integration > > Forgejo supports > [*webhooks*](https://forgejo.org/docs/latest/user/webhooks/), `POST` > requests that are sent to the server of one’s choice upon events such as > pull request creation. Cuirass (running at ci.guix.gnu.org) already > [supports](https://hpc.guix.info/blog/2025/01/join-the-guix-science-community/) > them and automatically creates a *jobset* when a pull request is made. > The [QA frontpage](https://qa.guix.gnu.org) and its [Data > Service](https://data.qa.guix.gnu.org) does not support Forgejo webhooks > yet but can be extended to do so without too much effort, possibly > sharing or reusing the Forgejo interface code from Cuirass. > > In the Guix repository, we will set up webhooks to trigger the creation > of a new jobset at ci.guix.gnu.org (Cuirass) as soon as migration is > complete. While this has been successfully used for several months for > [Guix-Science](https://codeberg.org/guix-science), scalability will be > the major concern here; additional developments may be needed to > consolidate this support. Eventually the QA frontpage will also support > those webhooks. > > We will arrange so that the build status of a pull request is clearly > visible right from that pull request. > > Eventually, the QA service or a [Forgejo > *action*](https://forgejo.org/docs/latest/user/actions/) may > automatically provide feedback from `guix lint` as a reply to pull > requests. I think this section would either be better changed to a commitment to setup particular things, or a shorter statement that "Continuous Integration" at least shouldn't be any harder. I'm not sure about the argument that "Continuous Integration" would be easier on Forgejo/Codeberg, since I think the main problems we're having in this area wouldn't be helped by this proposal. > ## Workflow > > Once continuous integration (CI) is fully operational, pull requests may > be merged if and only if they successfully built. “World-rebuild” pull > requests would still follow the [existing branching > process](https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html). Given this proposal isn't to get "continuous integration" to be fully operational, I don't think this paragraph is really relevant. > To help scale better, we will look for ways to empower team members who > are not members of the “Committers” team such that they can trigger a > merge even though they do not have commit access. This probably > involves a bot (TODO: think through it). Also on the subject that we don't have automated testing for changes, I think this is also too vauge to be useful. > Since Guix requires signed commits by people listed in > `.guix-authorizations`, we will *not* be able to click the “Merge” > button nor to enable auto-merge on build success. This is a security > feature that we want but it limits scalability as actual merges lays on > the shoulders of committers. To reduce the load on committers, we could > use a scheme as follows: > > - contributors create pull requests against a `staging` branch (TODO: > check PR templates to force `staging` by default); > - the `staging` branch is *not* signed and team members can somehow > enact (TODO: figure how) merging into that branch; > - committers periodically rebase and marge that branch into `master` > after a cursory look, with the understanding that it has been > reviewed and merged by authorized people. > > That way, pushes to `master` will be limited to changes that have > already been validated and built. > > XXX: Does it really belong in this document? Should we just keep that > for later? Personally I think the most safe workflow is to turn off the merge feature (which seems possible), then committers push things as usual. > - Committers can write to `master` (branch protection rule) > - Python members can write to `python-team` and `staging` I think this is proposing commit access for branches for team members, which might not be committers. Given that seems unnecessary I'd remove it from this proposal.
signature.asc
Description: PGP signature
