Happy to help! I'm a big fan of gitlab-ci since it is a collection of standard tools like Docker, YAML, bash, etc. It takes a bit more to learn than Travis-CI, but it pays off by being more flexible and a simpler setup. E.g. it is easy to start with a plain, base Debian image, only install the requirements, and run tests from there. No intermediate layer. And using YAML templates, it is possible to reuse chunks of code. In the go setup I'm using right now for snowflake, I have a template for the install and test run. Then its trivial to add/change the base image between Debian-derivs of various releases. I should also add: these are actually F-Droid runners, not Guardian Project. F-Droid a bare metal server (16-core/32-thread, 142GB RAM, 3TB disk) that could be allocated to only gitlab runners that can be shared with Tor Project cost-free. We just need someone to admin it. We have an almost complete setup with ansible. @uniqx and I would happily help someone finish that setup if there was someone to make sure it stays updated and running. (I'm personally already admining more servers than I should be). Also, these runners have KVM and privileged mode enabled, so you can run any KVM VM in the gitlab-ci jobs. Docker too. .hc Alexander Færøy:

Hello folks!

Hans from The Guardian Project added his CI runners to our Gitlab instance. It looks like some pretty fast machines that allows each team to experiment with Gitlab CI on our Gitlab instance.

Hans says that the runners have no uptime promises or anything like that, so if they are down they are down :-)

Here's some documentation for getting started: https://docs.gitlab.com/ee/ci/

Thanks to Hans for this!

All the best, Alex.

-- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556