Update: I added appropriate comment in the GitLab CI issue about PRs and we are getting attention of Jason Lenny - director of Product Management @ GitLab. Let's hope they prioritise it quickly enough.
Speaking of potential complexity/Maintenance - in order to alleviate any maintenance worries, I think about setting up the whole system on GitLab CI + GKE and running it in parallel to Travis for quite some time (even months) so that we can switch it at any time. Then we will be able to tune it according to real use cases and compare the experience of both systems. Also I am going for holidays in two weeks and I will make sure that there will be someone with GitLab + Kubernetes experience (from my company) who can take over and make sure there will be no problems. However I am quite confident :D nothing is going to happen while I am away. I would also invite whoever from committers who would like to join the project and gitlab instance (once I setup POC) to learn and see how easy it is and how maintenance free it is going to be. J. On Fri, Jul 26, 2019 at 2:56 PM Kamil Breguła <kamil.breg...@polidea.com> wrote: > GKE and its own CI will allow us to solve other problems - building > and publishing documentation from the master branch. Currently, > building is done using the RTD service. Unfortunately, our project is > too large and often the documentation is not built properly. > https://readthedocs.org/projects/airflow/builds/ > We should think about another way to build documentation. In the ideal > world, building documentation should use the same environment as > checking documentation on CI. Adding this step to Travis can further > reduce our development opportunities. > Discussion on Slack about it: > https://apache-airflow.slack.com/archives/CJ1LVREHX/p1561756652021900 > > It is worth thinking about the fact that our project will soon have a > website and our documentation will also be available in many > languages. Currently, talks are taking place with the design studio > and developers who can make these websites ;-) > > https://lists.apache.org/thread.html/982c7baa06742ad722f2baa0db53ad99aea6c26b14b7d6d4aa522677@%3Cdev.airflow.apache.org%3E > We should provide an environment that will allow you to build a > website and documentation. At best, these tasks should be combined. I > hope that we will be able to create a website that will be a real > support for the community on current events, so it will be updated > frequently. > > It seems to me that the project will grow. If we now have problems > with Travis, then the significance of these problems in the future can > only grow. Now we have a chance to provide a stable infrastructure for > the project for a long time. > > I would like to share another situation which was not pleasant for me. > Recently I wanted to send >10 PR, but because of Travis, I had to wait > for the weekend to send changes. If I would send my changes in a week, > I would block the queue for a few hours. Although I did it over the > weekend, I got the message that the queue is blocked on Travis by my > jobs. > > On Tue, Jul 23, 2019 at 6:12 PM Jarek Potiuk <jarek.pot...@polidea.com> > wrote: > > > > Hello Everyone, > > > > I prepared a short docs where I described general architecture of the > > solution I imagine we can deploy fairly quickly - having GitLab CI > support > > and Google provided funding for GCP resources. > > > > I am going to start working on Proof-Of-Concept soon but before I start > > doing it, I would like to get some comments and opinions on the proposed > > approach. I discussed the basic approach with my friend Kamil who works > at > > GitLab and he is a CI maintainer and this is what we think will be > > achievable in fairly short time. > > > > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI > > > > I am happy to discuss details and make changes to the proposal - we can > > discuss it here or as comments in the document. > > > > Let's see what people think about it and if we get to some consensus we > > might want to cast a vote (or maybe go via lasy consensus as this is > > something we should have rather quickly) > > > > Looking forward to your comments! > > > > J. > > > > -- > > > > 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/>
