On 2025-02-23 16:20, Ludovic Courtès wrote: > Hello Guix! > > [...] > ## 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. > > ## 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). > > Note that 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. > > If and when the project migrates, we will incrementally adjust our > workflow to ensure it scales better.
There is one thing I'm not sure someone raised earlier about ownership and ease of access to data. I hate a lot of AI usage/goals , but I think we should take advantage of the research in this field when convenient and for a worthwhile goal (that is : not making money by stealing people's attention). It seems we have a tremendous amount of data (for git commits, git commit messages, email exchanges) that could be used to train specialized AI agents that could be very useful in CI / development contexts. A few examples on the top of my mind: - a commit message help complying with GNU standards - a "rebuilder" agent, to try and rebuild a package that has failed when the change is trivial (such as ignoring a test / try updating a dependency). (This could be a "crew" of agents checking for compilability, lints, build failures... with MCP protocoal and each agent having its specific training data / RAG). (The goal is not to make the user less responsible but instead waste less time doing what is trivial.) Think about it : when rebuilding a package that is core to a build-system, such as python, instead of spending the most part of a week doing minor tweaks on hundreds packages, just let the background job run a week until it only leaves "truly" difficult packages for teams and maintainers. With some luck, since the tasks could be specialized, we might already have enough data to train internally. What's really good is that we might be able to only use guix data to train and use this kind of helpers. Accessing this data in batch, through the git repository, mailing lists, failed logs from build farms..., is possible at this date. Even if that would demand a coordinated effort anyway, I think the move to codeberg would make this more difficult ; I also think guix's guile and lists coherence is a strong advantage we don't take enough in consideration (I don't think Nix would be able to have these kind of helpers around, whereas it seems doable in Guix). (This is not against moving to codeberg, but more about being mindful of what we might loose on this aspect). -- Best regards, Nicolas Graves
