Yes. This is about PRs coming from forks. Currently GiltLab mirrors only the main repo to their own mirror. In order to get PRs from other forks working, they have to get commits from those other repos.
Indeed it's different to use the public runners vs Kubernetes ones. For now Travis will remain a good option to run your own forks (it will continue running and they share the same scripts to start/stop/compose the tests). Those tests will be fully CI-independent (and the tests are already running fully in Docker so no matter where they run, locally, Travis, GitLab, Github - as long as there will be enough resources, they should run. But It also should run using the public Docker runners. The setup I have now uses Docker-In-Docker approach - which means that the whole "machine" that runs the tests is also run as a Docker container. Basically we have single Docker-In-Docker (dind) container that runs on it's docker engine, has docker compose and all the docker-compose started services run inside this docker container (yeah - Inception). The only requirement is that we run the dind with --priviledged flag. This is the only way we can run docker-compose in Kubernetes Cluster and also it makes it super-portable. I just do not know how it will be with performance and have not yet experimented with it as I wanted to focus on having the POC running it. J. On Thu, Aug 8, 2019 at 9:12 PM Philippe Gagnon <[email protected]> wrote: > Hey Jarek, > > AFAIK Gitlab implemented PR builds earlier this year, do they only trigger > if the PR is coming from the same project? > > Also on another note, I wanted to point out that there are environment > differences on Gitlab CI when CI runners run on Kubernetes vs when they run > in VMs w/ plain old docker. The reason why this might be important is that > from what I understand our plan is to run our build infra on GKE (which > will obviously use k8s runners), while gitlab.com public runners are > basically EC2 machines with docker. I think it would be good to keep our CI > templates drop-in compatible with public runners so that contributors can > setup their CI environment in their own gitlab.com accounts almost as > easily as its done with Travis currently. > > Philippe > > On Thu, Aug 8, 2019 at 5:44 AM Jarek Potiuk <[email protected]> > wrote: > > > Indeed. > > > > I will try to get the automated builds on GitLabCI working from master > > before my holidays so that it will automatically runs for quite a while > > (even if the Kubernetest/Kind tests are not yet working there) and > > hopefully we will be able to switch to GitLab + GKE soon. The only > blocker > > there (building from forks) will either be released by GitLab end of > August > > (if they manage to implement and test it) or en of September (they have > > monthly release cadence). > > > > J. > > > > On Thu, Aug 8, 2019 at 11:11 AM Kaxil Naik <[email protected]> wrote: > > > > > This is getting pretty annoying. > > > > > > On Thu, Aug 8, 2019 at 9:06 AM Jarek Potiuk <[email protected]> > > > wrote: > > > > > > > Her is the incident ... our builds are now failing on network > timeouts > > > > https://www.traviscistatus.com/incidents/bmh7gcb0v95t > > > > > > > > -- > > > > > > > > Jarek Potiuk > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > > > > > M: +48 660 796 129 <+48660796129> > > > > [image: Polidea] <https://www.polidea.com/> > > > > > > > > > > > > > -- > > > *Kaxil Naik* > > > *Big Data Consultant | DevOps Data Engineer* > > > *Certified *Google Cloud Data Engineer | *Certified* Apache Spark & > Neo4j > > > Developer > > > *LinkedIn*: https://www.linkedin.com/in/kaxil > > > > > > > > > -- > > > > Jarek Potiuk > > Polidea <https://www.polidea.com/> | Principal Software Engineer > > > > M: +48 660 796 129 <+48660796129> > > [image: Polidea] <https://www.polidea.com/> > > > -- Jarek Potiuk Polidea <https://www.polidea.com/> | Principal Software Engineer M: +48 660 796 129 <+48660796129> [image: Polidea] <https://www.polidea.com/>
