🇳🇱
#QOTO update.
I recently added auto-scaling high-power CI runners to our gitlab instance which is free and open to all open-source projects. They even autoscale to keep up with demand.
We include three types of CI runners now, Default compute, GPGPU, and FPGA capable runners.
@freemo No valid certs😬
@snder on https? certs valid what do you mean?
@snder Thats not an invalid cert your seeing. The cert is valid. We just pull in javascript from http sources not just https which chrome is weird about and reports as insecure. If you ook at the cert itself its actually completely valid.
Ah I see! That’s weird indeed, normally Chrome doesn’t have a problem with mixed content..
Sorry! Nothing said!
@snder Regardless it will be fixed eventually
@snder I'm less confident of that.
@freemo How did you setup GitLab? Standalone install or through Yuno or something?
@snder Neither exactly. All the qoto services I engineered my own AWS pipelines for.
We use ECS with some custom hacks that bring down cost as well as make it portable to other non-aws servers.
Basically i use a nginx reverse proxy container along with a companion container that automates load balaning and SSL certificates. The way it works is whenever i add any container of any kind to the cluster I simply set two environment variables telling it the domain name it will be hosted on and whihc port it exposes the web server on. At that point the load balancing container automatically detects the new docker container, reads the variables, and creates a new reverse proxy link. It then automatically goes and obtains/applies a new SSL certificate from lets encrypt and applies it to the reverse proxy link.
So basically to get gitlab to work i just brought up a container with the proper settings and everything magically worked, just like my other services.
Oh wow! That's pretty genius! 🤓
