raku / rakudocibot Goto Github PK

RCB is at a point where it starts to make sense to activate it for the production repos (rakudo, nqp, MoarVM). I currently have it running on a server provided by me and working against a set of test repos instead of the production ones.

It has a working OpenBuildService backend, so it can test on everything OBS supports. The GitHub integration is working, flapper detection is there and it's possible to instruct RCB via a PR comment to automatically merge a PR for you should all CI tests be successful.* The only major bit missing is integration of Azure. But we can just leave the current Azure integration in for the time being.

It's probable though that RCB isn't entirely stable yet.

So are people willing to accept some potential flakyness in CI tests but gain wider platform coverage in return?

It is possible to make RCB respond only to one of the three repos, if that makes sense.

I'd like to come to an answer quickly. So I want to avoid going through problem-solving with this and instead just ping a few people and see if some consensus emerges. Please speak up if you object to this approach. Also please ping other people that you feel should also be asked.

Ping @lizmat @ugexe @Altai-man @vrurg @moritz @niner @jdv

• This is only half true, as RCB only takes tests into account it manages itself, so should Azure fail, but the RCB managed runs succeed, RCB won't know and would proceed to merge the PR.

Open discussion on how to best host the RCB.

Requirements:

• Can be run in a container, but needn't be.
• Requires a persistent Postgres DB.
• Requires a Rakudo and a set of modules among them the Cro stack, Red, LibXML and WebService::GitHub. LibXML requires the libxml dev libs to be installed.
• A TLS reverse proxy is probably a wise choice. (Could be an Nginx or or something else.)
• Currently stores sources and build logs indefinitely. Ticks in at about 32MB per test run. Sooner or later we'll need to implement some form of cleanup. 100GB of disk space will give us ~3000 test runs.
• Needs to be accessible via a stable domain name to be able to use GitHub hooks.
• A nice URL to make the web interface available could be https://cibot.rakudo.org/. Bikeshedding allowed.
• Some kind of orchestrator that auto-restarts the service should it die is wise to have. The minimal solution could be a systemd service file, kubernetes is most certainly overkill. Some raku and rakudo infra currently already is deployed on portainer, so maybe just stick with that.

Ping @rba