Hi, Mathieu Othacehe <othac...@gnu.org> skribis:
> Thanks for the fix! The jami and jami-provisioning tests are also broken > because of what looks like to be the same issue: > > One does not simply initialize the client: Another daemon is detected > /gnu/store/01phrvxnxrg1q0gxa35g7f77q06crf6v-shepherd-marionette.scm:1:1718: > ERROR: > 1. &action-exception-error: > service: jami > action: start > key: match-error > args: ("match" "no matching pattern" #f) > Jami Daemon 11.0.0, by Savoir-faire Linux 2004-2019 > https://jami.net/ > [Video support enabled] > [Plugins support enabled] Yes, I noticed that, but I’m not sure how to apply a similar workaround. > I think we don't have the right approach here: we should check that the > system tests are passing before pushing series and not adapt the tests > afterwards. Yes, apologies for that. > Historically this was difficult because the system tests were often in a > semi-broken state. Before the Shepherd update the tests were however all > passing (modulo rare intermittent failures). > > As it's not always obvious what's going to break the system tests and > what's not (simple package update can easily break them), it would be > really nice to have mandatory commit verification. > > The mumi/cuirass gateway that has already been discussed could really > help us here. If some people are motivated, we could split the work and > introduce such a mechanism. Yes, I agree; an “always green” ‘master’ branch would be great. Do you have milestones in mind for “commit verification”? As I see it, the difficulty is that we’ve been looking at a horizon of features à la GitLab-CI without being quite sure how to get there (apart from deploying GitLab or a similar tool, that is). A first step that comes to mind would be an easier way to set up transient jobsets for a branch (or, ideally, for an issue: the thing would apply patches and create the branch). Thoughts? (Maybe worth moving to guix-devel.) Ludo’.