[libre-riscv-dev] submitted bugreport to upstream nmigen

Frieder Paape frieder at paape.io
Sat Apr 4 09:15:23 BST 2020


There is an api endpoint for jobs
<https://docs.gitlab.com/ee/api/jobs.html>. We could write a cronjob
which polls the api every day for new jobs and then saves the logs for
those jobs locally.

BUT I personaly think instead of investing time into workarounds because
we don't have gitlab hosted ourselves, we should rather invest time to
host it ourselves. Why not try to host it on the new talos 2 server.
Does it have a public IP? We will probably run into problems, but hey,
we are building a CPU on that architecture, it would look nice if we
host our development tools on such architecture as well. And if there
are larger problems we could bring them to IBM, which probably use
gitlab in high quantity and might have the muscle to ask for a quick
solution.

Hosting it on a donated x86 server I guess would be fine as well

Frieder

On 2020-04-03 23:48, Luke Kenneth Casson Leighton wrote:
> On Fri, Apr 3, 2020 at 9:22 PM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
>>> would you be happy for frieder to install gitlab on it?  (the more
>>> people doing stuff in parallel the better).
>> Sure, though it doesn't have a public IP address and will be nearly
>> impossible to access publicly.
> tck... tck... *thinks*.... nginx reverse-proxy through libre-riscv.org
> shouuuld be able to fix that....
>
>> Also, I won't guarantee that
>> jacob-build-server will be up and running all the time or that I will
>> even respond quickly to issues (feel free to ssh in and power it off
>> if all else fails), so we shouldn't have it be a critical
>> time-sensitive dependency, such as hosting a website.
>>
>> We should probably still use debian salsa for building and setup some
>> kind of log scraper since it is publicly visible,
> there really should be a better way of doing that.
>
> frieder do you know how logs can be sent externally?  (cole i see you
> investigated this somewhat).
>
> remember we do *not* have administrative control over salsa.
>
> l.


More information about the libre-riscv-dev mailing list