Re: Multi-OS Emacs buildbot?

[Michael Albinus]

Lars Ingebrigtsen <larsi@gnus.org> writes:

Hi Lars,

>> Maybe somebody will help you? I, for example, am already thinking
>> about GitLab runners. But I didn't start to implement.
>
> The VMs are running on my machine on the desk over there *points*, so
> I'm a bit leery of hooking them up to some external system that can
> issue commands.

Yes, it is also my concern. Well, I have a local OpenBSD VM, I also plan
to do first tests installing a GitLab runner there. Just to get a feeling.

Where to put such VMs afterwards is another story. Or you install a
local GitLab instance in your environment, and let the CI jobs run
there?

>> Imagine, I have broken Tramp (not unlikely, you know). So I will get a
>> message, and everybody who commits afterwards, would also get such
>> message, until I have fixed this. Not so nice.
>>
>> AFAIK, GitLab has no memory. It doesn't remember, whether the previous
>> job has failed.
>
> When I've worked with CI systems, they usually are pretty good at
> assigning blame for a breakage?  I'd be surprised if GitLab didn't have
> such a basic feature.

Maybe it has, and I don't know. I know just the trigger "pipeline is
broken" and "pipeline is working"; GitLab sends the messages exactly
when the trigger changes.

For blaming^W informing *people*, we need a more fine-grained trigger.

> But I know nothing about GitLab, and the
> dashboard at emba isn't very encouraging -- it seems to say that most of
> the builds failed because of git locking issues:
>
> ----
> Another git process seems to be running in this repository, e.g.
> an editor opened by 'git commit'. Please make sure all processes
> are terminated then try again. If it still fails, a git process
> may have crashed in this repository earlier:
> ----
>
> So it looks like it needs some work?

Yes, it needs some love. Likely this happens when there are too many
commits in fast sequence; the resulting pipelines block each other. It
is on my TODO to check what's up; perhaps I should give it more
priority.

Best regards, Michael.