[Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

Yeah. And pairing that with slimmed-down CI integrations
https://github.com/apache/airflow/pull/7091 that might finally solve our
long-standing CI problems...

J.

On Fri, Jan 10, 2020 at 3:54 PM Tomasz Urbaszek <to...@polidea.com>
wrote:

> Hi all,
>
> Just a small update:
> - after Jarek's changes from https://github.com/apache/airflow/pull/6516
> kubernetes
>   builds started to run (proviously there was an issue with kind)
> - I am testing self-hosted runners
>
> It seems that possible migration is getting closer ;)
>
> Bests,
> Tomek
>
> On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <ph...@gmail.com>
> wrote:
>
> > We have been using Actions on the prestosql project for a little while
> as a
> > Travis replacement and we like it a lot.
> >
> > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > :(
> > >
> > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com>
> > > wrote:
> > >
> > > > I started to play with self-hosted runner and... well, encountered
> > known
> > > > error:
> > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > >
> > > > It seems that GA is still maturing.
> > > >
> > > > Bests,
> > > > Tomek
> > > >
> > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > > > wrote:
> > > >
> > > > > Yeah. All at once seems more than reasonable.
> > > > >
> > > > > J.
> > > > >
> > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Agree with Daniel, let's do it all at once.
> > > > > >
> > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > daniel.imberman@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I’d rather we do it all at once and not need to maintain two
> > > builds.
> > > > > > > Most/all of our CI/CD is dockerized at this point so there
> > > shouldn’t
> > > > > be a
> > > > > > > huge difference.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I have to solve a problem with our kubernetes test but for your
> > > > > > information
> > > > > > > I have never experienced a flaky
> > > > > > > or timeouted build on Github Actions. Maybe I am lucky or maybe
> > > > there's
> > > > > > > something different.
> > > > > > >
> > > > > > > If we agree to move to Github Actions, would we like to migrate
> > > > > > > incrementally or fully?
> > > > > > >
> > > > > > > Bests,
> > > > > > > Tomek
> > > > > > >
> > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > Jarek.Potiuk@polidea.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > No problem on that side - Tomek is using the same scripts we
> > have
> > > > on
> > > > > > > Travis
> > > > > > > > (and they generally work - I think the last step is to make
> all
> > > the
> > > > > > > > tests pass. We have still a number of dependencies between
> > tests
> > > > and
> > > > > > some
> > > > > > > > environmental flakiness so that some tests consistently fail
> in
> > > > > Github
> > > > > > > > Actions where they did not fail in Travis. From latest try by
> > > Tomek
> > > > > it
> > > > > > > > looks like we are 1 test to go (plus some cleanup/setup of
> > > project
> > > > > and
> > > > > > > > making sure all is stable):
> > > > > > > >
> > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in
> > 1207.96s
> > > > > > > (0:20:07)
> > > > > > > > =====
> > > > > > > >
> > > > > > > > We discussed with Tomek and Kamil that in order to speed it
> up
> > we
> > > > > might
> > > > > > > > want to run our own workers on the GCP account we have - just
> > to
> > > > test
> > > > > > > > quickly how much we can optimise it and I am inclined to
> agree.
> > > If
> > > > we
> > > > > > do
> > > > > > > it
> > > > > > > > this way, the transition might be rather fast.
> > > > > > > >
> > > > > > > > If we want to use auto-scalable GKE cluster as we originally
> > > > planned
> > > > > it
> > > > > > > > might take more time to setup (similar setup to what I tried
> > with
> > > > > > > GitLab).
> > > > > > > > There we might need to use docker-in-docker to build the CI
> > image
> > > > > with
> > > > > > > > latest as first step of build and then use that built image
> by
> > > all
> > > > > > > > subsequent steps. But we can do it as the next step -
> > optimising
> > > > the
> > > > > > > > experience.
> > > > > > > >
> > > > > > > > J.
> > > > > > > >
> > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 on my end as well.
> > > > > > > > >
> > > > > > > > > @jarek does this affect anything involving breeze? Do
> GitHub
> > > > > actions
> > > > > > > have
> > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > >
> > > > > > > > > via Newton Mail [
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > ]
> > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > > > ash@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > Legal: no I don't think so.
> > > > > > > > >
> > > > > > > > > Infra: possibly yes to get secrets in there to run things
> on
> > > our
> > > > > own
> > > > > > > > > "hardware" -
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > >
> > > > > > > > > needs someone with Admin rights to create, and I don't see
> > the
> > > > > > Settings
> > > > > > > > tab
> > > > > > > > > at all.
> > > > > > > > >
> > > > > > > > > -ash
> > > > > > > > >
> > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > xd.deng.r@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > +1 for GitHub Actions. I have been using it for months
> for
> > my
> > > > > side
> > > > > > > > > > projects, and it’s working very well. I believe most of
> us
> > > are
> > > > > > quite
> > > > > > > > > tired
> > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > >
> > > > > > > > > > The only point I would like to remind is whether we need
> to
> > > > > > > communicate
> > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > XD
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > kaxilnaik@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> +1 for Github actions
> > > > > > > > > >>
> > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > ash@apache.org>
> > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >>> Happy with any thing that gives a more seamless CI
> > > > experience -
> > > > > > > > faster
> > > > > > > > > is
> > > > > > > > > >>> good too!
> > > > > > > > > >>>
> > > > > > > > > >>> -a
> > > > > > > > > >>>
> > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat
> kyzy <
> > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > >>>>
> > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > >
> > > > > > > > > >>>> wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>>> I am all for it! GitLab has been less-than helpful so
> > far
> > > > and
> > > > > > > > > >>>> recently it
> > > > > > > > > >>>>> seems that running PRs from forks will only be run in
> > > > > > Enterrprise
> > > > > > > > > >>>> Edition,
> > > > > > > > > >>>>> which is less than welcome. I am quite a bit
> > disappointed
> > > > > with
> > > > > > > the
> > > > > > > > > >>>> pace and
> > > > > > > > > >>>>> attitude. Github Actions seems to be much better
> > choice -
> > > > > > > > especially
> > > > > > > > > >>>> that
> > > > > > > > > >>>>> they are closely integrated with Github repo and seem
> > to
> > > > get
> > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> And they added self-hosted runners as well, which
> makes
> > > it
> > > > > > > possible
> > > > > > > > > >>>> for us
> > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> J.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> J.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > >>>>> wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>> Hi all,
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> It sometime since we last discussed using other CI
> > than
> > > > > > Travis.
> > > > > > > > One
> > > > > > > > > >>>> of
> > > > > > > > > >>>>> the
> > > > > > > > > >>>>>> main reasons behind considering Gitlab CI was its
> > > ability
> > > > to
> > > > > > > work
> > > > > > > > > >>>> on
> > > > > > > > > >>>>>> self-hosted runner. However, over time of few long
> > weeks
> > > > > > Github
> > > > > > > > > >>>> Actions
> > > > > > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Github Actions are still growing but using them have
> > few
> > > > big
> > > > > > > > > >>>> advantages:
> > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > >>>>>> - forking repo and enabling actions will run CI on
> > your
> > > > fork
> > > > > > > > > >>>>> automatically
> > > > > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > >>>>>> My impression is quite good. I like information
> about
> > > > steps
> > > > > > > > > >>>> successes at
> > > > > > > > > >>>>>> the PR level (no need to go to CI to check which
> step
> > > > > failed).
> > > > > > > The
> > > > > > > > > >>>> build
> > > > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Does any of you have any experience with Github
> > Actions?
> > > > Any
> > > > > > > > > >>>> thoughts
> > > > > > > > > >>>>>> about using it?
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Best,
> > > > > > > > > >>>>>> Tomek
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > >>>> wrote:
> > > > > > > > > >>>>>>> FYI: Interesting article about the history behind
> > > > GitLabCI
> > > > > > > > > >>>> (featuring
> > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > >>>>>>> wrote:
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can
> fairly
> > > > easily
> > > > > > > > > >>>> replicate
> > > > > > > > > >>>>>> the
> > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it
> > > > > generally
> > > > > > > > > >>>> works, I
> > > > > > > > > >>>>>> can
> > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the
> main
> > > > > Airflow
> > > > > > > > > >>>> project
> > > > > > > > > >>>>>> for a
> > > > > > > > > >>>>>>>> few weeks to see how it is doing (while I am no
> > > > holidays)
> > > > > > and
> > > > > > > > > >>>> once we
> > > > > > > > > >>>>>> see
> > > > > > > > > >>>>>>>> it running and get the support for PRs from GitLab
> > we
> > > > can
> > > > > > > > > >>>> switch to
> > > > > > > > > >>>>> it.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> What do you think ? Should i call a vote or just
> try
> > > to
> > > > > set
> > > > > > it
> > > > > > > > > >>>> up ?
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> Some details
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> - I manged to get full working builds in GitLabCI
> +
> > > > > > > > > >>>> kubernetes -
> > > > > > > > > >>>>>>>> without the kubernetes-specific tests yet, but
> this
> > > > should
> > > > > > > > > >>>> be
> > > > > > > > > >>>>>> rather easy
> > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > >>>>>>>> - Working example here - you can take a look and
> > > compare
> > > > > the
> > > > > > > > > >>>>> UI/how
> > > > > > > > > >>>>>> it
> > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > >>>>>>>>
> > > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far
> > (still
> > > > > > > > > >>>> around 35
> > > > > > > > > >>>>>>>> minutes in total), but I plan to optimise it
> > further.
> > > I
> > > > > can
> > > > > > > > > >>>> play
> > > > > > > > > >>>>>> with
> > > > > > > > > >>>>>>>> memory/cpu settings of individual workers (Got
> some
> > > > > > > > > >>>> reasonable
> > > > > > > > > >>>>>> values now),
> > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> storage/logs/etc
> > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for
> initial
> > > > 24) -
> > > > > > > > > >>>> that
> > > > > > > > > >>>>>> should
> > > > > > > > > >>>>>>>> let us build 3 builds in parallel independently
> from
> > > > each
> > > > > > > > > >>>> other.
> > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes working (we
> > have
> > > > > built
> > > > > > > > > >>>> in
> > > > > > > > > >>>>> retry
> > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of system
> > failures
> > > > > like
> > > > > > > > > >>>> that
> > > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We
> > > > should
> > > > > be
> > > > > > > > > >>>> way
> > > > > > > > > >>>>>> below
> > > > > > > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > > > > > > >>>> calculations.
> > > > > > > > > >>>>>> Likely
> > > > > > > > > >>>>>>>> well below
> > > > > > > > > >>>>>>>> - The current setup does not use GCR as cache and
> > > Kaniko
> > > > > as
> > > > > > > > > >>>> I
> > > > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > > > authentication
> > > > > > > > > >>>> (and
> > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet
> well
> > > > handle
> > > > > > > > > >>>>>> multi-staging
> > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > >>>>>>>>
> > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > ).
> > > > > > > > > >>>> I
> > > > > > > > > >>>>>> updated
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > >>>>>> to
> > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so
> > that
> > > we
> > > > > can
> > > > > > > > > >>>> have
> > > > > > > > > >>>>>>>> reliable downloads not depending on DockerHub's
> > > > stability
> > > > > > > > > >>>> (it has
> > > > > > > > > >>>>>> problems
> > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be
> run
> > in
> > > > any
> > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > >>>>>>>> cluster (some optimisations like local volumes
> > > mounting
> > > > > for
> > > > > > > > > >>>> docker
> > > > > > > > > >>>>>> engine
> > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but should be
> > > > > generally
> > > > > > > > > >>>>>> replicable).
> > > > > > > > > >>>>>>>> - You can take a look at the current source code
> in
> > > > > > > > > >>>>>>>>
> > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > >>>>>>>> - There will be some updates (I will get rid of
> > custom
> > > > > > > > > >>>> builder
> > > > > > > > > >>>>>> Docker,
> > > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes tests)
> -
> > > it's
> > > > > > > > > >>>> mostly
> > > > > > > > > >>>>> some
> > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific variables +
> > > > > gitlab.ci
> > > > > > > > > >>>> yaml
> > > > > > > > > >>>>>> with
> > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> J.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>> So GitLab already works on automatically running
> > > builds
> > > > > > from
> > > > > > > > > >>>> for PRs
> > > > > > > > > >>>>>> :).
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>> Kamil got involved and will be out advocate on
> it:
> > > > > > > > > >>>>>>>>>
> > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > >>>>>>>>> J.
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > > > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>>>>>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>> --
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > > Software
> > > > > > > > > >>>> Engineer
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> --
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > Software
> > > > > > > > > >>>> Engineer
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> --
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > Software
> > > > > > > Engineer
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> --
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal
> > Software
> > > > > > Engineer
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>> [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/>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Tomasz Urbaszek
> > > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > > >
> > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > > >
> > > > > > > Unique Tech
> > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Jarek Potiuk
> > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > >
> > > > > M: +48 660 796 129 <+48660796129>
> > > > > [image: Polidea] <https://www.polidea.com/>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Tomasz Urbaszek
> > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > >
> > > > M: +48 505 628 493 <+48505628493>
> > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > > Unique Tech
> > > > Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
>
>
> --
>
> Tomasz Urbaszek
> Polidea <https://www.polidea.com/> | Software Engineer
>
> M: +48 505 628 493 <+48505628493>
> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <tu...@apache.org>]

Hi all,

To decrease pressure on Travis and our frustration some CI workloads were
moved to Github Actions:
https://github.com/apache/airflow/pull/8376

Hopefully there will be no failing builds...

We stil run kube tests and backports build on Travis. Further improvements
are on the way.
Thanks to Jarek Potiuk and Daniel Imberman for help and support!

Best wishes,
Tomek

On Sat, Jan 11, 2020 at 2:50 PM Kaxil Naik <ka...@gmail.com> wrote:

> Spark is using Github actions too so shouldn't be a problem I think.
>
> On Sat, Jan 11, 2020 at 1:22 PM Tomasz Urbaszek <tu...@apache.org>
> wrote:
>
> > Yes, I thought that there was limit (the docs are little bit unclear
> > regarding this issue).
> >
> > T.
> >
> > On Sat, 11 Jan 2020 at 13:32, Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Oh wow! That's fantastic! Indeed it looks like in the pricing docs. I
> am
> > > sure we discussed before that there is a limit :).
> > >
> > > J.
> > >
> > >
> > > On Sat, Jan 11, 2020 at 12:41 PM Tomasz Urbaszek <turbaszek@apache.org
> >
> > > wrote:
> > >
> > > > I have checked and Github Actions have unlimited minutes for open
> > > > repositories.
> > > >
> > > > T
> > > >
> > > > On Sat, 11 Jan 2020 at 12:27, Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > > wrote:
> > > >
> > > > > I am working on some last fixes to Kind improvement PR and get it
> > ready
> > > > to
> > > > > merge today - I hope :). Also looking forward to moving out of
> Travis
> > > > > finally.
> > > > >
> > > > > One more thought - we think the best way to approach it is to
> enable
> > > > Github
> > > > > Actions in parallel to Travis and keep it running in parallel to
> make
> > > > sure
> > > > > it is stable.
> > > > >
> > > > > Then we can disable Travis but we can keep it available to switch
> it
> > on
> > > > > again as needed.
> > > > >
> > > > > I think the main semi-open point we have with GA is the
> availability
> > of
> > > > > credits for GCP.  The free minutes from Github will not be enough
> for
> > > > sure,
> > > > > Tomek already runs it on the GCP account we got from Google, but we
> > > need
> > > > to
> > > > > secure the credits for the future as well. I will take on that task
> > > with
> > > > > Aizhamal but we need to keep it running for some time to understand
> > > what
> > > > > the usage might be.
> > > > >
> > > > > We can also talk to Github and other providers as well and maybe
> get
> > > some
> > > > > credit donations from other people/companies (maybe we could join
> > > 'Github
> > > > > Sponsors" project and start getting some money through that
> > > > > https://github.com/sponsors)? I think having several sources of
> > > funding
> > > > > for
> > > > > our compute resources might be a good idea. WDYT?
> > > > >
> > > > > J
> > > > >
> > > > > On Sat, Jan 11, 2020 at 11:41 AM Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Yeah, that would be nice.
> > > > > >
> > > > > > On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <
> turbaszek@apache.org>
> > > > > wrote:
> > > > > >
> > > > > > > An additional advantage of GA + self-hosted runners is the
> > ability
> > > to
> > > > > > > ssh to machine and see what is going on (for example why tests
> > > > > timeout).
> > > > > > >
> > > > > > > T.
> > > > > > >
> > > > > > > On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <
> kaxilnaik@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Awesome Tomek, great job. Waiting for your PR eagerly :) and
> > > can't
> > > > > wait
> > > > > > > to
> > > > > > > > move out of Travis.
> > > > > > > >
> > > > > > > > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > Just a small update:
> > > > > > > > > - after Jarek's changes from
> > > > > > > https://github.com/apache/airflow/pull/6516
> > > > > > > > > kubernetes
> > > > > > > > >   builds started to run (proviously there was an issue with
> > > kind)
> > > > > > > > > - I am testing self-hosted runners
> > > > > > > > >
> > > > > > > > > It seems that possible migration is getting closer ;)
> > > > > > > > >
> > > > > > > > > Bests,
> > > > > > > > > Tomek
> > > > > > > > >
> > > > > > > > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <
> > > > > > philgagnon1@gmail.com
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > We have been using Actions on the prestosql project for a
> > > > little
> > > > > > > while
> > > > > > > > > as a
> > > > > > > > > > Travis replacement and we like it a lot.
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > :(
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > I started to play with self-hosted runner and...
> well,
> > > > > > > encountered
> > > > > > > > > > known
> > > > > > > > > > > > error:
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > > > > > > > >
> > > > > > > > > > > > It seems that GA is still maturing.
> > > > > > > > > > > >
> > > > > > > > > > > > Bests,
> > > > > > > > > > > > Tomek
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > > > > > > > >
> > > > > > > > > > > > > J.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> > > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > > > > > > > daniel.imberman@gmail.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I’d rather we do it all at once and not need to
> > > > > maintain
> > > > > > > two
> > > > > > > > > > > builds.
> > > > > > > > > > > > > > > Most/all of our CI/CD is dockerized at this
> point
> > > so
> > > > > > there
> > > > > > > > > > > shouldn’t
> > > > > > > > > > > > > be a
> > > > > > > > > > > > > > > huge difference.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz
> Urbaszek
> > <
> > > > > > > > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > I have to solve a problem with our kubernetes
> > test
> > > > but
> > > > > > for
> > > > > > > > your
> > > > > > > > > > > > > > information
> > > > > > > > > > > > > > > I have never experienced a flaky
> > > > > > > > > > > > > > > or timeouted build on Github Actions. Maybe I
> am
> > > > lucky
> > > > > or
> > > > > > > > maybe
> > > > > > > > > > > > there's
> > > > > > > > > > > > > > > something different.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If we agree to move to Github Actions, would we
> > > like
> > > > to
> > > > > > > > migrate
> > > > > > > > > > > > > > > incrementally or fully?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Bests,
> > > > > > > > > > > > > > > Tomek
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > No problem on that side - Tomek is using the
> > same
> > > > > > scripts
> > > > > > > > we
> > > > > > > > > > have
> > > > > > > > > > > > on
> > > > > > > > > > > > > > > Travis
> > > > > > > > > > > > > > > > (and they generally work - I think the last
> > step
> > > is
> > > > > to
> > > > > > > make
> > > > > > > > > all
> > > > > > > > > > > the
> > > > > > > > > > > > > > > > tests pass. We have still a number of
> > > dependencies
> > > > > > > between
> > > > > > > > > > tests
> > > > > > > > > > > > and
> > > > > > > > > > > > > > some
> > > > > > > > > > > > > > > > environmental flakiness so that some tests
> > > > > consistently
> > > > > > > > fail
> > > > > > > > > in
> > > > > > > > > > > > > Github
> > > > > > > > > > > > > > > > Actions where they did not fail in Travis.
> From
> > > > > latest
> > > > > > > try
> > > > > > > > by
> > > > > > > > > > > Tomek
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > looks like we are 1 test to go (plus some
> > > > > cleanup/setup
> > > > > > > of
> > > > > > > > > > > project
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > making sure all is stable):
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16
> > > > warnings
> > > > > in
> > > > > > > > > > 1207.96s
> > > > > > > > > > > > > > > (0:20:07)
> > > > > > > > > > > > > > > > =====
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > We discussed with Tomek and Kamil that in
> order
> > > to
> > > > > > speed
> > > > > > > it
> > > > > > > > > up
> > > > > > > > > > we
> > > > > > > > > > > > > might
> > > > > > > > > > > > > > > > want to run our own workers on the GCP
> account
> > we
> > > > > have
> > > > > > -
> > > > > > > > just
> > > > > > > > > > to
> > > > > > > > > > > > test
> > > > > > > > > > > > > > > > quickly how much we can optimise it and I am
> > > > inclined
> > > > > > to
> > > > > > > > > agree.
> > > > > > > > > > > If
> > > > > > > > > > > > we
> > > > > > > > > > > > > > do
> > > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > this way, the transition might be rather
> fast.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > If we want to use auto-scalable GKE cluster
> as
> > we
> > > > > > > > originally
> > > > > > > > > > > > planned
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > might take more time to setup (similar setup
> to
> > > > what
> > > > > I
> > > > > > > > tried
> > > > > > > > > > with
> > > > > > > > > > > > > > > GitLab).
> > > > > > > > > > > > > > > > There we might need to use docker-in-docker
> to
> > > > build
> > > > > > the
> > > > > > > CI
> > > > > > > > > > image
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > > latest as first step of build and then use
> that
> > > > built
> > > > > > > image
> > > > > > > > > by
> > > > > > > > > > > all
> > > > > > > > > > > > > > > > subsequent steps. But we can do it as the
> next
> > > > step -
> > > > > > > > > > optimising
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > experience.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > J.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel
> > Imberman
> > > <
> > > > > > > > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > @jarek does this affect anything involving
> > > > breeze?
> > > > > Do
> > > > > > > > > GitHub
> > > > > > > > > > > > > actions
> > > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > > an easy docker/docker-compose based
> workflow?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > via Newton Mail [
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > > > > > > > ]
> > > > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash
> > > > Berlin-Taylor
> > > > > <
> > > > > > > > > > > > ash@apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Infra: possibly yes to get secrets in there
> > to
> > > > run
> > > > > > > things
> > > > > > > > > on
> > > > > > > > > > > our
> > > > > > > > > > > > > own
> > > > > > > > > > > > > > > > > "hardware" -
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > needs someone with Admin rights to create,
> > and
> > > I
> > > > > > don't
> > > > > > > > see
> > > > > > > > > > the
> > > > > > > > > > > > > > Settings
> > > > > > > > > > > > > > > > tab
> > > > > > > > > > > > > > > > > at all.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > -ash
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > > > > > > > xd.deng.r@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > +1 for GitHub Actions. I have been using
> it
> > > for
> > > > > > > months
> > > > > > > > > for
> > > > > > > > > > my
> > > > > > > > > > > > > side
> > > > > > > > > > > > > > > > > > projects, and it’s working very well. I
> > > believe
> > > > > > most
> > > > > > > of
> > > > > > > > > us
> > > > > > > > > > > are
> > > > > > > > > > > > > > quite
> > > > > > > > > > > > > > > > > tired
> > > > > > > > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > The only point I would like to remind is
> > > > whether
> > > > > we
> > > > > > > > need
> > > > > > > > > to
> > > > > > > > > > > > > > > communicate
> > > > > > > > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > XD
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik
> <
> > > > > > > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash
> > > Berlin-Taylor <
> > > > > > > > > > > ash@apache.org>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >>> Happy with any thing that gives a more
> > > > seamless
> > > > > > CI
> > > > > > > > > > > > experience -
> > > > > > > > > > > > > > > > faster
> > > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > > >>> good too!
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> -a
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT,
> Aizhamal
> > > > > > Nurmamat
> > > > > > > > > kyzy <
> > > > > > > > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek
> > > Potiuk
> > > > <
> > > > > > > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>>> I am all for it! GitLab has been
> > > less-than
> > > > > > > helpful
> > > > > > > > so
> > > > > > > > > > far
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >>>> recently it
> > > > > > > > > > > > > > > > > >>>>> seems that running PRs from forks
> will
> > > only
> > > > > be
> > > > > > > run
> > > > > > > > in
> > > > > > > > > > > > > > Enterrprise
> > > > > > > > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > > > > > > > >>>>> which is less than welcome. I am
> quite
> > a
> > > > bit
> > > > > > > > > > disappointed
> > > > > > > > > > > > > with
> > > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >>>> pace and
> > > > > > > > > > > > > > > > > >>>>> attitude. Github Actions seems to be
> > much
> > > > > > better
> > > > > > > > > > choice -
> > > > > > > > > > > > > > > > especially
> > > > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > > > >>>>> they are closely integrated with
> Github
> > > > repo
> > > > > > and
> > > > > > > > seem
> > > > > > > > > > to
> > > > > > > > > > > > get
> > > > > > > > > > > > > > > > > >>>>> attention/focus from
> Github/Microsoft.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>> And they added self-hosted runners as
> > > well,
> > > > > > which
> > > > > > > > > makes
> > > > > > > > > > > it
> > > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > > >>>> for us
> > > > > > > > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM
> Tomasz
> > > > > > Urbaszek <
> > > > > > > > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>> It sometime since we last discussed
> > > using
> > > > > > other
> > > > > > > CI
> > > > > > > > > > than
> > > > > > > > > > > > > > Travis.
> > > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > > >>>> of
> > > > > > > > > > > > > > > > > >>>>> the
> > > > > > > > > > > > > > > > > >>>>>> main reasons behind considering
> Gitlab
> > > CI
> > > > > was
> > > > > > > its
> > > > > > > > > > > ability
> > > > > > > > > > > > to
> > > > > > > > > > > > > > > work
> > > > > > > > > > > > > > > > > >>>> on
> > > > > > > > > > > > > > > > > >>>>>> self-hosted runner. However, over
> time
> > > of
> > > > > few
> > > > > > > long
> > > > > > > > > > weeks
> > > > > > > > > > > > > > Github
> > > > > > > > > > > > > > > > > >>>> Actions
> > > > > > > > > > > > > > > > > >>>>>> matured enough to allow using
> > > self-hosted
> > > > > > > runners!
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>> Github Actions are still growing but
> > > using
> > > > > > them
> > > > > > > > have
> > > > > > > > > > few
> > > > > > > > > > > > big
> > > > > > > > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > > > > > > > >>>>>> - forking repo and enabling actions
> > will
> > > > run
> > > > > > CI
> > > > > > > on
> > > > > > > > > > your
> > > > > > > > > > > > fork
> > > > > > > > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > > > > > > > >>>>>> - variety of actions (PR checks,
> > > > greetings,
> > > > > > etc)
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>> I put together a PoC of CI in our
> > > internal
> > > > > > repo:
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > > > > > > > >>>>>> My impression is quite good. I like
> > > > > > information
> > > > > > > > > about
> > > > > > > > > > > > steps
> > > > > > > > > > > > > > > > > >>>> successes at
> > > > > > > > > > > > > > > > > >>>>>> the PR level (no need to go to CI to
> > > check
> > > > > > which
> > > > > > > > > step
> > > > > > > > > > > > > failed).
> > > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > > >>>> build
> > > > > > > > > > > > > > > > > >>>>>> log view is a little bit clumsy but
> it
> > > > > works.
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>> Does any of you have any experience
> > with
> > > > > > Github
> > > > > > > > > > Actions?
> > > > > > > > > > > > Any
> > > > > > > > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek
> Potiuk <
> > > > > > > > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > > >>>>>>> FYI: Interesting article about the
> > > > history
> > > > > > > behind
> > > > > > > > > > > > GitLabCI
> > > > > > > > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM
> Jarek
> > > > Potiuk
> > > > > > > > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> Some update on my GitLab
> experiences
> > > so
> > > > > far:
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown
> > that
> > > we
> > > > > can
> > > > > > > > > fairly
> > > > > > > > > > > > easily
> > > > > > > > > > > > > > > > > >>>> replicate
> > > > > > > > > > > > > > > > > >>>>>> the
> > > > > > > > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I
> think i
> > > can
> > > > > > say -
> > > > > > > > it
> > > > > > > > > > > > > generally
> > > > > > > > > > > > > > > > > >>>> works, I
> > > > > > > > > > > > > > > > > >>>>>> can
> > > > > > > > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test
> > > builds
> > > > in
> > > > > > the
> > > > > > > > > main
> > > > > > > > > > > > > Airflow
> > > > > > > > > > > > > > > > > >>>> project
> > > > > > > > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > > > > > > > >>>>>>>> few weeks to see how it is doing
> > > (while
> > > > I
> > > > > am
> > > > > > > no
> > > > > > > > > > > > holidays)
> > > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > > >>>> once we
> > > > > > > > > > > > > > > > > >>>>>> see
> > > > > > > > > > > > > > > > > >>>>>>>> it running and get the support for
> > PRs
> > > > > from
> > > > > > > > GitLab
> > > > > > > > > > we
> > > > > > > > > > > > can
> > > > > > > > > > > > > > > > > >>>> switch to
> > > > > > > > > > > > > > > > > >>>>> it.
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> What do you think ? Should i call
> a
> > > vote
> > > > > or
> > > > > > > just
> > > > > > > > > try
> > > > > > > > > > > to
> > > > > > > > > > > > > set
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > > >>>> up ?
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> - I manged to get full working
> > builds
> > > in
> > > > > > > > GitLabCI
> > > > > > > > > +
> > > > > > > > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > > > > > > > >>>>>>>> without the kubernetes-specific
> > tests
> > > > yet,
> > > > > > but
> > > > > > > > > this
> > > > > > > > > > > > should
> > > > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > > > > > > > >>>>>>>> - Working example here - you can
> > take
> > > a
> > > > > look
> > > > > > > and
> > > > > > > > > > > compare
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > > > > > > > >>>>>> it
> > > > > > > > > > > > > > > > > >>>>>>>> is to navigate, comparing to
> Travis
> > > etc:
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >
> > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than
> > > Travis
> > > > > so
> > > > > > > far
> > > > > > > > > > (still
> > > > > > > > > > > > > > > > > >>>> around 35
> > > > > > > > > > > > > > > > > >>>>>>>> minutes in total), but I plan to
> > > > optimise
> > > > > it
> > > > > > > > > > further.
> > > > > > > > > > > I
> > > > > > > > > > > > > can
> > > > > > > > > > > > > > > > > >>>> play
> > > > > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > > > > >>>>>>>> memory/cpu settings of individual
> > > > workers
> > > > > > (Got
> > > > > > > > > some
> > > > > > > > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > > > > > > > storage/logs/etc
> > > > > > > > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU
> quota
> > > (up
> > > > > for
> > > > > > > > > initial
> > > > > > > > > > > > 24) -
> > > > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > > > >>>>>> should
> > > > > > > > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> > > > > > > independently
> > > > > > > > > from
> > > > > > > > > > > > each
> > > > > > > > > > > > > > > > > >>>> other.
> > > > > > > > > > > > > > > > > >>>>>>>> - I managed to get Preemptible
> nodes
> > > > > working
> > > > > > > (we
> > > > > > > > > > have
> > > > > > > > > > > > > built
> > > > > > > > > > > > > > > > > >>>> in
> > > > > > > > > > > > > > > > > >>>>> retry
> > > > > > > > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in
> case
> > of
> > > > > > system
> > > > > > > > > > failures
> > > > > > > > > > > > > like
> > > > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > > > >>>>>>>> - Current spending with > 120
> builds
> > > is
> > > > 40
> > > > > > > USD.
> > > > > > > > We
> > > > > > > > > > > > should
> > > > > > > > > > > > > be
> > > > > > > > > > > > > > > > > >>>> way
> > > > > > > > > > > > > > > > > >>>>>> below
> > > > > > > > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > > > > > > > back-of-the-envelope
> > > > > > > > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > > > > > > > >>>>>>>> - The current setup does not use
> GCR
> > > as
> > > > > > cache
> > > > > > > > and
> > > > > > > > > > > Kaniko
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > > > > >>>>>>>> originally planned. GCR would
> > require
> > > > > custom
> > > > > > > > > > > > > authentication
> > > > > > > > > > > > > > > > > >>>> (and
> > > > > > > > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko
> > does
> > > > not
> > > > > > yet
> > > > > > > > > well
> > > > > > > > > > > > handle
> > > > > > > > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >
> > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > > > > > > > ).
> > > > > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > > > > > > > >>>>>> to
> > > > > > > > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of
> > > > > DockerHub
> > > > > > -
> > > > > > > so
> > > > > > > > > > that
> > > > > > > > > > > we
> > > > > > > > > > > > > can
> > > > > > > > > > > > > > > > > >>>> have
> > > > > > > > > > > > > > > > > >>>>>>>> reliable downloads not depending
> on
> > > > > > > DockerHub's
> > > > > > > > > > > > stability
> > > > > > > > > > > > > > > > > >>>> (it has
> > > > > > > > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > > > > > > > >>>>>>>> - All in-all, it's
> GCP-independent.
> > It
> > > > > could
> > > > > > > be
> > > > > > > > > run
> > > > > > > > > > in
> > > > > > > > > > > > any
> > > > > > > > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > > > > > > > >>>>>>>> cluster (some optimisations like
> > local
> > > > > > volumes
> > > > > > > > > > > mounting
> > > > > > > > > > > > > for
> > > > > > > > > > > > > > > > > >>>> docker
> > > > > > > > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > > > > > > > >>>>>>>> might have GCP-specific
> assumptions,
> > > but
> > > > > > > should
> > > > > > > > be
> > > > > > > > > > > > > generally
> > > > > > > > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > > > > > > > >>>>>>>> - You can take a look at the
> current
> > > > > source
> > > > > > > code
> > > > > > > > > in
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >
> > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > > > > > > > >>>>>>>> - There will be some updates (I
> will
> > > get
> > > > > rid
> > > > > > > of
> > > > > > > > > > custom
> > > > > > > > > > > > > > > > > >>>> builder
> > > > > > > > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > > > > > > > >>>>>>>> simplify it a bit and implement
> > > > kubernetes
> > > > > > > > tests)
> > > > > > > > > -
> > > > > > > > > > > it's
> > > > > > > > > > > > > > > > > >>>> mostly
> > > > > > > > > > > > > > > > > >>>>> some
> > > > > > > > > > > > > > > > > >>>>>>>> cleanups + removal of
> > Travis-Specific
> > > > > > > variables
> > > > > > > > +
> > > > > > > > > > > > > gitlab.ci
> > > > > > > > > > > > > > > > > >>>> yaml
> > > > > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM
> > Jarek
> > > > > > Potiuk
> > > > > > > <
> > > > > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>> So GitLab already works on
> > > > automatically
> > > > > > > > running
> > > > > > > > > > > builds
> > > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>> Kamil got involved and will be
> out
> > > > > advocate
> > > > > > > on
> > > > > > > > > it:
> > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > > > > > > > >>>>>>>>> Phone: +48660796129
> > > > > <+48%20660%20796%20129>
> > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12
> użytkownik
> > > > Jarek
> > > > > > > > Potiuk <
> > > > > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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
> > > > > > <+48%20660%20796%20129>
> > > > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> > > > > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > > > >>>>>>>>>> Polidea <
> https://www.polidea.com/
> > >
> > > |
> > > > > > > > Principal
> > > > > > > > > > > > Software
> > > > > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129
> > > > > <+48%20660%20796%20129>
> > > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > > > >>>>>>>>>> [image: Polidea] <
> > > > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/
> >
> > |
> > > > > > > Principal
> > > > > > > > > > > Software
> > > > > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>> M: +48 660 796 129
> > > > <+48%20660%20796%20129>
> > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > > > >>>>>>>> [image: Polidea] <
> > > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/>
> |
> > > > > > Principal
> > > > > > > > > > > Software
> > > > > > > > > > > > > > > Engineer
> > > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > > >>>>>>> M: +48 660 796 129
> > > > <+48%20660%20796%20129>
> > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > > >>>>> <+
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kaxil Naik <ka...@gmail.com>]

Spark is using Github actions too so shouldn't be a problem I think.

On Sat, Jan 11, 2020 at 1:22 PM Tomasz Urbaszek <tu...@apache.org>
wrote:

> Yes, I thought that there was limit (the docs are little bit unclear
> regarding this issue).
>
> T.
>
> On Sat, 11 Jan 2020 at 13:32, Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Oh wow! That's fantastic! Indeed it looks like in the pricing docs. I am
> > sure we discussed before that there is a limit :).
> >
> > J.
> >
> >
> > On Sat, Jan 11, 2020 at 12:41 PM Tomasz Urbaszek <tu...@apache.org>
> > wrote:
> >
> > > I have checked and Github Actions have unlimited minutes for open
> > > repositories.
> > >
> > > T
> > >
> > > On Sat, 11 Jan 2020 at 12:27, Jarek Potiuk <Ja...@polidea.com>
> > > wrote:
> > >
> > > > I am working on some last fixes to Kind improvement PR and get it
> ready
> > > to
> > > > merge today - I hope :). Also looking forward to moving out of Travis
> > > > finally.
> > > >
> > > > One more thought - we think the best way to approach it is to enable
> > > Github
> > > > Actions in parallel to Travis and keep it running in parallel to make
> > > sure
> > > > it is stable.
> > > >
> > > > Then we can disable Travis but we can keep it available to switch it
> on
> > > > again as needed.
> > > >
> > > > I think the main semi-open point we have with GA is the availability
> of
> > > > credits for GCP.  The free minutes from Github will not be enough for
> > > sure,
> > > > Tomek already runs it on the GCP account we got from Google, but we
> > need
> > > to
> > > > secure the credits for the future as well. I will take on that task
> > with
> > > > Aizhamal but we need to keep it running for some time to understand
> > what
> > > > the usage might be.
> > > >
> > > > We can also talk to Github and other providers as well and maybe get
> > some
> > > > credit donations from other people/companies (maybe we could join
> > 'Github
> > > > Sponsors" project and start getting some money through that
> > > > https://github.com/sponsors)? I think having several sources of
> > funding
> > > > for
> > > > our compute resources might be a good idea. WDYT?
> > > >
> > > > J
> > > >
> > > > On Sat, Jan 11, 2020 at 11:41 AM Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > >
> > > > > Yeah, that would be nice.
> > > > >
> > > > > On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <tu...@apache.org>
> > > > wrote:
> > > > >
> > > > > > An additional advantage of GA + self-hosted runners is the
> ability
> > to
> > > > > > ssh to machine and see what is going on (for example why tests
> > > > timeout).
> > > > > >
> > > > > > T.
> > > > > >
> > > > > > On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Awesome Tomek, great job. Waiting for your PR eagerly :) and
> > can't
> > > > wait
> > > > > > to
> > > > > > > move out of Travis.
> > > > > > >
> > > > > > > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > Just a small update:
> > > > > > > > - after Jarek's changes from
> > > > > > https://github.com/apache/airflow/pull/6516
> > > > > > > > kubernetes
> > > > > > > >   builds started to run (proviously there was an issue with
> > kind)
> > > > > > > > - I am testing self-hosted runners
> > > > > > > >
> > > > > > > > It seems that possible migration is getting closer ;)
> > > > > > > >
> > > > > > > > Bests,
> > > > > > > > Tomek
> > > > > > > >
> > > > > > > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <
> > > > > philgagnon1@gmail.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > We have been using Actions on the prestosql project for a
> > > little
> > > > > > while
> > > > > > > > as a
> > > > > > > > > Travis replacement and we like it a lot.
> > > > > > > > >
> > > > > > > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> > > > > > Jarek.Potiuk@polidea.com
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > :(
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I started to play with self-hosted runner and... well,
> > > > > > encountered
> > > > > > > > > known
> > > > > > > > > > > error:
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > > > > > > >
> > > > > > > > > > > It seems that GA is still maturing.
> > > > > > > > > > >
> > > > > > > > > > > Bests,
> > > > > > > > > > > Tomek
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > > > > > > >
> > > > > > > > > > > > J.
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > > > > > > daniel.imberman@gmail.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > I’d rather we do it all at once and not need to
> > > > maintain
> > > > > > two
> > > > > > > > > > builds.
> > > > > > > > > > > > > > Most/all of our CI/CD is dockerized at this point
> > so
> > > > > there
> > > > > > > > > > shouldn’t
> > > > > > > > > > > > be a
> > > > > > > > > > > > > > huge difference.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek
> <
> > > > > > > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I have to solve a problem with our kubernetes
> test
> > > but
> > > > > for
> > > > > > > your
> > > > > > > > > > > > > information
> > > > > > > > > > > > > > I have never experienced a flaky
> > > > > > > > > > > > > > or timeouted build on Github Actions. Maybe I am
> > > lucky
> > > > or
> > > > > > > maybe
> > > > > > > > > > > there's
> > > > > > > > > > > > > > something different.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If we agree to move to Github Actions, would we
> > like
> > > to
> > > > > > > migrate
> > > > > > > > > > > > > > incrementally or fully?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Bests,
> > > > > > > > > > > > > > Tomek
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > No problem on that side - Tomek is using the
> same
> > > > > scripts
> > > > > > > we
> > > > > > > > > have
> > > > > > > > > > > on
> > > > > > > > > > > > > > Travis
> > > > > > > > > > > > > > > (and they generally work - I think the last
> step
> > is
> > > > to
> > > > > > make
> > > > > > > > all
> > > > > > > > > > the
> > > > > > > > > > > > > > > tests pass. We have still a number of
> > dependencies
> > > > > > between
> > > > > > > > > tests
> > > > > > > > > > > and
> > > > > > > > > > > > > some
> > > > > > > > > > > > > > > environmental flakiness so that some tests
> > > > consistently
> > > > > > > fail
> > > > > > > > in
> > > > > > > > > > > > Github
> > > > > > > > > > > > > > > Actions where they did not fail in Travis. From
> > > > latest
> > > > > > try
> > > > > > > by
> > > > > > > > > > Tomek
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > looks like we are 1 test to go (plus some
> > > > cleanup/setup
> > > > > > of
> > > > > > > > > > project
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > making sure all is stable):
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16
> > > warnings
> > > > in
> > > > > > > > > 1207.96s
> > > > > > > > > > > > > > (0:20:07)
> > > > > > > > > > > > > > > =====
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > We discussed with Tomek and Kamil that in order
> > to
> > > > > speed
> > > > > > it
> > > > > > > > up
> > > > > > > > > we
> > > > > > > > > > > > might
> > > > > > > > > > > > > > > want to run our own workers on the GCP account
> we
> > > > have
> > > > > -
> > > > > > > just
> > > > > > > > > to
> > > > > > > > > > > test
> > > > > > > > > > > > > > > quickly how much we can optimise it and I am
> > > inclined
> > > > > to
> > > > > > > > agree.
> > > > > > > > > > If
> > > > > > > > > > > we
> > > > > > > > > > > > > do
> > > > > > > > > > > > > > it
> > > > > > > > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If we want to use auto-scalable GKE cluster as
> we
> > > > > > > originally
> > > > > > > > > > > planned
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > might take more time to setup (similar setup to
> > > what
> > > > I
> > > > > > > tried
> > > > > > > > > with
> > > > > > > > > > > > > > GitLab).
> > > > > > > > > > > > > > > There we might need to use docker-in-docker to
> > > build
> > > > > the
> > > > > > CI
> > > > > > > > > image
> > > > > > > > > > > > with
> > > > > > > > > > > > > > > latest as first step of build and then use that
> > > built
> > > > > > image
> > > > > > > > by
> > > > > > > > > > all
> > > > > > > > > > > > > > > subsequent steps. But we can do it as the next
> > > step -
> > > > > > > > > optimising
> > > > > > > > > > > the
> > > > > > > > > > > > > > > experience.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > J.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel
> Imberman
> > <
> > > > > > > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > @jarek does this affect anything involving
> > > breeze?
> > > > Do
> > > > > > > > GitHub
> > > > > > > > > > > > actions
> > > > > > > > > > > > > > have
> > > > > > > > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > via Newton Mail [
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > > > > > > ]
> > > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash
> > > Berlin-Taylor
> > > > <
> > > > > > > > > > > ash@apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Infra: possibly yes to get secrets in there
> to
> > > run
> > > > > > things
> > > > > > > > on
> > > > > > > > > > our
> > > > > > > > > > > > own
> > > > > > > > > > > > > > > > "hardware" -
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > needs someone with Admin rights to create,
> and
> > I
> > > > > don't
> > > > > > > see
> > > > > > > > > the
> > > > > > > > > > > > > Settings
> > > > > > > > > > > > > > > tab
> > > > > > > > > > > > > > > > at all.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -ash
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > > > > > > xd.deng.r@gmail.com
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > +1 for GitHub Actions. I have been using it
> > for
> > > > > > months
> > > > > > > > for
> > > > > > > > > my
> > > > > > > > > > > > side
> > > > > > > > > > > > > > > > > projects, and it’s working very well. I
> > believe
> > > > > most
> > > > > > of
> > > > > > > > us
> > > > > > > > > > are
> > > > > > > > > > > > > quite
> > > > > > > > > > > > > > > > tired
> > > > > > > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The only point I would like to remind is
> > > whether
> > > > we
> > > > > > > need
> > > > > > > > to
> > > > > > > > > > > > > > communicate
> > > > > > > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > XD
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > > > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash
> > Berlin-Taylor <
> > > > > > > > > > ash@apache.org>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >>> Happy with any thing that gives a more
> > > seamless
> > > > > CI
> > > > > > > > > > > experience -
> > > > > > > > > > > > > > > faster
> > > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > > >>> good too!
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>> -a
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal
> > > > > Nurmamat
> > > > > > > > kyzy <
> > > > > > > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek
> > Potiuk
> > > <
> > > > > > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>>> I am all for it! GitLab has been
> > less-than
> > > > > > helpful
> > > > > > > so
> > > > > > > > > far
> > > > > > > > > > > and
> > > > > > > > > > > > > > > > >>>> recently it
> > > > > > > > > > > > > > > > >>>>> seems that running PRs from forks will
> > only
> > > > be
> > > > > > run
> > > > > > > in
> > > > > > > > > > > > > Enterrprise
> > > > > > > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > > > > > > >>>>> which is less than welcome. I am quite
> a
> > > bit
> > > > > > > > > disappointed
> > > > > > > > > > > > with
> > > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >>>> pace and
> > > > > > > > > > > > > > > > >>>>> attitude. Github Actions seems to be
> much
> > > > > better
> > > > > > > > > choice -
> > > > > > > > > > > > > > > especially
> > > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > > >>>>> they are closely integrated with Github
> > > repo
> > > > > and
> > > > > > > seem
> > > > > > > > > to
> > > > > > > > > > > get
> > > > > > > > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>> And they added self-hosted runners as
> > well,
> > > > > which
> > > > > > > > makes
> > > > > > > > > > it
> > > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > > >>>> for us
> > > > > > > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz
> > > > > Urbaszek <
> > > > > > > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>> It sometime since we last discussed
> > using
> > > > > other
> > > > > > CI
> > > > > > > > > than
> > > > > > > > > > > > > Travis.
> > > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > > >>>> of
> > > > > > > > > > > > > > > > >>>>> the
> > > > > > > > > > > > > > > > >>>>>> main reasons behind considering Gitlab
> > CI
> > > > was
> > > > > > its
> > > > > > > > > > ability
> > > > > > > > > > > to
> > > > > > > > > > > > > > work
> > > > > > > > > > > > > > > > >>>> on
> > > > > > > > > > > > > > > > >>>>>> self-hosted runner. However, over time
> > of
> > > > few
> > > > > > long
> > > > > > > > > weeks
> > > > > > > > > > > > > Github
> > > > > > > > > > > > > > > > >>>> Actions
> > > > > > > > > > > > > > > > >>>>>> matured enough to allow using
> > self-hosted
> > > > > > runners!
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>> Github Actions are still growing but
> > using
> > > > > them
> > > > > > > have
> > > > > > > > > few
> > > > > > > > > > > big
> > > > > > > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > > > > > > >>>>>> - forking repo and enabling actions
> will
> > > run
> > > > > CI
> > > > > > on
> > > > > > > > > your
> > > > > > > > > > > fork
> > > > > > > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > > > > > > >>>>>> - variety of actions (PR checks,
> > > greetings,
> > > > > etc)
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>> I put together a PoC of CI in our
> > internal
> > > > > repo:
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > > > > > > >>>>>> My impression is quite good. I like
> > > > > information
> > > > > > > > about
> > > > > > > > > > > steps
> > > > > > > > > > > > > > > > >>>> successes at
> > > > > > > > > > > > > > > > >>>>>> the PR level (no need to go to CI to
> > check
> > > > > which
> > > > > > > > step
> > > > > > > > > > > > failed).
> > > > > > > > > > > > > > The
> > > > > > > > > > > > > > > > >>>> build
> > > > > > > > > > > > > > > > >>>>>> log view is a little bit clumsy but it
> > > > works.
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>> Does any of you have any experience
> with
> > > > > Github
> > > > > > > > > Actions?
> > > > > > > > > > > Any
> > > > > > > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > > >>>>>>> FYI: Interesting article about the
> > > history
> > > > > > behind
> > > > > > > > > > > GitLabCI
> > > > > > > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek
> > > Potiuk
> > > > > > > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> Some update on my GitLab experiences
> > so
> > > > far:
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown
> that
> > we
> > > > can
> > > > > > > > fairly
> > > > > > > > > > > easily
> > > > > > > > > > > > > > > > >>>> replicate
> > > > > > > > > > > > > > > > >>>>>> the
> > > > > > > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i
> > can
> > > > > say -
> > > > > > > it
> > > > > > > > > > > > generally
> > > > > > > > > > > > > > > > >>>> works, I
> > > > > > > > > > > > > > > > >>>>>> can
> > > > > > > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test
> > builds
> > > in
> > > > > the
> > > > > > > > main
> > > > > > > > > > > > Airflow
> > > > > > > > > > > > > > > > >>>> project
> > > > > > > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > > > > > > >>>>>>>> few weeks to see how it is doing
> > (while
> > > I
> > > > am
> > > > > > no
> > > > > > > > > > > holidays)
> > > > > > > > > > > > > and
> > > > > > > > > > > > > > > > >>>> once we
> > > > > > > > > > > > > > > > >>>>>> see
> > > > > > > > > > > > > > > > >>>>>>>> it running and get the support for
> PRs
> > > > from
> > > > > > > GitLab
> > > > > > > > > we
> > > > > > > > > > > can
> > > > > > > > > > > > > > > > >>>> switch to
> > > > > > > > > > > > > > > > >>>>> it.
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> What do you think ? Should i call a
> > vote
> > > > or
> > > > > > just
> > > > > > > > try
> > > > > > > > > > to
> > > > > > > > > > > > set
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > > > >>>> up ?
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> - I manged to get full working
> builds
> > in
> > > > > > > GitLabCI
> > > > > > > > +
> > > > > > > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > > > > > > >>>>>>>> without the kubernetes-specific
> tests
> > > yet,
> > > > > but
> > > > > > > > this
> > > > > > > > > > > should
> > > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > > > > > > >>>>>>>> - Working example here - you can
> take
> > a
> > > > look
> > > > > > and
> > > > > > > > > > compare
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > > > > > > >>>>>> it
> > > > > > > > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis
> > etc:
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >
> > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than
> > Travis
> > > > so
> > > > > > far
> > > > > > > > > (still
> > > > > > > > > > > > > > > > >>>> around 35
> > > > > > > > > > > > > > > > >>>>>>>> minutes in total), but I plan to
> > > optimise
> > > > it
> > > > > > > > > further.
> > > > > > > > > > I
> > > > > > > > > > > > can
> > > > > > > > > > > > > > > > >>>> play
> > > > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > > > >>>>>>>> memory/cpu settings of individual
> > > workers
> > > > > (Got
> > > > > > > > some
> > > > > > > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > > > > > > storage/logs/etc
> > > > > > > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota
> > (up
> > > > for
> > > > > > > > initial
> > > > > > > > > > > 24) -
> > > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > > >>>>>> should
> > > > > > > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> > > > > > independently
> > > > > > > > from
> > > > > > > > > > > each
> > > > > > > > > > > > > > > > >>>> other.
> > > > > > > > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes
> > > > working
> > > > > > (we
> > > > > > > > > have
> > > > > > > > > > > > built
> > > > > > > > > > > > > > > > >>>> in
> > > > > > > > > > > > > > > > >>>>> retry
> > > > > > > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case
> of
> > > > > system
> > > > > > > > > failures
> > > > > > > > > > > > like
> > > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > > >>>>>>>> - Current spending with > 120 builds
> > is
> > > 40
> > > > > > USD.
> > > > > > > We
> > > > > > > > > > > should
> > > > > > > > > > > > be
> > > > > > > > > > > > > > > > >>>> way
> > > > > > > > > > > > > > > > >>>>>> below
> > > > > > > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > > > > > > back-of-the-envelope
> > > > > > > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > > > > > > >>>>>>>> - The current setup does not use GCR
> > as
> > > > > cache
> > > > > > > and
> > > > > > > > > > Kaniko
> > > > > > > > > > > > as
> > > > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > > > >>>>>>>> originally planned. GCR would
> require
> > > > custom
> > > > > > > > > > > > authentication
> > > > > > > > > > > > > > > > >>>> (and
> > > > > > > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko
> does
> > > not
> > > > > yet
> > > > > > > > well
> > > > > > > > > > > handle
> > > > > > > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > >
> > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > > > > > > ).
> > > > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > > > > > > >>>>>> to
> > > > > > > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of
> > > > DockerHub
> > > > > -
> > > > > > so
> > > > > > > > > that
> > > > > > > > > > we
> > > > > > > > > > > > can
> > > > > > > > > > > > > > > > >>>> have
> > > > > > > > > > > > > > > > >>>>>>>> reliable downloads not depending on
> > > > > > DockerHub's
> > > > > > > > > > > stability
> > > > > > > > > > > > > > > > >>>> (it has
> > > > > > > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent.
> It
> > > > could
> > > > > > be
> > > > > > > > run
> > > > > > > > > in
> > > > > > > > > > > any
> > > > > > > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > > > > > > >>>>>>>> cluster (some optimisations like
> local
> > > > > volumes
> > > > > > > > > > mounting
> > > > > > > > > > > > for
> > > > > > > > > > > > > > > > >>>> docker
> > > > > > > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > > > > > > >>>>>>>> might have GCP-specific assumptions,
> > but
> > > > > > should
> > > > > > > be
> > > > > > > > > > > > generally
> > > > > > > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > > > > > > >>>>>>>> - You can take a look at the current
> > > > source
> > > > > > code
> > > > > > > > in
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > >
> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > > > > > > >>>>>>>> - There will be some updates (I will
> > get
> > > > rid
> > > > > > of
> > > > > > > > > custom
> > > > > > > > > > > > > > > > >>>> builder
> > > > > > > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > > > > > > >>>>>>>> simplify it a bit and implement
> > > kubernetes
> > > > > > > tests)
> > > > > > > > -
> > > > > > > > > > it's
> > > > > > > > > > > > > > > > >>>> mostly
> > > > > > > > > > > > > > > > >>>>> some
> > > > > > > > > > > > > > > > >>>>>>>> cleanups + removal of
> Travis-Specific
> > > > > > variables
> > > > > > > +
> > > > > > > > > > > > gitlab.ci
> > > > > > > > > > > > > > > > >>>> yaml
> > > > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM
> Jarek
> > > > > Potiuk
> > > > > > <
> > > > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>> So GitLab already works on
> > > automatically
> > > > > > > running
> > > > > > > > > > builds
> > > > > > > > > > > > > from
> > > > > > > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>> Kamil got involved and will be out
> > > > advocate
> > > > > > on
> > > > > > > > it:
> > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > > > > > > >>>>>>>>> Phone: +48660796129
> > > > <+48%20660%20796%20129>
> > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik
> > > Jarek
> > > > > > > Potiuk <
> > > > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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
> > > > > <+48%20660%20796%20129>
> > > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> > > > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/
> >
> > |
> > > > > > > Principal
> > > > > > > > > > > Software
> > > > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129
> > > > <+48%20660%20796%20129>
> > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > > >>>>>>>>>> [image: Polidea] <
> > > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/>
> |
> > > > > > Principal
> > > > > > > > > > Software
> > > > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>> M: +48 660 796 129
> > > <+48%20660%20796%20129>
> > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > > >>>>>>>> [image: Polidea] <
> > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> |
> > > > > Principal
> > > > > > > > > > Software
> > > > > > > > > > > > > > Engineer
> > > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > > >>>>>>> M: +48 660 796 129
> > > <+48%20660%20796%20129>
> > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > > >>>>> <+
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <tu...@apache.org>]

Yes, I thought that there was limit (the docs are little bit unclear
regarding this issue).

T.

On Sat, 11 Jan 2020 at 13:32, Jarek Potiuk <Ja...@polidea.com> wrote:

> Oh wow! That's fantastic! Indeed it looks like in the pricing docs. I am
> sure we discussed before that there is a limit :).
>
> J.
>
>
> On Sat, Jan 11, 2020 at 12:41 PM Tomasz Urbaszek <tu...@apache.org>
> wrote:
>
> > I have checked and Github Actions have unlimited minutes for open
> > repositories.
> >
> > T
> >
> > On Sat, 11 Jan 2020 at 12:27, Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > I am working on some last fixes to Kind improvement PR and get it ready
> > to
> > > merge today - I hope :). Also looking forward to moving out of Travis
> > > finally.
> > >
> > > One more thought - we think the best way to approach it is to enable
> > Github
> > > Actions in parallel to Travis and keep it running in parallel to make
> > sure
> > > it is stable.
> > >
> > > Then we can disable Travis but we can keep it available to switch it on
> > > again as needed.
> > >
> > > I think the main semi-open point we have with GA is the availability of
> > > credits for GCP.  The free minutes from Github will not be enough for
> > sure,
> > > Tomek already runs it on the GCP account we got from Google, but we
> need
> > to
> > > secure the credits for the future as well. I will take on that task
> with
> > > Aizhamal but we need to keep it running for some time to understand
> what
> > > the usage might be.
> > >
> > > We can also talk to Github and other providers as well and maybe get
> some
> > > credit donations from other people/companies (maybe we could join
> 'Github
> > > Sponsors" project and start getting some money through that
> > > https://github.com/sponsors)? I think having several sources of
> funding
> > > for
> > > our compute resources might be a good idea. WDYT?
> > >
> > > J
> > >
> > > On Sat, Jan 11, 2020 at 11:41 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > > > Yeah, that would be nice.
> > > >
> > > > On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <tu...@apache.org>
> > > wrote:
> > > >
> > > > > An additional advantage of GA + self-hosted runners is the ability
> to
> > > > > ssh to machine and see what is going on (for example why tests
> > > timeout).
> > > > >
> > > > > T.
> > > > >
> > > > > On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Awesome Tomek, great job. Waiting for your PR eagerly :) and
> can't
> > > wait
> > > > > to
> > > > > > move out of Travis.
> > > > > >
> > > > > > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > > > > > tomasz.urbaszek@polidea.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Hi all,
> > > > > > >
> > > > > > > Just a small update:
> > > > > > > - after Jarek's changes from
> > > > > https://github.com/apache/airflow/pull/6516
> > > > > > > kubernetes
> > > > > > >   builds started to run (proviously there was an issue with
> kind)
> > > > > > > - I am testing self-hosted runners
> > > > > > >
> > > > > > > It seems that possible migration is getting closer ;)
> > > > > > >
> > > > > > > Bests,
> > > > > > > Tomek
> > > > > > >
> > > > > > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <
> > > > philgagnon1@gmail.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > We have been using Actions on the prestosql project for a
> > little
> > > > > while
> > > > > > > as a
> > > > > > > > Travis replacement and we like it a lot.
> > > > > > > >
> > > > > > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> > > > > Jarek.Potiuk@polidea.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > :(
> > > > > > > > >
> > > > > > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I started to play with self-hosted runner and... well,
> > > > > encountered
> > > > > > > > known
> > > > > > > > > > error:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > > > > > >
> > > > > > > > > > It seems that GA is still maturing.
> > > > > > > > > >
> > > > > > > > > > Bests,
> > > > > > > > > > Tomek
> > > > > > > > > >
> > > > > > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > > > > > >
> > > > > > > > > > > J.
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> > > > > kaxilnaik@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > > > > > daniel.imberman@gmail.com
> > > > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > I’d rather we do it all at once and not need to
> > > maintain
> > > > > two
> > > > > > > > > builds.
> > > > > > > > > > > > > Most/all of our CI/CD is dockerized at this point
> so
> > > > there
> > > > > > > > > shouldn’t
> > > > > > > > > > > be a
> > > > > > > > > > > > > huge difference.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > > > > > Hi all,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I have to solve a problem with our kubernetes test
> > but
> > > > for
> > > > > > your
> > > > > > > > > > > > information
> > > > > > > > > > > > > I have never experienced a flaky
> > > > > > > > > > > > > or timeouted build on Github Actions. Maybe I am
> > lucky
> > > or
> > > > > > maybe
> > > > > > > > > > there's
> > > > > > > > > > > > > something different.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If we agree to move to Github Actions, would we
> like
> > to
> > > > > > migrate
> > > > > > > > > > > > > incrementally or fully?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Bests,
> > > > > > > > > > > > > Tomek
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > No problem on that side - Tomek is using the same
> > > > scripts
> > > > > > we
> > > > > > > > have
> > > > > > > > > > on
> > > > > > > > > > > > > Travis
> > > > > > > > > > > > > > (and they generally work - I think the last step
> is
> > > to
> > > > > make
> > > > > > > all
> > > > > > > > > the
> > > > > > > > > > > > > > tests pass. We have still a number of
> dependencies
> > > > > between
> > > > > > > > tests
> > > > > > > > > > and
> > > > > > > > > > > > some
> > > > > > > > > > > > > > environmental flakiness so that some tests
> > > consistently
> > > > > > fail
> > > > > > > in
> > > > > > > > > > > Github
> > > > > > > > > > > > > > Actions where they did not fail in Travis. From
> > > latest
> > > > > try
> > > > > > by
> > > > > > > > > Tomek
> > > > > > > > > > > it
> > > > > > > > > > > > > > looks like we are 1 test to go (plus some
> > > cleanup/setup
> > > > > of
> > > > > > > > > project
> > > > > > > > > > > and
> > > > > > > > > > > > > > making sure all is stable):
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16
> > warnings
> > > in
> > > > > > > > 1207.96s
> > > > > > > > > > > > > (0:20:07)
> > > > > > > > > > > > > > =====
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > We discussed with Tomek and Kamil that in order
> to
> > > > speed
> > > > > it
> > > > > > > up
> > > > > > > > we
> > > > > > > > > > > might
> > > > > > > > > > > > > > want to run our own workers on the GCP account we
> > > have
> > > > -
> > > > > > just
> > > > > > > > to
> > > > > > > > > > test
> > > > > > > > > > > > > > quickly how much we can optimise it and I am
> > inclined
> > > > to
> > > > > > > agree.
> > > > > > > > > If
> > > > > > > > > > we
> > > > > > > > > > > > do
> > > > > > > > > > > > > it
> > > > > > > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > If we want to use auto-scalable GKE cluster as we
> > > > > > originally
> > > > > > > > > > planned
> > > > > > > > > > > it
> > > > > > > > > > > > > > might take more time to setup (similar setup to
> > what
> > > I
> > > > > > tried
> > > > > > > > with
> > > > > > > > > > > > > GitLab).
> > > > > > > > > > > > > > There we might need to use docker-in-docker to
> > build
> > > > the
> > > > > CI
> > > > > > > > image
> > > > > > > > > > > with
> > > > > > > > > > > > > > latest as first step of build and then use that
> > built
> > > > > image
> > > > > > > by
> > > > > > > > > all
> > > > > > > > > > > > > > subsequent steps. But we can do it as the next
> > step -
> > > > > > > > optimising
> > > > > > > > > > the
> > > > > > > > > > > > > > experience.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > J.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman
> <
> > > > > > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > @jarek does this affect anything involving
> > breeze?
> > > Do
> > > > > > > GitHub
> > > > > > > > > > > actions
> > > > > > > > > > > > > have
> > > > > > > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > via Newton Mail [
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > > > > > ]
> > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash
> > Berlin-Taylor
> > > <
> > > > > > > > > > ash@apache.org
> > > > > > > > > > > >
> > > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Infra: possibly yes to get secrets in there to
> > run
> > > > > things
> > > > > > > on
> > > > > > > > > our
> > > > > > > > > > > own
> > > > > > > > > > > > > > > "hardware" -
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > > <
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > needs someone with Admin rights to create, and
> I
> > > > don't
> > > > > > see
> > > > > > > > the
> > > > > > > > > > > > Settings
> > > > > > > > > > > > > > tab
> > > > > > > > > > > > > > > at all.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -ash
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > > > > > xd.deng.r@gmail.com
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > +1 for GitHub Actions. I have been using it
> for
> > > > > months
> > > > > > > for
> > > > > > > > my
> > > > > > > > > > > side
> > > > > > > > > > > > > > > > projects, and it’s working very well. I
> believe
> > > > most
> > > > > of
> > > > > > > us
> > > > > > > > > are
> > > > > > > > > > > > quite
> > > > > > > > > > > > > > > tired
> > > > > > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The only point I would like to remind is
> > whether
> > > we
> > > > > > need
> > > > > > > to
> > > > > > > > > > > > > communicate
> > > > > > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > XD
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash
> Berlin-Taylor <
> > > > > > > > > ash@apache.org>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>> Happy with any thing that gives a more
> > seamless
> > > > CI
> > > > > > > > > > experience -
> > > > > > > > > > > > > > faster
> > > > > > > > > > > > > > > is
> > > > > > > > > > > > > > > >>> good too!
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> -a
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal
> > > > Nurmamat
> > > > > > > kyzy <
> > > > > > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek
> Potiuk
> > <
> > > > > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>>> I am all for it! GitLab has been
> less-than
> > > > > helpful
> > > > > > so
> > > > > > > > far
> > > > > > > > > > and
> > > > > > > > > > > > > > > >>>> recently it
> > > > > > > > > > > > > > > >>>>> seems that running PRs from forks will
> only
> > > be
> > > > > run
> > > > > > in
> > > > > > > > > > > > Enterrprise
> > > > > > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > > > > > >>>>> which is less than welcome. I am quite a
> > bit
> > > > > > > > disappointed
> > > > > > > > > > > with
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > >>>> pace and
> > > > > > > > > > > > > > > >>>>> attitude. Github Actions seems to be much
> > > > better
> > > > > > > > choice -
> > > > > > > > > > > > > > especially
> > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > >>>>> they are closely integrated with Github
> > repo
> > > > and
> > > > > > seem
> > > > > > > > to
> > > > > > > > > > get
> > > > > > > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>> And they added self-hosted runners as
> well,
> > > > which
> > > > > > > makes
> > > > > > > > > it
> > > > > > > > > > > > > possible
> > > > > > > > > > > > > > > >>>> for us
> > > > > > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz
> > > > Urbaszek <
> > > > > > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>> It sometime since we last discussed
> using
> > > > other
> > > > > CI
> > > > > > > > than
> > > > > > > > > > > > Travis.
> > > > > > > > > > > > > > One
> > > > > > > > > > > > > > > >>>> of
> > > > > > > > > > > > > > > >>>>> the
> > > > > > > > > > > > > > > >>>>>> main reasons behind considering Gitlab
> CI
> > > was
> > > > > its
> > > > > > > > > ability
> > > > > > > > > > to
> > > > > > > > > > > > > work
> > > > > > > > > > > > > > > >>>> on
> > > > > > > > > > > > > > > >>>>>> self-hosted runner. However, over time
> of
> > > few
> > > > > long
> > > > > > > > weeks
> > > > > > > > > > > > Github
> > > > > > > > > > > > > > > >>>> Actions
> > > > > > > > > > > > > > > >>>>>> matured enough to allow using
> self-hosted
> > > > > runners!
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>> Github Actions are still growing but
> using
> > > > them
> > > > > > have
> > > > > > > > few
> > > > > > > > > > big
> > > > > > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > > > > > >>>>>> - forking repo and enabling actions will
> > run
> > > > CI
> > > > > on
> > > > > > > > your
> > > > > > > > > > fork
> > > > > > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > > > > > >>>>>> - variety of actions (PR checks,
> > greetings,
> > > > etc)
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>> I put together a PoC of CI in our
> internal
> > > > repo:
> > > > > > > > > > > > > > > >>>>>>
> > > > > > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > > > > > >>>>>> My impression is quite good. I like
> > > > information
> > > > > > > about
> > > > > > > > > > steps
> > > > > > > > > > > > > > > >>>> successes at
> > > > > > > > > > > > > > > >>>>>> the PR level (no need to go to CI to
> check
> > > > which
> > > > > > > step
> > > > > > > > > > > failed).
> > > > > > > > > > > > > The
> > > > > > > > > > > > > > > >>>> build
> > > > > > > > > > > > > > > >>>>>> log view is a little bit clumsy but it
> > > works.
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>> Does any of you have any experience with
> > > > Github
> > > > > > > > Actions?
> > > > > > > > > > Any
> > > > > > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > > >>>>>>> FYI: Interesting article about the
> > history
> > > > > behind
> > > > > > > > > > GitLabCI
> > > > > > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek
> > Potiuk
> > > > > > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> Some update on my GitLab experiences
> so
> > > far:
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that
> we
> > > can
> > > > > > > fairly
> > > > > > > > > > easily
> > > > > > > > > > > > > > > >>>> replicate
> > > > > > > > > > > > > > > >>>>>> the
> > > > > > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i
> can
> > > > say -
> > > > > > it
> > > > > > > > > > > generally
> > > > > > > > > > > > > > > >>>> works, I
> > > > > > > > > > > > > > > >>>>>> can
> > > > > > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test
> builds
> > in
> > > > the
> > > > > > > main
> > > > > > > > > > > Airflow
> > > > > > > > > > > > > > > >>>> project
> > > > > > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > > > > > >>>>>>>> few weeks to see how it is doing
> (while
> > I
> > > am
> > > > > no
> > > > > > > > > > holidays)
> > > > > > > > > > > > and
> > > > > > > > > > > > > > > >>>> once we
> > > > > > > > > > > > > > > >>>>>> see
> > > > > > > > > > > > > > > >>>>>>>> it running and get the support for PRs
> > > from
> > > > > > GitLab
> > > > > > > > we
> > > > > > > > > > can
> > > > > > > > > > > > > > > >>>> switch to
> > > > > > > > > > > > > > > >>>>> it.
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> What do you think ? Should i call a
> vote
> > > or
> > > > > just
> > > > > > > try
> > > > > > > > > to
> > > > > > > > > > > set
> > > > > > > > > > > > it
> > > > > > > > > > > > > > > >>>> up ?
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> - I manged to get full working builds
> in
> > > > > > GitLabCI
> > > > > > > +
> > > > > > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > > > > > >>>>>>>> without the kubernetes-specific tests
> > yet,
> > > > but
> > > > > > > this
> > > > > > > > > > should
> > > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > > > > > >>>>>>>> - Working example here - you can take
> a
> > > look
> > > > > and
> > > > > > > > > compare
> > > > > > > > > > > the
> > > > > > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > > > > > >>>>>> it
> > > > > > > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis
> etc:
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > >
> > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than
> Travis
> > > so
> > > > > far
> > > > > > > > (still
> > > > > > > > > > > > > > > >>>> around 35
> > > > > > > > > > > > > > > >>>>>>>> minutes in total), but I plan to
> > optimise
> > > it
> > > > > > > > further.
> > > > > > > > > I
> > > > > > > > > > > can
> > > > > > > > > > > > > > > >>>> play
> > > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > > >>>>>>>> memory/cpu settings of individual
> > workers
> > > > (Got
> > > > > > > some
> > > > > > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > > > > > storage/logs/etc
> > > > > > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota
> (up
> > > for
> > > > > > > initial
> > > > > > > > > > 24) -
> > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > >>>>>> should
> > > > > > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> > > > > independently
> > > > > > > from
> > > > > > > > > > each
> > > > > > > > > > > > > > > >>>> other.
> > > > > > > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes
> > > working
> > > > > (we
> > > > > > > > have
> > > > > > > > > > > built
> > > > > > > > > > > > > > > >>>> in
> > > > > > > > > > > > > > > >>>>> retry
> > > > > > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of
> > > > system
> > > > > > > > failures
> > > > > > > > > > > like
> > > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > > >>>>>>>> - Current spending with > 120 builds
> is
> > 40
> > > > > USD.
> > > > > > We
> > > > > > > > > > should
> > > > > > > > > > > be
> > > > > > > > > > > > > > > >>>> way
> > > > > > > > > > > > > > > >>>>>> below
> > > > > > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > > > > > back-of-the-envelope
> > > > > > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > > > > > >>>>>>>> - The current setup does not use GCR
> as
> > > > cache
> > > > > > and
> > > > > > > > > Kaniko
> > > > > > > > > > > as
> > > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > > >>>>>>>> originally planned. GCR would require
> > > custom
> > > > > > > > > > > authentication
> > > > > > > > > > > > > > > >>>> (and
> > > > > > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does
> > not
> > > > yet
> > > > > > > well
> > > > > > > > > > handle
> > > > > > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > >
> https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > > > > > ).
> > > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > > > > > >>>>>> to
> > > > > > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of
> > > DockerHub
> > > > -
> > > > > so
> > > > > > > > that
> > > > > > > > > we
> > > > > > > > > > > can
> > > > > > > > > > > > > > > >>>> have
> > > > > > > > > > > > > > > >>>>>>>> reliable downloads not depending on
> > > > > DockerHub's
> > > > > > > > > > stability
> > > > > > > > > > > > > > > >>>> (it has
> > > > > > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It
> > > could
> > > > > be
> > > > > > > run
> > > > > > > > in
> > > > > > > > > > any
> > > > > > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > > > > > >>>>>>>> cluster (some optimisations like local
> > > > volumes
> > > > > > > > > mounting
> > > > > > > > > > > for
> > > > > > > > > > > > > > > >>>> docker
> > > > > > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > > > > > >>>>>>>> might have GCP-specific assumptions,
> but
> > > > > should
> > > > > > be
> > > > > > > > > > > generally
> > > > > > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > > > > > >>>>>>>> - You can take a look at the current
> > > source
> > > > > code
> > > > > > > in
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > > > > > >>>>>>>> - There will be some updates (I will
> get
> > > rid
> > > > > of
> > > > > > > > custom
> > > > > > > > > > > > > > > >>>> builder
> > > > > > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > > > > > >>>>>>>> simplify it a bit and implement
> > kubernetes
> > > > > > tests)
> > > > > > > -
> > > > > > > > > it's
> > > > > > > > > > > > > > > >>>> mostly
> > > > > > > > > > > > > > > >>>>> some
> > > > > > > > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific
> > > > > variables
> > > > > > +
> > > > > > > > > > > gitlab.ci
> > > > > > > > > > > > > > > >>>> yaml
> > > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek
> > > > Potiuk
> > > > > <
> > > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>> So GitLab already works on
> > automatically
> > > > > > running
> > > > > > > > > builds
> > > > > > > > > > > > from
> > > > > > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>> Kamil got involved and will be out
> > > advocate
> > > > > on
> > > > > > > it:
> > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > > > > > >>>>>>>>> Phone: +48660796129
> > > <+48%20660%20796%20129>
> > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik
> > Jarek
> > > > > > Potiuk <
> > > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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
> > > > <+48%20660%20796%20129>
> > > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> > > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/>
> |
> > > > > > Principal
> > > > > > > > > > Software
> > > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129
> > > <+48%20660%20796%20129>
> > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > >>>>>>>>>> [image: Polidea] <
> > > > https://www.polidea.com/>
> > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> |
> > > > > Principal
> > > > > > > > > Software
> > > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>> M: +48 660 796 129
> > <+48%20660%20796%20129>
> > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > > >>>>>>>> [image: Polidea] <
> > > https://www.polidea.com/>
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> |
> > > > Principal
> > > > > > > > > Software
> > > > > > > > > > > > > Engineer
> > > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > > >>>>>>> M: +48 660 796 129
> > <+48%20660%20796%20129>
> > > > > > > > > <+48660796129
> > > > > > > > > > > > > > > >>>>> <+

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

Oh wow! That's fantastic! Indeed it looks like in the pricing docs. I am
sure we discussed before that there is a limit :).

J.


On Sat, Jan 11, 2020 at 12:41 PM Tomasz Urbaszek <tu...@apache.org>
wrote:

> I have checked and Github Actions have unlimited minutes for open
> repositories.
>
> T
>
> On Sat, 11 Jan 2020 at 12:27, Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > I am working on some last fixes to Kind improvement PR and get it ready
> to
> > merge today - I hope :). Also looking forward to moving out of Travis
> > finally.
> >
> > One more thought - we think the best way to approach it is to enable
> Github
> > Actions in parallel to Travis and keep it running in parallel to make
> sure
> > it is stable.
> >
> > Then we can disable Travis but we can keep it available to switch it on
> > again as needed.
> >
> > I think the main semi-open point we have with GA is the availability of
> > credits for GCP.  The free minutes from Github will not be enough for
> sure,
> > Tomek already runs it on the GCP account we got from Google, but we need
> to
> > secure the credits for the future as well. I will take on that task with
> > Aizhamal but we need to keep it running for some time to understand what
> > the usage might be.
> >
> > We can also talk to Github and other providers as well and maybe get some
> > credit donations from other people/companies (maybe we could join 'Github
> > Sponsors" project and start getting some money through that
> > https://github.com/sponsors)? I think having several sources of funding
> > for
> > our compute resources might be a good idea. WDYT?
> >
> > J
> >
> > On Sat, Jan 11, 2020 at 11:41 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > Yeah, that would be nice.
> > >
> > > On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <tu...@apache.org>
> > wrote:
> > >
> > > > An additional advantage of GA + self-hosted runners is the ability to
> > > > ssh to machine and see what is going on (for example why tests
> > timeout).
> > > >
> > > > T.
> > > >
> > > > On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > >
> > > > > Awesome Tomek, great job. Waiting for your PR eagerly :) and can't
> > wait
> > > > to
> > > > > move out of Travis.
> > > > >
> > > > > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > > > > tomasz.urbaszek@polidea.com>
> > > > > wrote:
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Just a small update:
> > > > > > - after Jarek's changes from
> > > > https://github.com/apache/airflow/pull/6516
> > > > > > kubernetes
> > > > > >   builds started to run (proviously there was an issue with kind)
> > > > > > - I am testing self-hosted runners
> > > > > >
> > > > > > It seems that possible migration is getting closer ;)
> > > > > >
> > > > > > Bests,
> > > > > > Tomek
> > > > > >
> > > > > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <
> > > philgagnon1@gmail.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > We have been using Actions on the prestosql project for a
> little
> > > > while
> > > > > > as a
> > > > > > > Travis replacement and we like it a lot.
> > > > > > >
> > > > > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> > > > Jarek.Potiuk@polidea.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > :(
> > > > > > > >
> > > > > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I started to play with self-hosted runner and... well,
> > > > encountered
> > > > > > > known
> > > > > > > > > error:
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > > > > >
> > > > > > > > > It seems that GA is still maturing.
> > > > > > > > >
> > > > > > > > > Bests,
> > > > > > > > > Tomek
> > > > > > > > >
> > > > > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > > > > Jarek.Potiuk@polidea.com
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > > > > >
> > > > > > > > > > J.
> > > > > > > > > >
> > > > > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> > > > kaxilnaik@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > > > > daniel.imberman@gmail.com
> > > > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > I’d rather we do it all at once and not need to
> > maintain
> > > > two
> > > > > > > > builds.
> > > > > > > > > > > > Most/all of our CI/CD is dockerized at this point so
> > > there
> > > > > > > > shouldn’t
> > > > > > > > > > be a
> > > > > > > > > > > > huge difference.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > > > > Hi all,
> > > > > > > > > > > >
> > > > > > > > > > > > I have to solve a problem with our kubernetes test
> but
> > > for
> > > > > your
> > > > > > > > > > > information
> > > > > > > > > > > > I have never experienced a flaky
> > > > > > > > > > > > or timeouted build on Github Actions. Maybe I am
> lucky
> > or
> > > > > maybe
> > > > > > > > > there's
> > > > > > > > > > > > something different.
> > > > > > > > > > > >
> > > > > > > > > > > > If we agree to move to Github Actions, would we like
> to
> > > > > migrate
> > > > > > > > > > > > incrementally or fully?
> > > > > > > > > > > >
> > > > > > > > > > > > Bests,
> > > > > > > > > > > > Tomek
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > No problem on that side - Tomek is using the same
> > > scripts
> > > > > we
> > > > > > > have
> > > > > > > > > on
> > > > > > > > > > > > Travis
> > > > > > > > > > > > > (and they generally work - I think the last step is
> > to
> > > > make
> > > > > > all
> > > > > > > > the
> > > > > > > > > > > > > tests pass. We have still a number of dependencies
> > > > between
> > > > > > > tests
> > > > > > > > > and
> > > > > > > > > > > some
> > > > > > > > > > > > > environmental flakiness so that some tests
> > consistently
> > > > > fail
> > > > > > in
> > > > > > > > > > Github
> > > > > > > > > > > > > Actions where they did not fail in Travis. From
> > latest
> > > > try
> > > > > by
> > > > > > > > Tomek
> > > > > > > > > > it
> > > > > > > > > > > > > looks like we are 1 test to go (plus some
> > cleanup/setup
> > > > of
> > > > > > > > project
> > > > > > > > > > and
> > > > > > > > > > > > > making sure all is stable):
> > > > > > > > > > > > >
> > > > > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16
> warnings
> > in
> > > > > > > 1207.96s
> > > > > > > > > > > > (0:20:07)
> > > > > > > > > > > > > =====
> > > > > > > > > > > > >
> > > > > > > > > > > > > We discussed with Tomek and Kamil that in order to
> > > speed
> > > > it
> > > > > > up
> > > > > > > we
> > > > > > > > > > might
> > > > > > > > > > > > > want to run our own workers on the GCP account we
> > have
> > > -
> > > > > just
> > > > > > > to
> > > > > > > > > test
> > > > > > > > > > > > > quickly how much we can optimise it and I am
> inclined
> > > to
> > > > > > agree.
> > > > > > > > If
> > > > > > > > > we
> > > > > > > > > > > do
> > > > > > > > > > > > it
> > > > > > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > > > > > >
> > > > > > > > > > > > > If we want to use auto-scalable GKE cluster as we
> > > > > originally
> > > > > > > > > planned
> > > > > > > > > > it
> > > > > > > > > > > > > might take more time to setup (similar setup to
> what
> > I
> > > > > tried
> > > > > > > with
> > > > > > > > > > > > GitLab).
> > > > > > > > > > > > > There we might need to use docker-in-docker to
> build
> > > the
> > > > CI
> > > > > > > image
> > > > > > > > > > with
> > > > > > > > > > > > > latest as first step of build and then use that
> built
> > > > image
> > > > > > by
> > > > > > > > all
> > > > > > > > > > > > > subsequent steps. But we can do it as the next
> step -
> > > > > > > optimising
> > > > > > > > > the
> > > > > > > > > > > > > experience.
> > > > > > > > > > > > >
> > > > > > > > > > > > > J.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > @jarek does this affect anything involving
> breeze?
> > Do
> > > > > > GitHub
> > > > > > > > > > actions
> > > > > > > > > > > > have
> > > > > > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > via Newton Mail [
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > > > > ]
> > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash
> Berlin-Taylor
> > <
> > > > > > > > > ash@apache.org
> > > > > > > > > > >
> > > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Infra: possibly yes to get secrets in there to
> run
> > > > things
> > > > > > on
> > > > > > > > our
> > > > > > > > > > own
> > > > > > > > > > > > > > "hardware" -
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > > <
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > needs someone with Admin rights to create, and I
> > > don't
> > > > > see
> > > > > > > the
> > > > > > > > > > > Settings
> > > > > > > > > > > > > tab
> > > > > > > > > > > > > > at all.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -ash
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > > > > xd.deng.r@gmail.com
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > +1 for GitHub Actions. I have been using it for
> > > > months
> > > > > > for
> > > > > > > my
> > > > > > > > > > side
> > > > > > > > > > > > > > > projects, and it’s working very well. I believe
> > > most
> > > > of
> > > > > > us
> > > > > > > > are
> > > > > > > > > > > quite
> > > > > > > > > > > > > > tired
> > > > > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The only point I would like to remind is
> whether
> > we
> > > > > need
> > > > > > to
> > > > > > > > > > > > communicate
> > > > > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > XD
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > > > > > > ash@apache.org>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>> Happy with any thing that gives a more
> seamless
> > > CI
> > > > > > > > > experience -
> > > > > > > > > > > > > faster
> > > > > > > > > > > > > > is
> > > > > > > > > > > > > > >>> good too!
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> -a
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal
> > > Nurmamat
> > > > > > kyzy <
> > > > > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk
> <
> > > > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>>> I am all for it! GitLab has been less-than
> > > > helpful
> > > > > so
> > > > > > > far
> > > > > > > > > and
> > > > > > > > > > > > > > >>>> recently it
> > > > > > > > > > > > > > >>>>> seems that running PRs from forks will only
> > be
> > > > run
> > > > > in
> > > > > > > > > > > Enterrprise
> > > > > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > > > > >>>>> which is less than welcome. I am quite a
> bit
> > > > > > > disappointed
> > > > > > > > > > with
> > > > > > > > > > > > the
> > > > > > > > > > > > > > >>>> pace and
> > > > > > > > > > > > > > >>>>> attitude. Github Actions seems to be much
> > > better
> > > > > > > choice -
> > > > > > > > > > > > > especially
> > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > >>>>> they are closely integrated with Github
> repo
> > > and
> > > > > seem
> > > > > > > to
> > > > > > > > > get
> > > > > > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> And they added self-hosted runners as well,
> > > which
> > > > > > makes
> > > > > > > > it
> > > > > > > > > > > > possible
> > > > > > > > > > > > > > >>>> for us
> > > > > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz
> > > Urbaszek <
> > > > > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> It sometime since we last discussed using
> > > other
> > > > CI
> > > > > > > than
> > > > > > > > > > > Travis.
> > > > > > > > > > > > > One
> > > > > > > > > > > > > > >>>> of
> > > > > > > > > > > > > > >>>>> the
> > > > > > > > > > > > > > >>>>>> main reasons behind considering Gitlab CI
> > was
> > > > its
> > > > > > > > ability
> > > > > > > > > to
> > > > > > > > > > > > work
> > > > > > > > > > > > > > >>>> on
> > > > > > > > > > > > > > >>>>>> self-hosted runner. However, over time of
> > few
> > > > long
> > > > > > > weeks
> > > > > > > > > > > Github
> > > > > > > > > > > > > > >>>> Actions
> > > > > > > > > > > > > > >>>>>> matured enough to allow using self-hosted
> > > > runners!
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> Github Actions are still growing but using
> > > them
> > > > > have
> > > > > > > few
> > > > > > > > > big
> > > > > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > > > > >>>>>> - forking repo and enabling actions will
> run
> > > CI
> > > > on
> > > > > > > your
> > > > > > > > > fork
> > > > > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > > > > >>>>>> - variety of actions (PR checks,
> greetings,
> > > etc)
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> I put together a PoC of CI in our internal
> > > repo:
> > > > > > > > > > > > > > >>>>>>
> > > > > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > > > > >>>>>> My impression is quite good. I like
> > > information
> > > > > > about
> > > > > > > > > steps
> > > > > > > > > > > > > > >>>> successes at
> > > > > > > > > > > > > > >>>>>> the PR level (no need to go to CI to check
> > > which
> > > > > > step
> > > > > > > > > > failed).
> > > > > > > > > > > > The
> > > > > > > > > > > > > > >>>> build
> > > > > > > > > > > > > > >>>>>> log view is a little bit clumsy but it
> > works.
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> Does any of you have any experience with
> > > Github
> > > > > > > Actions?
> > > > > > > > > Any
> > > > > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > > >>>>>>> FYI: Interesting article about the
> history
> > > > behind
> > > > > > > > > GitLabCI
> > > > > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek
> Potiuk
> > > > > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>>> Some update on my GitLab experiences so
> > far:
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we
> > can
> > > > > > fairly
> > > > > > > > > easily
> > > > > > > > > > > > > > >>>> replicate
> > > > > > > > > > > > > > >>>>>> the
> > > > > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can
> > > say -
> > > > > it
> > > > > > > > > > generally
> > > > > > > > > > > > > > >>>> works, I
> > > > > > > > > > > > > > >>>>>> can
> > > > > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds
> in
> > > the
> > > > > > main
> > > > > > > > > > Airflow
> > > > > > > > > > > > > > >>>> project
> > > > > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > > > > >>>>>>>> few weeks to see how it is doing (while
> I
> > am
> > > > no
> > > > > > > > > holidays)
> > > > > > > > > > > and
> > > > > > > > > > > > > > >>>> once we
> > > > > > > > > > > > > > >>>>>> see
> > > > > > > > > > > > > > >>>>>>>> it running and get the support for PRs
> > from
> > > > > GitLab
> > > > > > > we
> > > > > > > > > can
> > > > > > > > > > > > > > >>>> switch to
> > > > > > > > > > > > > > >>>>> it.
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> What do you think ? Should i call a vote
> > or
> > > > just
> > > > > > try
> > > > > > > > to
> > > > > > > > > > set
> > > > > > > > > > > it
> > > > > > > > > > > > > > >>>> up ?
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> - I manged to get full working builds in
> > > > > GitLabCI
> > > > > > +
> > > > > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > > > > >>>>>>>> without the kubernetes-specific tests
> yet,
> > > but
> > > > > > this
> > > > > > > > > should
> > > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > > > > >>>>>>>> - Working example here - you can take a
> > look
> > > > and
> > > > > > > > compare
> > > > > > > > > > the
> > > > > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > > > > >>>>>> it
> > > > > > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > >
> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis
> > so
> > > > far
> > > > > > > (still
> > > > > > > > > > > > > > >>>> around 35
> > > > > > > > > > > > > > >>>>>>>> minutes in total), but I plan to
> optimise
> > it
> > > > > > > further.
> > > > > > > > I
> > > > > > > > > > can
> > > > > > > > > > > > > > >>>> play
> > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > >>>>>>>> memory/cpu settings of individual
> workers
> > > (Got
> > > > > > some
> > > > > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > > > > storage/logs/etc
> > > > > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up
> > for
> > > > > > initial
> > > > > > > > > 24) -
> > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > >>>>>> should
> > > > > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> > > > independently
> > > > > > from
> > > > > > > > > each
> > > > > > > > > > > > > > >>>> other.
> > > > > > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes
> > working
> > > > (we
> > > > > > > have
> > > > > > > > > > built
> > > > > > > > > > > > > > >>>> in
> > > > > > > > > > > > > > >>>>> retry
> > > > > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of
> > > system
> > > > > > > failures
> > > > > > > > > > like
> > > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > > >>>>>>>> - Current spending with > 120 builds is
> 40
> > > > USD.
> > > > > We
> > > > > > > > > should
> > > > > > > > > > be
> > > > > > > > > > > > > > >>>> way
> > > > > > > > > > > > > > >>>>>> below
> > > > > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > > > > back-of-the-envelope
> > > > > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > > > > >>>>>>>> - The current setup does not use GCR as
> > > cache
> > > > > and
> > > > > > > > Kaniko
> > > > > > > > > > as
> > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > >>>>>>>> originally planned. GCR would require
> > custom
> > > > > > > > > > authentication
> > > > > > > > > > > > > > >>>> (and
> > > > > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does
> not
> > > yet
> > > > > > well
> > > > > > > > > handle
> > > > > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > > > > ).
> > > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > > > > >>>>>> to
> > > > > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of
> > DockerHub
> > > -
> > > > so
> > > > > > > that
> > > > > > > > we
> > > > > > > > > > can
> > > > > > > > > > > > > > >>>> have
> > > > > > > > > > > > > > >>>>>>>> reliable downloads not depending on
> > > > DockerHub's
> > > > > > > > > stability
> > > > > > > > > > > > > > >>>> (it has
> > > > > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It
> > could
> > > > be
> > > > > > run
> > > > > > > in
> > > > > > > > > any
> > > > > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > > > > >>>>>>>> cluster (some optimisations like local
> > > volumes
> > > > > > > > mounting
> > > > > > > > > > for
> > > > > > > > > > > > > > >>>> docker
> > > > > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but
> > > > should
> > > > > be
> > > > > > > > > > generally
> > > > > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > > > > >>>>>>>> - You can take a look at the current
> > source
> > > > code
> > > > > > in
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > > > > >>>>>>>> - There will be some updates (I will get
> > rid
> > > > of
> > > > > > > custom
> > > > > > > > > > > > > > >>>> builder
> > > > > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > > > > >>>>>>>> simplify it a bit and implement
> kubernetes
> > > > > tests)
> > > > > > -
> > > > > > > > it's
> > > > > > > > > > > > > > >>>> mostly
> > > > > > > > > > > > > > >>>>> some
> > > > > > > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific
> > > > variables
> > > > > +
> > > > > > > > > > gitlab.ci
> > > > > > > > > > > > > > >>>> yaml
> > > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek
> > > Potiuk
> > > > <
> > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>> So GitLab already works on
> automatically
> > > > > running
> > > > > > > > builds
> > > > > > > > > > > from
> > > > > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>> Kamil got involved and will be out
> > advocate
> > > > on
> > > > > > it:
> > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > > > > >>>>>>>>> Phone: +48660796129
> > <+48%20660%20796%20129>
> > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik
> Jarek
> > > > > Potiuk <
> > > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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
> > > <+48%20660%20796%20129>
> > > > > > > > > > <+48660796129
> > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> > > > https://www.polidea.com/>
> > > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> |
> > > > > Principal
> > > > > > > > > Software
> > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129
> > <+48%20660%20796%20129>
> > > > > > > > > <+48660796129
> > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > >>>>>>>>>> [image: Polidea] <
> > > https://www.polidea.com/>
> > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> |
> > > > Principal
> > > > > > > > Software
> > > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>> M: +48 660 796 129
> <+48%20660%20796%20129>
> > > > > > > > <+48660796129
> > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > >>>>>>>> [image: Polidea] <
> > https://www.polidea.com/>
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> |
> > > Principal
> > > > > > > > Software
> > > > > > > > > > > > Engineer
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>> M: +48 660 796 129
> <+48%20660%20796%20129>
> > > > > > > > <+48660796129
> > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > >>>>>>> [image: Polidea] <
> https://www.polidea.com/
> > >
> > > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> --
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > > > > > > >>>>> Polidea <https://www.polidea.com/> |
> > Principal
> > > > > > > Software
> > > > > > > > > > > Engineer
> > > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > > <+48660796129
> > > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > > >>>>> [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/>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > >
> > > > > > > > > > > > Tomasz Urbaszek
> > > > > > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> > > > > Engineer
> > > > > > > > > > > >
> > > > > > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > > > > > E: tomasz.urbaszek@polidea.com <
> > > > tomasz.urbaszeki@polidea.com
> > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Unique Tech
> > > > > > > > > > > > Check out our projects! <
> > > https://www.polidea.com/our-work>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > Jarek Potiuk
> > > > > > > > > > Polidea <https://www.polidea.com/> | Principal Software
> > > > Engineer
> > > > > > > > > >
> > > > > > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > Tomasz Urbaszek
> > > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> > Engineer
> > > > > > > > >
> > > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > > E: tomasz.urbaszek@polidea.com <
> tomasz.urbaszeki@polidea.com
> > >
> > > > > > > > >
> > > > > > > > > Unique Tech
> > > > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Jarek Potiuk
> > > > > > > > Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > > > > >
> > > > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tomasz Urbaszek
> > > > > > Polidea <https://www.polidea.com/> | Software Engineer
> > > > > >
> > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > >
> > > > > > Unique Tech
> > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > >
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > 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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <tu...@apache.org>]

I have checked and Github Actions have unlimited minutes for open
repositories.

T

On Sat, 11 Jan 2020 at 12:27, Jarek Potiuk <Ja...@polidea.com> wrote:

> I am working on some last fixes to Kind improvement PR and get it ready to
> merge today - I hope :). Also looking forward to moving out of Travis
> finally.
>
> One more thought - we think the best way to approach it is to enable Github
> Actions in parallel to Travis and keep it running in parallel to make sure
> it is stable.
>
> Then we can disable Travis but we can keep it available to switch it on
> again as needed.
>
> I think the main semi-open point we have with GA is the availability of
> credits for GCP.  The free minutes from Github will not be enough for sure,
> Tomek already runs it on the GCP account we got from Google, but we need to
> secure the credits for the future as well. I will take on that task with
> Aizhamal but we need to keep it running for some time to understand what
> the usage might be.
>
> We can also talk to Github and other providers as well and maybe get some
> credit donations from other people/companies (maybe we could join 'Github
> Sponsors" project and start getting some money through that
> https://github.com/sponsors)? I think having several sources of funding
> for
> our compute resources might be a good idea. WDYT?
>
> J
>
> On Sat, Jan 11, 2020 at 11:41 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > Yeah, that would be nice.
> >
> > On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <tu...@apache.org>
> wrote:
> >
> > > An additional advantage of GA + self-hosted runners is the ability to
> > > ssh to machine and see what is going on (for example why tests
> timeout).
> > >
> > > T.
> > >
> > > On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > > > Awesome Tomek, great job. Waiting for your PR eagerly :) and can't
> wait
> > > to
> > > > move out of Travis.
> > > >
> > > > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com>
> > > > wrote:
> > > >
> > > > > Hi all,
> > > > >
> > > > > Just a small update:
> > > > > - after Jarek's changes from
> > > https://github.com/apache/airflow/pull/6516
> > > > > kubernetes
> > > > >   builds started to run (proviously there was an issue with kind)
> > > > > - I am testing self-hosted runners
> > > > >
> > > > > It seems that possible migration is getting closer ;)
> > > > >
> > > > > Bests,
> > > > > Tomek
> > > > >
> > > > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <
> > philgagnon1@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > We have been using Actions on the prestosql project for a little
> > > while
> > > > > as a
> > > > > > Travis replacement and we like it a lot.
> > > > > >
> > > > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> > > Jarek.Potiuk@polidea.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > :(
> > > > > > >
> > > > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > > > tomasz.urbaszek@polidea.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I started to play with self-hosted runner and... well,
> > > encountered
> > > > > > known
> > > > > > > > error:
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > > > >
> > > > > > > > It seems that GA is still maturing.
> > > > > > > >
> > > > > > > > Bests,
> > > > > > > > Tomek
> > > > > > > >
> > > > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > > > Jarek.Potiuk@polidea.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > > > >
> > > > > > > > > J.
> > > > > > > > >
> > > > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> > > kaxilnaik@gmail.com>
> > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > > > >
> > > > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > > > daniel.imberman@gmail.com
> > > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > I’d rather we do it all at once and not need to
> maintain
> > > two
> > > > > > > builds.
> > > > > > > > > > > Most/all of our CI/CD is dockerized at this point so
> > there
> > > > > > > shouldn’t
> > > > > > > > > be a
> > > > > > > > > > > huge difference.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > > > Hi all,
> > > > > > > > > > >
> > > > > > > > > > > I have to solve a problem with our kubernetes test but
> > for
> > > > your
> > > > > > > > > > information
> > > > > > > > > > > I have never experienced a flaky
> > > > > > > > > > > or timeouted build on Github Actions. Maybe I am lucky
> or
> > > > maybe
> > > > > > > > there's
> > > > > > > > > > > something different.
> > > > > > > > > > >
> > > > > > > > > > > If we agree to move to Github Actions, would we like to
> > > > migrate
> > > > > > > > > > > incrementally or fully?
> > > > > > > > > > >
> > > > > > > > > > > Bests,
> > > > > > > > > > > Tomek
> > > > > > > > > > >
> > > > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > No problem on that side - Tomek is using the same
> > scripts
> > > > we
> > > > > > have
> > > > > > > > on
> > > > > > > > > > > Travis
> > > > > > > > > > > > (and they generally work - I think the last step is
> to
> > > make
> > > > > all
> > > > > > > the
> > > > > > > > > > > > tests pass. We have still a number of dependencies
> > > between
> > > > > > tests
> > > > > > > > and
> > > > > > > > > > some
> > > > > > > > > > > > environmental flakiness so that some tests
> consistently
> > > > fail
> > > > > in
> > > > > > > > > Github
> > > > > > > > > > > > Actions where they did not fail in Travis. From
> latest
> > > try
> > > > by
> > > > > > > Tomek
> > > > > > > > > it
> > > > > > > > > > > > looks like we are 1 test to go (plus some
> cleanup/setup
> > > of
> > > > > > > project
> > > > > > > > > and
> > > > > > > > > > > > making sure all is stable):
> > > > > > > > > > > >
> > > > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings
> in
> > > > > > 1207.96s
> > > > > > > > > > > (0:20:07)
> > > > > > > > > > > > =====
> > > > > > > > > > > >
> > > > > > > > > > > > We discussed with Tomek and Kamil that in order to
> > speed
> > > it
> > > > > up
> > > > > > we
> > > > > > > > > might
> > > > > > > > > > > > want to run our own workers on the GCP account we
> have
> > -
> > > > just
> > > > > > to
> > > > > > > > test
> > > > > > > > > > > > quickly how much we can optimise it and I am inclined
> > to
> > > > > agree.
> > > > > > > If
> > > > > > > > we
> > > > > > > > > > do
> > > > > > > > > > > it
> > > > > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > > > > >
> > > > > > > > > > > > If we want to use auto-scalable GKE cluster as we
> > > > originally
> > > > > > > > planned
> > > > > > > > > it
> > > > > > > > > > > > might take more time to setup (similar setup to what
> I
> > > > tried
> > > > > > with
> > > > > > > > > > > GitLab).
> > > > > > > > > > > > There we might need to use docker-in-docker to build
> > the
> > > CI
> > > > > > image
> > > > > > > > > with
> > > > > > > > > > > > latest as first step of build and then use that built
> > > image
> > > > > by
> > > > > > > all
> > > > > > > > > > > > subsequent steps. But we can do it as the next step -
> > > > > > optimising
> > > > > > > > the
> > > > > > > > > > > > experience.
> > > > > > > > > > > >
> > > > > > > > > > > > J.
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > > > >
> > > > > > > > > > > > > @jarek does this affect anything involving breeze?
> Do
> > > > > GitHub
> > > > > > > > > actions
> > > > > > > > > > > have
> > > > > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > > > > >
> > > > > > > > > > > > > via Newton Mail [
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > > > ]
> > > > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor
> <
> > > > > > > > ash@apache.org
> > > > > > > > > >
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Infra: possibly yes to get secrets in there to run
> > > things
> > > > > on
> > > > > > > our
> > > > > > > > > own
> > > > > > > > > > > > > "hardware" -
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > > <
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > >
> > > > > > > > > > > > > needs someone with Admin rights to create, and I
> > don't
> > > > see
> > > > > > the
> > > > > > > > > > Settings
> > > > > > > > > > > > tab
> > > > > > > > > > > > > at all.
> > > > > > > > > > > > >
> > > > > > > > > > > > > -ash
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > > > xd.deng.r@gmail.com
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > +1 for GitHub Actions. I have been using it for
> > > months
> > > > > for
> > > > > > my
> > > > > > > > > side
> > > > > > > > > > > > > > projects, and it’s working very well. I believe
> > most
> > > of
> > > > > us
> > > > > > > are
> > > > > > > > > > quite
> > > > > > > > > > > > > tired
> > > > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The only point I would like to remind is whether
> we
> > > > need
> > > > > to
> > > > > > > > > > > communicate
> > > > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > XD
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > > > > > ash@apache.org>
> > > > > > > > > > > wrote:
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>> Happy with any thing that gives a more seamless
> > CI
> > > > > > > > experience -
> > > > > > > > > > > > faster
> > > > > > > > > > > > > is
> > > > > > > > > > > > > >>> good too!
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> -a
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal
> > Nurmamat
> > > > > kyzy <
> > > > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>>> I am all for it! GitLab has been less-than
> > > helpful
> > > > so
> > > > > > far
> > > > > > > > and
> > > > > > > > > > > > > >>>> recently it
> > > > > > > > > > > > > >>>>> seems that running PRs from forks will only
> be
> > > run
> > > > in
> > > > > > > > > > Enterrprise
> > > > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > > > >>>>> which is less than welcome. I am quite a bit
> > > > > > disappointed
> > > > > > > > > with
> > > > > > > > > > > the
> > > > > > > > > > > > > >>>> pace and
> > > > > > > > > > > > > >>>>> attitude. Github Actions seems to be much
> > better
> > > > > > choice -
> > > > > > > > > > > > especially
> > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > >>>>> they are closely integrated with Github repo
> > and
> > > > seem
> > > > > > to
> > > > > > > > get
> > > > > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> And they added self-hosted runners as well,
> > which
> > > > > makes
> > > > > > > it
> > > > > > > > > > > possible
> > > > > > > > > > > > > >>>> for us
> > > > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz
> > Urbaszek <
> > > > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> It sometime since we last discussed using
> > other
> > > CI
> > > > > > than
> > > > > > > > > > Travis.
> > > > > > > > > > > > One
> > > > > > > > > > > > > >>>> of
> > > > > > > > > > > > > >>>>> the
> > > > > > > > > > > > > >>>>>> main reasons behind considering Gitlab CI
> was
> > > its
> > > > > > > ability
> > > > > > > > to
> > > > > > > > > > > work
> > > > > > > > > > > > > >>>> on
> > > > > > > > > > > > > >>>>>> self-hosted runner. However, over time of
> few
> > > long
> > > > > > weeks
> > > > > > > > > > Github
> > > > > > > > > > > > > >>>> Actions
> > > > > > > > > > > > > >>>>>> matured enough to allow using self-hosted
> > > runners!
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> Github Actions are still growing but using
> > them
> > > > have
> > > > > > few
> > > > > > > > big
> > > > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > > > >>>>>> - forking repo and enabling actions will run
> > CI
> > > on
> > > > > > your
> > > > > > > > fork
> > > > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > > > >>>>>> - variety of actions (PR checks, greetings,
> > etc)
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> I put together a PoC of CI in our internal
> > repo:
> > > > > > > > > > > > > >>>>>>
> > > > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > > > >>>>>> My impression is quite good. I like
> > information
> > > > > about
> > > > > > > > steps
> > > > > > > > > > > > > >>>> successes at
> > > > > > > > > > > > > >>>>>> the PR level (no need to go to CI to check
> > which
> > > > > step
> > > > > > > > > failed).
> > > > > > > > > > > The
> > > > > > > > > > > > > >>>> build
> > > > > > > > > > > > > >>>>>> log view is a little bit clumsy but it
> works.
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> Does any of you have any experience with
> > Github
> > > > > > Actions?
> > > > > > > > Any
> > > > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > > >>>>>>> FYI: Interesting article about the history
> > > behind
> > > > > > > > GitLabCI
> > > > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>>> Some update on my GitLab experiences so
> far:
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we
> can
> > > > > fairly
> > > > > > > > easily
> > > > > > > > > > > > > >>>> replicate
> > > > > > > > > > > > > >>>>>> the
> > > > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can
> > say -
> > > > it
> > > > > > > > > generally
> > > > > > > > > > > > > >>>> works, I
> > > > > > > > > > > > > >>>>>> can
> > > > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in
> > the
> > > > > main
> > > > > > > > > Airflow
> > > > > > > > > > > > > >>>> project
> > > > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > > > >>>>>>>> few weeks to see how it is doing (while I
> am
> > > no
> > > > > > > > holidays)
> > > > > > > > > > and
> > > > > > > > > > > > > >>>> once we
> > > > > > > > > > > > > >>>>>> see
> > > > > > > > > > > > > >>>>>>>> it running and get the support for PRs
> from
> > > > GitLab
> > > > > > we
> > > > > > > > can
> > > > > > > > > > > > > >>>> switch to
> > > > > > > > > > > > > >>>>> it.
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> What do you think ? Should i call a vote
> or
> > > just
> > > > > try
> > > > > > > to
> > > > > > > > > set
> > > > > > > > > > it
> > > > > > > > > > > > > >>>> up ?
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> - I manged to get full working builds in
> > > > GitLabCI
> > > > > +
> > > > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > > > >>>>>>>> without the kubernetes-specific tests yet,
> > but
> > > > > this
> > > > > > > > should
> > > > > > > > > > > > > >>>> be
> > > > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > > > >>>>>>>> - Working example here - you can take a
> look
> > > and
> > > > > > > compare
> > > > > > > > > the
> > > > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > > > >>>>>> it
> > > > > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis
> so
> > > far
> > > > > > (still
> > > > > > > > > > > > > >>>> around 35
> > > > > > > > > > > > > >>>>>>>> minutes in total), but I plan to optimise
> it
> > > > > > further.
> > > > > > > I
> > > > > > > > > can
> > > > > > > > > > > > > >>>> play
> > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > >>>>>>>> memory/cpu settings of individual workers
> > (Got
> > > > > some
> > > > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > > > storage/logs/etc
> > > > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up
> for
> > > > > initial
> > > > > > > > 24) -
> > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > >>>>>> should
> > > > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> > > independently
> > > > > from
> > > > > > > > each
> > > > > > > > > > > > > >>>> other.
> > > > > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes
> working
> > > (we
> > > > > > have
> > > > > > > > > built
> > > > > > > > > > > > > >>>> in
> > > > > > > > > > > > > >>>>> retry
> > > > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of
> > system
> > > > > > failures
> > > > > > > > > like
> > > > > > > > > > > > > >>>> that
> > > > > > > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40
> > > USD.
> > > > We
> > > > > > > > should
> > > > > > > > > be
> > > > > > > > > > > > > >>>> way
> > > > > > > > > > > > > >>>>>> below
> > > > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > > > back-of-the-envelope
> > > > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > > > >>>>>>>> - The current setup does not use GCR as
> > cache
> > > > and
> > > > > > > Kaniko
> > > > > > > > > as
> > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > >>>>>>>> originally planned. GCR would require
> custom
> > > > > > > > > authentication
> > > > > > > > > > > > > >>>> (and
> > > > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not
> > yet
> > > > > well
> > > > > > > > handle
> > > > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > > > ).
> > > > > > > > > > > > > >>>> I
> > > > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > > > >>>>>> to
> > > > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of
> DockerHub
> > -
> > > so
> > > > > > that
> > > > > > > we
> > > > > > > > > can
> > > > > > > > > > > > > >>>> have
> > > > > > > > > > > > > >>>>>>>> reliable downloads not depending on
> > > DockerHub's
> > > > > > > > stability
> > > > > > > > > > > > > >>>> (it has
> > > > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It
> could
> > > be
> > > > > run
> > > > > > in
> > > > > > > > any
> > > > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > > > >>>>>>>> cluster (some optimisations like local
> > volumes
> > > > > > > mounting
> > > > > > > > > for
> > > > > > > > > > > > > >>>> docker
> > > > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but
> > > should
> > > > be
> > > > > > > > > generally
> > > > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > > > >>>>>>>> - You can take a look at the current
> source
> > > code
> > > > > in
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > > > >>>>>>>> - There will be some updates (I will get
> rid
> > > of
> > > > > > custom
> > > > > > > > > > > > > >>>> builder
> > > > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes
> > > > tests)
> > > > > -
> > > > > > > it's
> > > > > > > > > > > > > >>>> mostly
> > > > > > > > > > > > > >>>>> some
> > > > > > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific
> > > variables
> > > > +
> > > > > > > > > gitlab.ci
> > > > > > > > > > > > > >>>> yaml
> > > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek
> > Potiuk
> > > <
> > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>>> So GitLab already works on automatically
> > > > running
> > > > > > > builds
> > > > > > > > > > from
> > > > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>> Kamil got involved and will be out
> advocate
> > > on
> > > > > it:
> > > > > > > > > > > > > >>>>>>>>>
> > > > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > > > >>>>>>>>> Phone: +48660796129
> <+48%20660%20796%20129>
> > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek
> > > > Potiuk <
> > > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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
> > <+48%20660%20796%20129>
> > > > > > > > > <+48660796129
> > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> > > https://www.polidea.com/>
> > > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> |
> > > > Principal
> > > > > > > > Software
> > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129
> <+48%20660%20796%20129>
> > > > > > > > <+48660796129
> > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > >>>>>>>>>> [image: Polidea] <
> > https://www.polidea.com/>
> > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> |
> > > Principal
> > > > > > > Software
> > > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > > <+48660796129
> > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > >>>>>>>> [image: Polidea] <
> https://www.polidea.com/>
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> |
> > Principal
> > > > > > > Software
> > > > > > > > > > > Engineer
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > > <+48660796129
> > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/
> >
> > > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> --
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > > > > > >>>>> Polidea <https://www.polidea.com/> |
> Principal
> > > > > > Software
> > > > > > > > > > Engineer
> > > > > > > > > > > > > >>>>>
> > > > > > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > <+48660796129
> > > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > > >>>>> [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/>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > >
> > > > > > > > > > > Tomasz Urbaszek
> > > > > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> > > > Engineer
> > > > > > > > > > >
> > > > > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > > > > E: tomasz.urbaszek@polidea.com <
> > > tomasz.urbaszeki@polidea.com
> > > > >
> > > > > > > > > > >
> > > > > > > > > > > Unique Tech
> > > > > > > > > > > Check out our projects! <
> > https://www.polidea.com/our-work>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > Jarek Potiuk
> > > > > > > > > Polidea <https://www.polidea.com/> | Principal Software
> > > Engineer
> > > > > > > > >
> > > > > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Tomasz Urbaszek
> > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> Engineer
> > > > > > > >
> > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > E: tomasz.urbaszek@polidea.com <tomasz.urbaszeki@polidea.com
> >
> > > > > > > >
> > > > > > > > Unique Tech
> > > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Jarek Potiuk
> > > > > > > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > > > > >
> > > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Tomasz Urbaszek
> > > > > Polidea <https://www.polidea.com/> | Software Engineer
> > > > >
> > > > > M: +48 505 628 493 <+48505628493>
> > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > > Unique Tech
> > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > >
> > > >
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

I am working on some last fixes to Kind improvement PR and get it ready to
merge today - I hope :). Also looking forward to moving out of Travis
finally.

One more thought - we think the best way to approach it is to enable Github
Actions in parallel to Travis and keep it running in parallel to make sure
it is stable.

Then we can disable Travis but we can keep it available to switch it on
again as needed.

I think the main semi-open point we have with GA is the availability of
credits for GCP.  The free minutes from Github will not be enough for sure,
Tomek already runs it on the GCP account we got from Google, but we need to
secure the credits for the future as well. I will take on that task with
Aizhamal but we need to keep it running for some time to understand what
the usage might be.

We can also talk to Github and other providers as well and maybe get some
credit donations from other people/companies (maybe we could join 'Github
Sponsors" project and start getting some money through that
https://github.com/sponsors)? I think having several sources of funding for
our compute resources might be a good idea. WDYT?

J

On Sat, Jan 11, 2020 at 11:41 AM Kaxil Naik <ka...@gmail.com> wrote:

> Yeah, that would be nice.
>
> On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <tu...@apache.org> wrote:
>
> > An additional advantage of GA + self-hosted runners is the ability to
> > ssh to machine and see what is going on (for example why tests timeout).
> >
> > T.
> >
> > On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > Awesome Tomek, great job. Waiting for your PR eagerly :) and can't wait
> > to
> > > move out of Travis.
> > >
> > > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com>
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > Just a small update:
> > > > - after Jarek's changes from
> > https://github.com/apache/airflow/pull/6516
> > > > kubernetes
> > > >   builds started to run (proviously there was an issue with kind)
> > > > - I am testing self-hosted runners
> > > >
> > > > It seems that possible migration is getting closer ;)
> > > >
> > > > Bests,
> > > > Tomek
> > > >
> > > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <
> philgagnon1@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > We have been using Actions on the prestosql project for a little
> > while
> > > > as a
> > > > > Travis replacement and we like it a lot.
> > > > >
> > > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> > Jarek.Potiuk@polidea.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > :(
> > > > > >
> > > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > > tomasz.urbaszek@polidea.com>
> > > > > > wrote:
> > > > > >
> > > > > > > I started to play with self-hosted runner and... well,
> > encountered
> > > > > known
> > > > > > > error:
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > > >
> > > > > > > It seems that GA is still maturing.
> > > > > > >
> > > > > > > Bests,
> > > > > > > Tomek
> > > > > > >
> > > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > > Jarek.Potiuk@polidea.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > > >
> > > > > > > > J.
> > > > > > > >
> > > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> > kaxilnaik@gmail.com>
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > > >
> > > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > > daniel.imberman@gmail.com
> > > > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > I’d rather we do it all at once and not need to maintain
> > two
> > > > > > builds.
> > > > > > > > > > Most/all of our CI/CD is dockerized at this point so
> there
> > > > > > shouldn’t
> > > > > > > > be a
> > > > > > > > > > huge difference.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > > Hi all,
> > > > > > > > > >
> > > > > > > > > > I have to solve a problem with our kubernetes test but
> for
> > > your
> > > > > > > > > information
> > > > > > > > > > I have never experienced a flaky
> > > > > > > > > > or timeouted build on Github Actions. Maybe I am lucky or
> > > maybe
> > > > > > > there's
> > > > > > > > > > something different.
> > > > > > > > > >
> > > > > > > > > > If we agree to move to Github Actions, would we like to
> > > migrate
> > > > > > > > > > incrementally or fully?
> > > > > > > > > >
> > > > > > > > > > Bests,
> > > > > > > > > > Tomek
> > > > > > > > > >
> > > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > No problem on that side - Tomek is using the same
> scripts
> > > we
> > > > > have
> > > > > > > on
> > > > > > > > > > Travis
> > > > > > > > > > > (and they generally work - I think the last step is to
> > make
> > > > all
> > > > > > the
> > > > > > > > > > > tests pass. We have still a number of dependencies
> > between
> > > > > tests
> > > > > > > and
> > > > > > > > > some
> > > > > > > > > > > environmental flakiness so that some tests consistently
> > > fail
> > > > in
> > > > > > > > Github
> > > > > > > > > > > Actions where they did not fail in Travis. From latest
> > try
> > > by
> > > > > > Tomek
> > > > > > > > it
> > > > > > > > > > > looks like we are 1 test to go (plus some cleanup/setup
> > of
> > > > > > project
> > > > > > > > and
> > > > > > > > > > > making sure all is stable):
> > > > > > > > > > >
> > > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in
> > > > > 1207.96s
> > > > > > > > > > (0:20:07)
> > > > > > > > > > > =====
> > > > > > > > > > >
> > > > > > > > > > > We discussed with Tomek and Kamil that in order to
> speed
> > it
> > > > up
> > > > > we
> > > > > > > > might
> > > > > > > > > > > want to run our own workers on the GCP account we have
> -
> > > just
> > > > > to
> > > > > > > test
> > > > > > > > > > > quickly how much we can optimise it and I am inclined
> to
> > > > agree.
> > > > > > If
> > > > > > > we
> > > > > > > > > do
> > > > > > > > > > it
> > > > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > > > >
> > > > > > > > > > > If we want to use auto-scalable GKE cluster as we
> > > originally
> > > > > > > planned
> > > > > > > > it
> > > > > > > > > > > might take more time to setup (similar setup to what I
> > > tried
> > > > > with
> > > > > > > > > > GitLab).
> > > > > > > > > > > There we might need to use docker-in-docker to build
> the
> > CI
> > > > > image
> > > > > > > > with
> > > > > > > > > > > latest as first step of build and then use that built
> > image
> > > > by
> > > > > > all
> > > > > > > > > > > subsequent steps. But we can do it as the next step -
> > > > > optimising
> > > > > > > the
> > > > > > > > > > > experience.
> > > > > > > > > > >
> > > > > > > > > > > J.
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > > >
> > > > > > > > > > > > @jarek does this affect anything involving breeze? Do
> > > > GitHub
> > > > > > > > actions
> > > > > > > > > > have
> > > > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > > > >
> > > > > > > > > > > > via Newton Mail [
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > > ]
> > > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > > > > > > ash@apache.org
> > > > > > > > >
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > > >
> > > > > > > > > > > > Infra: possibly yes to get secrets in there to run
> > things
> > > > on
> > > > > > our
> > > > > > > > own
> > > > > > > > > > > > "hardware" -
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > > <
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > >
> > > > > > > > > > > > needs someone with Admin rights to create, and I
> don't
> > > see
> > > > > the
> > > > > > > > > Settings
> > > > > > > > > > > tab
> > > > > > > > > > > > at all.
> > > > > > > > > > > >
> > > > > > > > > > > > -ash
> > > > > > > > > > > >
> > > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > > xd.deng.r@gmail.com
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > +1 for GitHub Actions. I have been using it for
> > months
> > > > for
> > > > > my
> > > > > > > > side
> > > > > > > > > > > > > projects, and it’s working very well. I believe
> most
> > of
> > > > us
> > > > > > are
> > > > > > > > > quite
> > > > > > > > > > > > tired
> > > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > > >
> > > > > > > > > > > > > The only point I would like to remind is whether we
> > > need
> > > > to
> > > > > > > > > > communicate
> > > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > XD
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > > > kaxilnaik@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > > > > ash@apache.org>
> > > > > > > > > > wrote:
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> Happy with any thing that gives a more seamless
> CI
> > > > > > > experience -
> > > > > > > > > > > faster
> > > > > > > > > > > > is
> > > > > > > > > > > > >>> good too!
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> -a
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal
> Nurmamat
> > > > kyzy <
> > > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > > >
> > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>>> I am all for it! GitLab has been less-than
> > helpful
> > > so
> > > > > far
> > > > > > > and
> > > > > > > > > > > > >>>> recently it
> > > > > > > > > > > > >>>>> seems that running PRs from forks will only be
> > run
> > > in
> > > > > > > > > Enterrprise
> > > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > > >>>>> which is less than welcome. I am quite a bit
> > > > > disappointed
> > > > > > > > with
> > > > > > > > > > the
> > > > > > > > > > > > >>>> pace and
> > > > > > > > > > > > >>>>> attitude. Github Actions seems to be much
> better
> > > > > choice -
> > > > > > > > > > > especially
> > > > > > > > > > > > >>>> that
> > > > > > > > > > > > >>>>> they are closely integrated with Github repo
> and
> > > seem
> > > > > to
> > > > > > > get
> > > > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> And they added self-hosted runners as well,
> which
> > > > makes
> > > > > > it
> > > > > > > > > > possible
> > > > > > > > > > > > >>>> for us
> > > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> J.
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz
> Urbaszek <
> > > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> It sometime since we last discussed using
> other
> > CI
> > > > > than
> > > > > > > > > Travis.
> > > > > > > > > > > One
> > > > > > > > > > > > >>>> of
> > > > > > > > > > > > >>>>> the
> > > > > > > > > > > > >>>>>> main reasons behind considering Gitlab CI was
> > its
> > > > > > ability
> > > > > > > to
> > > > > > > > > > work
> > > > > > > > > > > > >>>> on
> > > > > > > > > > > > >>>>>> self-hosted runner. However, over time of few
> > long
> > > > > weeks
> > > > > > > > > Github
> > > > > > > > > > > > >>>> Actions
> > > > > > > > > > > > >>>>>> matured enough to allow using self-hosted
> > runners!
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> Github Actions are still growing but using
> them
> > > have
> > > > > few
> > > > > > > big
> > > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > > >>>>>> - forking repo and enabling actions will run
> CI
> > on
> > > > > your
> > > > > > > fork
> > > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > > >>>>>> - variety of actions (PR checks, greetings,
> etc)
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> I put together a PoC of CI in our internal
> repo:
> > > > > > > > > > > > >>>>>>
> > > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > > >>>>>> My impression is quite good. I like
> information
> > > > about
> > > > > > > steps
> > > > > > > > > > > > >>>> successes at
> > > > > > > > > > > > >>>>>> the PR level (no need to go to CI to check
> which
> > > > step
> > > > > > > > failed).
> > > > > > > > > > The
> > > > > > > > > > > > >>>> build
> > > > > > > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> Does any of you have any experience with
> Github
> > > > > Actions?
> > > > > > > Any
> > > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > > >>>>>>> FYI: Interesting article about the history
> > behind
> > > > > > > GitLabCI
> > > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can
> > > > fairly
> > > > > > > easily
> > > > > > > > > > > > >>>> replicate
> > > > > > > > > > > > >>>>>> the
> > > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can
> say -
> > > it
> > > > > > > > generally
> > > > > > > > > > > > >>>> works, I
> > > > > > > > > > > > >>>>>> can
> > > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in
> the
> > > > main
> > > > > > > > Airflow
> > > > > > > > > > > > >>>> project
> > > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > > >>>>>>>> few weeks to see how it is doing (while I am
> > no
> > > > > > > holidays)
> > > > > > > > > and
> > > > > > > > > > > > >>>> once we
> > > > > > > > > > > > >>>>>> see
> > > > > > > > > > > > >>>>>>>> it running and get the support for PRs from
> > > GitLab
> > > > > we
> > > > > > > can
> > > > > > > > > > > > >>>> switch to
> > > > > > > > > > > > >>>>> it.
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> What do you think ? Should i call a vote or
> > just
> > > > try
> > > > > > to
> > > > > > > > set
> > > > > > > > > it
> > > > > > > > > > > > >>>> up ?
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> - I manged to get full working builds in
> > > GitLabCI
> > > > +
> > > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > > >>>>>>>> without the kubernetes-specific tests yet,
> but
> > > > this
> > > > > > > should
> > > > > > > > > > > > >>>> be
> > > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > > >>>>>>>> - Working example here - you can take a look
> > and
> > > > > > compare
> > > > > > > > the
> > > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > > >>>>>> it
> > > > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so
> > far
> > > > > (still
> > > > > > > > > > > > >>>> around 35
> > > > > > > > > > > > >>>>>>>> minutes in total), but I plan to optimise it
> > > > > further.
> > > > > > I
> > > > > > > > can
> > > > > > > > > > > > >>>> play
> > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > >>>>>>>> memory/cpu settings of individual workers
> (Got
> > > > some
> > > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > > storage/logs/etc
> > > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for
> > > > initial
> > > > > > > 24) -
> > > > > > > > > > > > >>>> that
> > > > > > > > > > > > >>>>>> should
> > > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> > independently
> > > > from
> > > > > > > each
> > > > > > > > > > > > >>>> other.
> > > > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes working
> > (we
> > > > > have
> > > > > > > > built
> > > > > > > > > > > > >>>> in
> > > > > > > > > > > > >>>>> retry
> > > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of
> system
> > > > > failures
> > > > > > > > like
> > > > > > > > > > > > >>>> that
> > > > > > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40
> > USD.
> > > We
> > > > > > > should
> > > > > > > > be
> > > > > > > > > > > > >>>> way
> > > > > > > > > > > > >>>>>> below
> > > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > > back-of-the-envelope
> > > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > > >>>>>>>> - The current setup does not use GCR as
> cache
> > > and
> > > > > > Kaniko
> > > > > > > > as
> > > > > > > > > > > > >>>> I
> > > > > > > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > > > > > > authentication
> > > > > > > > > > > > >>>> (and
> > > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not
> yet
> > > > well
> > > > > > > handle
> > > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > > >>>>>>>>
> > > > > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > > ).
> > > > > > > > > > > > >>>> I
> > > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > > >>>>>> to
> > > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub
> -
> > so
> > > > > that
> > > > > > we
> > > > > > > > can
> > > > > > > > > > > > >>>> have
> > > > > > > > > > > > >>>>>>>> reliable downloads not depending on
> > DockerHub's
> > > > > > > stability
> > > > > > > > > > > > >>>> (it has
> > > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could
> > be
> > > > run
> > > > > in
> > > > > > > any
> > > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > > >>>>>>>> cluster (some optimisations like local
> volumes
> > > > > > mounting
> > > > > > > > for
> > > > > > > > > > > > >>>> docker
> > > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but
> > should
> > > be
> > > > > > > > generally
> > > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > > >>>>>>>> - You can take a look at the current source
> > code
> > > > in
> > > > > > > > > > > > >>>>>>>>
> > > > > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > > >>>>>>>> - There will be some updates (I will get rid
> > of
> > > > > custom
> > > > > > > > > > > > >>>> builder
> > > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes
> > > tests)
> > > > -
> > > > > > it's
> > > > > > > > > > > > >>>> mostly
> > > > > > > > > > > > >>>>> some
> > > > > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific
> > variables
> > > +
> > > > > > > > gitlab.ci
> > > > > > > > > > > > >>>> yaml
> > > > > > > > > > > > >>>>>> with
> > > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek
> Potiuk
> > <
> > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>>> So GitLab already works on automatically
> > > running
> > > > > > builds
> > > > > > > > > from
> > > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > >>>>>>>>> Kamil got involved and will be out advocate
> > on
> > > > it:
> > > > > > > > > > > > >>>>>>>>>
> > > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek
> > > Potiuk <
> > > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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
> <+48%20660%20796%20129>
> > > > > > > > <+48660796129
> > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> > https://www.polidea.com/>
> > > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> |
> > > Principal
> > > > > > > Software
> > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > > <+48660796129
> > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > >>>>>>>>>> [image: Polidea] <
> https://www.polidea.com/>
> > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> |
> > Principal
> > > > > > Software
> > > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > <+48660796129
> > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> |
> Principal
> > > > > > Software
> > > > > > > > > > Engineer
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > <+48660796129
> > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > > > >>>>>>>
> > > > > > > > > > > > >>>>>>
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> --
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal
> > > > > Software
> > > > > > > > > Engineer
> > > > > > > > > > > > >>>>>
> > > > > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > <+48660796129
> > > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > > >>>>> [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/>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > >
> > > > > > > > > > Tomasz Urbaszek
> > > > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> > > Engineer
> > > > > > > > > >
> > > > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > > > E: tomasz.urbaszek@polidea.com <
> > tomasz.urbaszeki@polidea.com
> > > >
> > > > > > > > > >
> > > > > > > > > > Unique Tech
> > > > > > > > > > Check out our projects! <
> https://www.polidea.com/our-work>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Jarek Potiuk
> > > > > > > > Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > > > > >
> > > > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Tomasz Urbaszek
> > > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > > >
> > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > > >
> > > > > > > Unique Tech
> > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Jarek Potiuk
> > > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > > >
> > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Tomasz Urbaszek
> > > > Polidea <https://www.polidea.com/> | Software Engineer
> > > >
> > > > M: +48 505 628 493 <+48505628493>
> > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > > Unique Tech
> > > > Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kaxil Naik <ka...@gmail.com>]

Yeah, that would be nice.

On Sat, Jan 11, 2020, 10:35 Tomasz Urbaszek <tu...@apache.org> wrote:

> An additional advantage of GA + self-hosted runners is the ability to
> ssh to machine and see what is going on (for example why tests timeout).
>
> T.
>
> On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com> wrote:
>
> > Awesome Tomek, great job. Waiting for your PR eagerly :) and can't wait
> to
> > move out of Travis.
> >
> > On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> > tomasz.urbaszek@polidea.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > Just a small update:
> > > - after Jarek's changes from
> https://github.com/apache/airflow/pull/6516
> > > kubernetes
> > >   builds started to run (proviously there was an issue with kind)
> > > - I am testing self-hosted runners
> > >
> > > It seems that possible migration is getting closer ;)
> > >
> > > Bests,
> > > Tomek
> > >
> > > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <philgagnon1@gmail.com
> >
> > > wrote:
> > >
> > > > We have been using Actions on the prestosql project for a little
> while
> > > as a
> > > > Travis replacement and we like it a lot.
> > > >
> > > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > > > wrote:
> > > >
> > > > > :(
> > > > >
> > > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > > tomasz.urbaszek@polidea.com>
> > > > > wrote:
> > > > >
> > > > > > I started to play with self-hosted runner and... well,
> encountered
> > > > known
> > > > > > error:
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > > >
> > > > > > It seems that GA is still maturing.
> > > > > >
> > > > > > Bests,
> > > > > > Tomek
> > > > > >
> > > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > > Jarek.Potiuk@polidea.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Yeah. All at once seems more than reasonable.
> > > > > > >
> > > > > > > J.
> > > > > > >
> > > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <
> kaxilnaik@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > > >
> > > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > > daniel.imberman@gmail.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > I’d rather we do it all at once and not need to maintain
> two
> > > > > builds.
> > > > > > > > > Most/all of our CI/CD is dockerized at this point so there
> > > > > shouldn’t
> > > > > > > be a
> > > > > > > > > huge difference.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > I have to solve a problem with our kubernetes test but for
> > your
> > > > > > > > information
> > > > > > > > > I have never experienced a flaky
> > > > > > > > > or timeouted build on Github Actions. Maybe I am lucky or
> > maybe
> > > > > > there's
> > > > > > > > > something different.
> > > > > > > > >
> > > > > > > > > If we agree to move to Github Actions, would we like to
> > migrate
> > > > > > > > > incrementally or fully?
> > > > > > > > >
> > > > > > > > > Bests,
> > > > > > > > > Tomek
> > > > > > > > >
> > > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > > Jarek.Potiuk@polidea.com
> > > > > > > >
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > No problem on that side - Tomek is using the same scripts
> > we
> > > > have
> > > > > > on
> > > > > > > > > Travis
> > > > > > > > > > (and they generally work - I think the last step is to
> make
> > > all
> > > > > the
> > > > > > > > > > tests pass. We have still a number of dependencies
> between
> > > > tests
> > > > > > and
> > > > > > > > some
> > > > > > > > > > environmental flakiness so that some tests consistently
> > fail
> > > in
> > > > > > > Github
> > > > > > > > > > Actions where they did not fail in Travis. From latest
> try
> > by
> > > > > Tomek
> > > > > > > it
> > > > > > > > > > looks like we are 1 test to go (plus some cleanup/setup
> of
> > > > > project
> > > > > > > and
> > > > > > > > > > making sure all is stable):
> > > > > > > > > >
> > > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in
> > > > 1207.96s
> > > > > > > > > (0:20:07)
> > > > > > > > > > =====
> > > > > > > > > >
> > > > > > > > > > We discussed with Tomek and Kamil that in order to speed
> it
> > > up
> > > > we
> > > > > > > might
> > > > > > > > > > want to run our own workers on the GCP account we have -
> > just
> > > > to
> > > > > > test
> > > > > > > > > > quickly how much we can optimise it and I am inclined to
> > > agree.
> > > > > If
> > > > > > we
> > > > > > > > do
> > > > > > > > > it
> > > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > > >
> > > > > > > > > > If we want to use auto-scalable GKE cluster as we
> > originally
> > > > > > planned
> > > > > > > it
> > > > > > > > > > might take more time to setup (similar setup to what I
> > tried
> > > > with
> > > > > > > > > GitLab).
> > > > > > > > > > There we might need to use docker-in-docker to build the
> CI
> > > > image
> > > > > > > with
> > > > > > > > > > latest as first step of build and then use that built
> image
> > > by
> > > > > all
> > > > > > > > > > subsequent steps. But we can do it as the next step -
> > > > optimising
> > > > > > the
> > > > > > > > > > experience.
> > > > > > > > > >
> > > > > > > > > > J.
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > +1 on my end as well.
> > > > > > > > > > >
> > > > > > > > > > > @jarek does this affect anything involving breeze? Do
> > > GitHub
> > > > > > > actions
> > > > > > > > > have
> > > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > > >
> > > > > > > > > > > via Newton Mail [
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > > ]
> > > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > > > > > ash@apache.org
> > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > > >
> > > > > > > > > > > Infra: possibly yes to get secrets in there to run
> things
> > > on
> > > > > our
> > > > > > > own
> > > > > > > > > > > "hardware" -
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > > <
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > >
> > > > > > > > > > > needs someone with Admin rights to create, and I don't
> > see
> > > > the
> > > > > > > > Settings
> > > > > > > > > > tab
> > > > > > > > > > > at all.
> > > > > > > > > > >
> > > > > > > > > > > -ash
> > > > > > > > > > >
> > > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > > xd.deng.r@gmail.com
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > +1 for GitHub Actions. I have been using it for
> months
> > > for
> > > > my
> > > > > > > side
> > > > > > > > > > > > projects, and it’s working very well. I believe most
> of
> > > us
> > > > > are
> > > > > > > > quite
> > > > > > > > > > > tired
> > > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > > >
> > > > > > > > > > > > The only point I would like to remind is whether we
> > need
> > > to
> > > > > > > > > communicate
> > > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > XD
> > > > > > > > > > > >
> > > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > > kaxilnaik@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > > > ash@apache.org>
> > > > > > > > > wrote:
> > > > > > > > > > > >>
> > > > > > > > > > > >>> Happy with any thing that gives a more seamless CI
> > > > > > experience -
> > > > > > > > > > faster
> > > > > > > > > > > is
> > > > > > > > > > > >>> good too!
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> -a
> > > > > > > > > > > >>>
> > > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat
> > > kyzy <
> > > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > > >
> > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>>> I am all for it! GitLab has been less-than
> helpful
> > so
> > > > far
> > > > > > and
> > > > > > > > > > > >>>> recently it
> > > > > > > > > > > >>>>> seems that running PRs from forks will only be
> run
> > in
> > > > > > > > Enterrprise
> > > > > > > > > > > >>>> Edition,
> > > > > > > > > > > >>>>> which is less than welcome. I am quite a bit
> > > > disappointed
> > > > > > > with
> > > > > > > > > the
> > > > > > > > > > > >>>> pace and
> > > > > > > > > > > >>>>> attitude. Github Actions seems to be much better
> > > > choice -
> > > > > > > > > > especially
> > > > > > > > > > > >>>> that
> > > > > > > > > > > >>>>> they are closely integrated with Github repo and
> > seem
> > > > to
> > > > > > get
> > > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> And they added self-hosted runners as well, which
> > > makes
> > > > > it
> > > > > > > > > possible
> > > > > > > > > > > >>>> for us
> > > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> J.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> J.
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > > >>>>> wrote:
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> It sometime since we last discussed using other
> CI
> > > > than
> > > > > > > > Travis.
> > > > > > > > > > One
> > > > > > > > > > > >>>> of
> > > > > > > > > > > >>>>> the
> > > > > > > > > > > >>>>>> main reasons behind considering Gitlab CI was
> its
> > > > > ability
> > > > > > to
> > > > > > > > > work
> > > > > > > > > > > >>>> on
> > > > > > > > > > > >>>>>> self-hosted runner. However, over time of few
> long
> > > > weeks
> > > > > > > > Github
> > > > > > > > > > > >>>> Actions
> > > > > > > > > > > >>>>>> matured enough to allow using self-hosted
> runners!
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> Github Actions are still growing but using them
> > have
> > > > few
> > > > > > big
> > > > > > > > > > > >>>> advantages:
> > > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > > >>>>>> - forking repo and enabling actions will run CI
> on
> > > > your
> > > > > > fork
> > > > > > > > > > > >>>>> automatically
> > > > > > > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > > > > > > >>>>>>
> > https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > > >>>>>> My impression is quite good. I like information
> > > about
> > > > > > steps
> > > > > > > > > > > >>>> successes at
> > > > > > > > > > > >>>>>> the PR level (no need to go to CI to check which
> > > step
> > > > > > > failed).
> > > > > > > > > The
> > > > > > > > > > > >>>> build
> > > > > > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> Does any of you have any experience with Github
> > > > Actions?
> > > > > > Any
> > > > > > > > > > > >>>> thoughts
> > > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> Best,
> > > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > > >>>> wrote:
> > > > > > > > > > > >>>>>>> FYI: Interesting article about the history
> behind
> > > > > > GitLabCI
> > > > > > > > > > > >>>> (featuring
> > > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can
> > > fairly
> > > > > > easily
> > > > > > > > > > > >>>> replicate
> > > > > > > > > > > >>>>>> the
> > > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say -
> > it
> > > > > > > generally
> > > > > > > > > > > >>>> works, I
> > > > > > > > > > > >>>>>> can
> > > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the
> > > main
> > > > > > > Airflow
> > > > > > > > > > > >>>> project
> > > > > > > > > > > >>>>>> for a
> > > > > > > > > > > >>>>>>>> few weeks to see how it is doing (while I am
> no
> > > > > > holidays)
> > > > > > > > and
> > > > > > > > > > > >>>> once we
> > > > > > > > > > > >>>>>> see
> > > > > > > > > > > >>>>>>>> it running and get the support for PRs from
> > GitLab
> > > > we
> > > > > > can
> > > > > > > > > > > >>>> switch to
> > > > > > > > > > > >>>>> it.
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> What do you think ? Should i call a vote or
> just
> > > try
> > > > > to
> > > > > > > set
> > > > > > > > it
> > > > > > > > > > > >>>> up ?
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> - I manged to get full working builds in
> > GitLabCI
> > > +
> > > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > > >>>>>>>> without the kubernetes-specific tests yet, but
> > > this
> > > > > > should
> > > > > > > > > > > >>>> be
> > > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > > >>>>>>>> - Working example here - you can take a look
> and
> > > > > compare
> > > > > > > the
> > > > > > > > > > > >>>>> UI/how
> > > > > > > > > > > >>>>>> it
> > > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > > > >>>>>>>>
> > > > > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so
> far
> > > > (still
> > > > > > > > > > > >>>> around 35
> > > > > > > > > > > >>>>>>>> minutes in total), but I plan to optimise it
> > > > further.
> > > > > I
> > > > > > > can
> > > > > > > > > > > >>>> play
> > > > > > > > > > > >>>>>> with
> > > > > > > > > > > >>>>>>>> memory/cpu settings of individual workers (Got
> > > some
> > > > > > > > > > > >>>> reasonable
> > > > > > > > > > > >>>>>> values now),
> > > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > > storage/logs/etc
> > > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for
> > > initial
> > > > > > 24) -
> > > > > > > > > > > >>>> that
> > > > > > > > > > > >>>>>> should
> > > > > > > > > > > >>>>>>>> let us build 3 builds in parallel
> independently
> > > from
> > > > > > each
> > > > > > > > > > > >>>> other.
> > > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes working
> (we
> > > > have
> > > > > > > built
> > > > > > > > > > > >>>> in
> > > > > > > > > > > >>>>> retry
> > > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of system
> > > > failures
> > > > > > > like
> > > > > > > > > > > >>>> that
> > > > > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40
> USD.
> > We
> > > > > > should
> > > > > > > be
> > > > > > > > > > > >>>> way
> > > > > > > > > > > >>>>>> below
> > > > > > > > > > > >>>>>>>> 500 USD/month according to my
> > back-of-the-envelope
> > > > > > > > > > > >>>> calculations.
> > > > > > > > > > > >>>>>> Likely
> > > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > > >>>>>>>> - The current setup does not use GCR as cache
> > and
> > > > > Kaniko
> > > > > > > as
> > > > > > > > > > > >>>> I
> > > > > > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > > > > > authentication
> > > > > > > > > > > >>>> (and
> > > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet
> > > well
> > > > > > handle
> > > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > > >>>>>>>>
> > > > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > > ).
> > > > > > > > > > > >>>> I
> > > > > > > > > > > >>>>>> updated
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>
> > > > > > > > > > > >>>
> > > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > > >>>>>> to
> > > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub -
> so
> > > > that
> > > > > we
> > > > > > > can
> > > > > > > > > > > >>>> have
> > > > > > > > > > > >>>>>>>> reliable downloads not depending on
> DockerHub's
> > > > > > stability
> > > > > > > > > > > >>>> (it has
> > > > > > > > > > > >>>>>> problems
> > > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could
> be
> > > run
> > > > in
> > > > > > any
> > > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > > >>>>>>>> cluster (some optimisations like local volumes
> > > > > mounting
> > > > > > > for
> > > > > > > > > > > >>>> docker
> > > > > > > > > > > >>>>>> engine
> > > > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but
> should
> > be
> > > > > > > generally
> > > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > > >>>>>>>> - You can take a look at the current source
> code
> > > in
> > > > > > > > > > > >>>>>>>>
> > > > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > > >>>>>>>> - There will be some updates (I will get rid
> of
> > > > custom
> > > > > > > > > > > >>>> builder
> > > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes
> > tests)
> > > -
> > > > > it's
> > > > > > > > > > > >>>> mostly
> > > > > > > > > > > >>>>> some
> > > > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific
> variables
> > +
> > > > > > > gitlab.ci
> > > > > > > > > > > >>>> yaml
> > > > > > > > > > > >>>>>> with
> > > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk
> <
> > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>>> So GitLab already works on automatically
> > running
> > > > > builds
> > > > > > > > from
> > > > > > > > > > > >>>> for PRs
> > > > > > > > > > > >>>>>> :).
> > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > >>>>>>>>> Kamil got involved and will be out advocate
> on
> > > it:
> > > > > > > > > > > >>>>>>>>>
> > > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek
> > Potiuk <
> > > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > > >>>>>>>>>
> > > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > > > > > > <+48660796129
> > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <
> https://www.polidea.com/>
> > > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> |
> > Principal
> > > > > > Software
> > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > > <+48660796129
> > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> --
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> |
> Principal
> > > > > Software
> > > > > > > > > > > >>>> Engineer
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > <+48660796129
> > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>>
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>> --
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > > > Software
> > > > > > > > > Engineer
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > <+48660796129
> > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > > >>>>>>>
> > > > > > > > > > > >>>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> --
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal
> > > > Software
> > > > > > > > Engineer
> > > > > > > > > > > >>>>>
> > > > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > <+48660796129
> > > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > > >>>>> [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/>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > >
> > > > > > > > > Tomasz Urbaszek
> > > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> > Engineer
> > > > > > > > >
> > > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > > E: tomasz.urbaszek@polidea.com <
> tomasz.urbaszeki@polidea.com
> > >
> > > > > > > > >
> > > > > > > > > Unique Tech
> > > > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Jarek Potiuk
> > > > > > > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > > > > >
> > > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tomasz Urbaszek
> > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > >
> > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > >
> > > > > > Unique Tech
> > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Jarek Potiuk
> > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > >
> > > > > M: +48 660 796 129 <+48660796129>
> > > > > [image: Polidea] <https://www.polidea.com/>
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Tomasz Urbaszek
> > > Polidea <https://www.polidea.com/> | Software Engineer
> > >
> > > M: +48 505 628 493 <+48505628493>
> > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > > Unique Tech
> > > Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <tu...@apache.org>]

An additional advantage of GA + self-hosted runners is the ability to
ssh to machine and see what is going on (for example why tests timeout).

T.

On Sat, Jan 11, 2020 at 4:23 AM Kaxil Naik <ka...@gmail.com> wrote:

> Awesome Tomek, great job. Waiting for your PR eagerly :) and can't wait to
> move out of Travis.
>
> On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com>
> wrote:
>
> > Hi all,
> >
> > Just a small update:
> > - after Jarek's changes from https://github.com/apache/airflow/pull/6516
> > kubernetes
> >   builds started to run (proviously there was an issue with kind)
> > - I am testing self-hosted runners
> >
> > It seems that possible migration is getting closer ;)
> >
> > Bests,
> > Tomek
> >
> > On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <ph...@gmail.com>
> > wrote:
> >
> > > We have been using Actions on the prestosql project for a little while
> > as a
> > > Travis replacement and we like it a lot.
> > >
> > > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > wrote:
> > >
> > > > :(
> > > >
> > > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com>
> > > > wrote:
> > > >
> > > > > I started to play with self-hosted runner and... well, encountered
> > > known
> > > > > error:
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > > >
> > > > > It seems that GA is still maturing.
> > > > >
> > > > > Bests,
> > > > > Tomek
> > > > >
> > > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> > Jarek.Potiuk@polidea.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Yeah. All at once seems more than reasonable.
> > > > > >
> > > > > > J.
> > > > > >
> > > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com>
> > > > wrote:
> > > > > >
> > > > > > > Agree with Daniel, let's do it all at once.
> > > > > > >
> > > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > > daniel.imberman@gmail.com
> > > > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I’d rather we do it all at once and not need to maintain two
> > > > builds.
> > > > > > > > Most/all of our CI/CD is dockerized at this point so there
> > > > shouldn’t
> > > > > > be a
> > > > > > > > huge difference.
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > I have to solve a problem with our kubernetes test but for
> your
> > > > > > > information
> > > > > > > > I have never experienced a flaky
> > > > > > > > or timeouted build on Github Actions. Maybe I am lucky or
> maybe
> > > > > there's
> > > > > > > > something different.
> > > > > > > >
> > > > > > > > If we agree to move to Github Actions, would we like to
> migrate
> > > > > > > > incrementally or fully?
> > > > > > > >
> > > > > > > > Bests,
> > > > > > > > Tomek
> > > > > > > >
> > > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > > Jarek.Potiuk@polidea.com
> > > > > > >
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > No problem on that side - Tomek is using the same scripts
> we
> > > have
> > > > > on
> > > > > > > > Travis
> > > > > > > > > (and they generally work - I think the last step is to make
> > all
> > > > the
> > > > > > > > > tests pass. We have still a number of dependencies between
> > > tests
> > > > > and
> > > > > > > some
> > > > > > > > > environmental flakiness so that some tests consistently
> fail
> > in
> > > > > > Github
> > > > > > > > > Actions where they did not fail in Travis. From latest try
> by
> > > > Tomek
> > > > > > it
> > > > > > > > > looks like we are 1 test to go (plus some cleanup/setup of
> > > > project
> > > > > > and
> > > > > > > > > making sure all is stable):
> > > > > > > > >
> > > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in
> > > 1207.96s
> > > > > > > > (0:20:07)
> > > > > > > > > =====
> > > > > > > > >
> > > > > > > > > We discussed with Tomek and Kamil that in order to speed it
> > up
> > > we
> > > > > > might
> > > > > > > > > want to run our own workers on the GCP account we have -
> just
> > > to
> > > > > test
> > > > > > > > > quickly how much we can optimise it and I am inclined to
> > agree.
> > > > If
> > > > > we
> > > > > > > do
> > > > > > > > it
> > > > > > > > > this way, the transition might be rather fast.
> > > > > > > > >
> > > > > > > > > If we want to use auto-scalable GKE cluster as we
> originally
> > > > > planned
> > > > > > it
> > > > > > > > > might take more time to setup (similar setup to what I
> tried
> > > with
> > > > > > > > GitLab).
> > > > > > > > > There we might need to use docker-in-docker to build the CI
> > > image
> > > > > > with
> > > > > > > > > latest as first step of build and then use that built image
> > by
> > > > all
> > > > > > > > > subsequent steps. But we can do it as the next step -
> > > optimising
> > > > > the
> > > > > > > > > experience.
> > > > > > > > >
> > > > > > > > > J.
> > > > > > > > >
> > > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1 on my end as well.
> > > > > > > > > >
> > > > > > > > > > @jarek does this affect anything involving breeze? Do
> > GitHub
> > > > > > actions
> > > > > > > > have
> > > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > > >
> > > > > > > > > > via Newton Mail [
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > > ]
> > > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > > > > ash@apache.org
> > > > > > >
> > > > > > > > > wrote:
> > > > > > > > > > Legal: no I don't think so.
> > > > > > > > > >
> > > > > > > > > > Infra: possibly yes to get secrets in there to run things
> > on
> > > > our
> > > > > > own
> > > > > > > > > > "hardware" -
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > > <
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > >
> > > > > > > > > > needs someone with Admin rights to create, and I don't
> see
> > > the
> > > > > > > Settings
> > > > > > > > > tab
> > > > > > > > > > at all.
> > > > > > > > > >
> > > > > > > > > > -ash
> > > > > > > > > >
> > > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > > xd.deng.r@gmail.com
> > > > >
> > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > +1 for GitHub Actions. I have been using it for months
> > for
> > > my
> > > > > > side
> > > > > > > > > > > projects, and it’s working very well. I believe most of
> > us
> > > > are
> > > > > > > quite
> > > > > > > > > > tired
> > > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > > >
> > > > > > > > > > > The only point I would like to remind is whether we
> need
> > to
> > > > > > > > communicate
> > > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > XD
> > > > > > > > > > >
> > > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > > kaxilnaik@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > >> +1 for Github actions
> > > > > > > > > > >>
> > > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > > ash@apache.org>
> > > > > > > > wrote:
> > > > > > > > > > >>
> > > > > > > > > > >>> Happy with any thing that gives a more seamless CI
> > > > > experience -
> > > > > > > > > faster
> > > > > > > > > > is
> > > > > > > > > > >>> good too!
> > > > > > > > > > >>>
> > > > > > > > > > >>> -a
> > > > > > > > > > >>>
> > > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat
> > kyzy <
> > > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > > >>>>
> > > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > > >
> > > > > > > > > > >>>> wrote:
> > > > > > > > > > >>>>
> > > > > > > > > > >>>>> I am all for it! GitLab has been less-than helpful
> so
> > > far
> > > > > and
> > > > > > > > > > >>>> recently it
> > > > > > > > > > >>>>> seems that running PRs from forks will only be run
> in
> > > > > > > Enterrprise
> > > > > > > > > > >>>> Edition,
> > > > > > > > > > >>>>> which is less than welcome. I am quite a bit
> > > disappointed
> > > > > > with
> > > > > > > > the
> > > > > > > > > > >>>> pace and
> > > > > > > > > > >>>>> attitude. Github Actions seems to be much better
> > > choice -
> > > > > > > > > especially
> > > > > > > > > > >>>> that
> > > > > > > > > > >>>>> they are closely integrated with Github repo and
> seem
> > > to
> > > > > get
> > > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> And they added self-hosted runners as well, which
> > makes
> > > > it
> > > > > > > > possible
> > > > > > > > > > >>>> for us
> > > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> J.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> J.
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > > >>>>> wrote:
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>> Hi all,
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> It sometime since we last discussed using other CI
> > > than
> > > > > > > Travis.
> > > > > > > > > One
> > > > > > > > > > >>>> of
> > > > > > > > > > >>>>> the
> > > > > > > > > > >>>>>> main reasons behind considering Gitlab CI was its
> > > > ability
> > > > > to
> > > > > > > > work
> > > > > > > > > > >>>> on
> > > > > > > > > > >>>>>> self-hosted runner. However, over time of few long
> > > weeks
> > > > > > > Github
> > > > > > > > > > >>>> Actions
> > > > > > > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> Github Actions are still growing but using them
> have
> > > few
> > > > > big
> > > > > > > > > > >>>> advantages:
> > > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > > >>>>>> - forking repo and enabling actions will run CI on
> > > your
> > > > > fork
> > > > > > > > > > >>>>> automatically
> > > > > > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > > > > > >>>>>>
> https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > > >>>>>> My impression is quite good. I like information
> > about
> > > > > steps
> > > > > > > > > > >>>> successes at
> > > > > > > > > > >>>>>> the PR level (no need to go to CI to check which
> > step
> > > > > > failed).
> > > > > > > > The
> > > > > > > > > > >>>> build
> > > > > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> Does any of you have any experience with Github
> > > Actions?
> > > > > Any
> > > > > > > > > > >>>> thoughts
> > > > > > > > > > >>>>>> about using it?
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> Best,
> > > > > > > > > > >>>>>> Tomek
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > > >>>> wrote:
> > > > > > > > > > >>>>>>> FYI: Interesting article about the history behind
> > > > > GitLabCI
> > > > > > > > > > >>>> (featuring
> > > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > > >>>>>>> wrote:
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can
> > fairly
> > > > > easily
> > > > > > > > > > >>>> replicate
> > > > > > > > > > >>>>>> the
> > > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say -
> it
> > > > > > generally
> > > > > > > > > > >>>> works, I
> > > > > > > > > > >>>>>> can
> > > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the
> > main
> > > > > > Airflow
> > > > > > > > > > >>>> project
> > > > > > > > > > >>>>>> for a
> > > > > > > > > > >>>>>>>> few weeks to see how it is doing (while I am no
> > > > > holidays)
> > > > > > > and
> > > > > > > > > > >>>> once we
> > > > > > > > > > >>>>>> see
> > > > > > > > > > >>>>>>>> it running and get the support for PRs from
> GitLab
> > > we
> > > > > can
> > > > > > > > > > >>>> switch to
> > > > > > > > > > >>>>> it.
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> What do you think ? Should i call a vote or just
> > try
> > > > to
> > > > > > set
> > > > > > > it
> > > > > > > > > > >>>> up ?
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> Some details
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> - I manged to get full working builds in
> GitLabCI
> > +
> > > > > > > > > > >>>> kubernetes -
> > > > > > > > > > >>>>>>>> without the kubernetes-specific tests yet, but
> > this
> > > > > should
> > > > > > > > > > >>>> be
> > > > > > > > > > >>>>>> rather easy
> > > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > > >>>>>>>> - Working example here - you can take a look and
> > > > compare
> > > > > > the
> > > > > > > > > > >>>>> UI/how
> > > > > > > > > > >>>>>> it
> > > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > > >>>>>>>>
> > > > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far
> > > (still
> > > > > > > > > > >>>> around 35
> > > > > > > > > > >>>>>>>> minutes in total), but I plan to optimise it
> > > further.
> > > > I
> > > > > > can
> > > > > > > > > > >>>> play
> > > > > > > > > > >>>>>> with
> > > > > > > > > > >>>>>>>> memory/cpu settings of individual workers (Got
> > some
> > > > > > > > > > >>>> reasonable
> > > > > > > > > > >>>>>> values now),
> > > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> > storage/logs/etc
> > > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for
> > initial
> > > > > 24) -
> > > > > > > > > > >>>> that
> > > > > > > > > > >>>>>> should
> > > > > > > > > > >>>>>>>> let us build 3 builds in parallel independently
> > from
> > > > > each
> > > > > > > > > > >>>> other.
> > > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes working (we
> > > have
> > > > > > built
> > > > > > > > > > >>>> in
> > > > > > > > > > >>>>> retry
> > > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of system
> > > failures
> > > > > > like
> > > > > > > > > > >>>> that
> > > > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD.
> We
> > > > > should
> > > > > > be
> > > > > > > > > > >>>> way
> > > > > > > > > > >>>>>> below
> > > > > > > > > > >>>>>>>> 500 USD/month according to my
> back-of-the-envelope
> > > > > > > > > > >>>> calculations.
> > > > > > > > > > >>>>>> Likely
> > > > > > > > > > >>>>>>>> well below
> > > > > > > > > > >>>>>>>> - The current setup does not use GCR as cache
> and
> > > > Kaniko
> > > > > > as
> > > > > > > > > > >>>> I
> > > > > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > > > > authentication
> > > > > > > > > > >>>> (and
> > > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet
> > well
> > > > > handle
> > > > > > > > > > >>>>>> multi-staging
> > > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > > >>>>>>>>
> > > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > > ).
> > > > > > > > > > >>>> I
> > > > > > > > > > >>>>>> updated
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > > >>>>>> to
> > > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so
> > > that
> > > > we
> > > > > > can
> > > > > > > > > > >>>> have
> > > > > > > > > > >>>>>>>> reliable downloads not depending on DockerHub's
> > > > > stability
> > > > > > > > > > >>>> (it has
> > > > > > > > > > >>>>>> problems
> > > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be
> > run
> > > in
> > > > > any
> > > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > > >>>>>>>> cluster (some optimisations like local volumes
> > > > mounting
> > > > > > for
> > > > > > > > > > >>>> docker
> > > > > > > > > > >>>>>> engine
> > > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but should
> be
> > > > > > generally
> > > > > > > > > > >>>>>> replicable).
> > > > > > > > > > >>>>>>>> - You can take a look at the current source code
> > in
> > > > > > > > > > >>>>>>>>
> > > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > > >>>>>>>> - There will be some updates (I will get rid of
> > > custom
> > > > > > > > > > >>>> builder
> > > > > > > > > > >>>>>> Docker,
> > > > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes
> tests)
> > -
> > > > it's
> > > > > > > > > > >>>> mostly
> > > > > > > > > > >>>>> some
> > > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific variables
> +
> > > > > > gitlab.ci
> > > > > > > > > > >>>> yaml
> > > > > > > > > > >>>>>> with
> > > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> J.
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>> So GitLab already works on automatically
> running
> > > > builds
> > > > > > > from
> > > > > > > > > > >>>> for PRs
> > > > > > > > > > >>>>>> :).
> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >>>>>>>>> Kamil got involved and will be out advocate on
> > it:
> > > > > > > > > > >>>>>>>>>
> > > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > > >>>>>>>>> J.
> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek
> Potiuk <
> > > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > > >>>>>>>>>
> > > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > > > > > <+48660796129
> > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > >>>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>> --
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> |
> Principal
> > > > > Software
> > > > > > > > > > >>>> Engineer
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > > <+48660796129
> > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>>>
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> --
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > > Software
> > > > > > > > > > >>>> Engineer
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > <+48660796129
> > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>>
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> --
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > > Software
> > > > > > > > Engineer
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > <+48660796129
> > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > > >>>>>>>
> > > > > > > > > > >>>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> --
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal
> > > Software
> > > > > > > Engineer
> > > > > > > > > > >>>>>
> > > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > > >>>>> [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/>
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > >
> > > > > > > > Tomasz Urbaszek
> > > > > > > > Polidea <https://www.polidea.com/> | Junior Software
> Engineer
> > > > > > > >
> > > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > > E: tomasz.urbaszek@polidea.com <tomasz.urbaszeki@polidea.com
> >
> > > > > > > >
> > > > > > > > Unique Tech
> > > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Jarek Potiuk
> > > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > > >
> > > > > > M: +48 660 796 129 <+48660796129>
> > > > > > [image: Polidea] <https://www.polidea.com/>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Tomasz Urbaszek
> > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > >
> > > > > M: +48 505 628 493 <+48505628493>
> > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > > Unique Tech
> > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Jarek Potiuk
> > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >
> > > > M: +48 660 796 129 <+48660796129>
> > > > [image: Polidea] <https://www.polidea.com/>
> > > >
> > >
> >
> >
> > --
> >
> > Tomasz Urbaszek
> > Polidea <https://www.polidea.com/> | Software Engineer
> >
> > M: +48 505 628 493 <+48505628493>
> > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >
> > Unique Tech
> > Check out our projects! <https://www.polidea.com/our-work>
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kaxil Naik <ka...@gmail.com>]

Awesome Tomek, great job. Waiting for your PR eagerly :) and can't wait to
move out of Travis.

On Fri, Jan 10, 2020 at 2:54 PM Tomasz Urbaszek <to...@polidea.com>
wrote:

> Hi all,
>
> Just a small update:
> - after Jarek's changes from https://github.com/apache/airflow/pull/6516
> kubernetes
>   builds started to run (proviously there was an issue with kind)
> - I am testing self-hosted runners
>
> It seems that possible migration is getting closer ;)
>
> Bests,
> Tomek
>
> On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <ph...@gmail.com>
> wrote:
>
> > We have been using Actions on the prestosql project for a little while
> as a
> > Travis replacement and we like it a lot.
> >
> > On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > :(
> > >
> > > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com>
> > > wrote:
> > >
> > > > I started to play with self-hosted runner and... well, encountered
> > known
> > > > error:
> > > >
> > > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > > >
> > > > It seems that GA is still maturing.
> > > >
> > > > Bests,
> > > > Tomek
> > > >
> > > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > > > wrote:
> > > >
> > > > > Yeah. All at once seems more than reasonable.
> > > > >
> > > > > J.
> > > > >
> > > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > >
> > > > > > Agree with Daniel, let's do it all at once.
> > > > > >
> > > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > > daniel.imberman@gmail.com
> > > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > I’d rather we do it all at once and not need to maintain two
> > > builds.
> > > > > > > Most/all of our CI/CD is dockerized at this point so there
> > > shouldn’t
> > > > > be a
> > > > > > > huge difference.
> > > > > > >
> > > > > > >
> > > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > I have to solve a problem with our kubernetes test but for your
> > > > > > information
> > > > > > > I have never experienced a flaky
> > > > > > > or timeouted build on Github Actions. Maybe I am lucky or maybe
> > > > there's
> > > > > > > something different.
> > > > > > >
> > > > > > > If we agree to move to Github Actions, would we like to migrate
> > > > > > > incrementally or fully?
> > > > > > >
> > > > > > > Bests,
> > > > > > > Tomek
> > > > > > >
> > > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > > Jarek.Potiuk@polidea.com
> > > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > No problem on that side - Tomek is using the same scripts we
> > have
> > > > on
> > > > > > > Travis
> > > > > > > > (and they generally work - I think the last step is to make
> all
> > > the
> > > > > > > > tests pass. We have still a number of dependencies between
> > tests
> > > > and
> > > > > > some
> > > > > > > > environmental flakiness so that some tests consistently fail
> in
> > > > > Github
> > > > > > > > Actions where they did not fail in Travis. From latest try by
> > > Tomek
> > > > > it
> > > > > > > > looks like we are 1 test to go (plus some cleanup/setup of
> > > project
> > > > > and
> > > > > > > > making sure all is stable):
> > > > > > > >
> > > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in
> > 1207.96s
> > > > > > > (0:20:07)
> > > > > > > > =====
> > > > > > > >
> > > > > > > > We discussed with Tomek and Kamil that in order to speed it
> up
> > we
> > > > > might
> > > > > > > > want to run our own workers on the GCP account we have - just
> > to
> > > > test
> > > > > > > > quickly how much we can optimise it and I am inclined to
> agree.
> > > If
> > > > we
> > > > > > do
> > > > > > > it
> > > > > > > > this way, the transition might be rather fast.
> > > > > > > >
> > > > > > > > If we want to use auto-scalable GKE cluster as we originally
> > > > planned
> > > > > it
> > > > > > > > might take more time to setup (similar setup to what I tried
> > with
> > > > > > > GitLab).
> > > > > > > > There we might need to use docker-in-docker to build the CI
> > image
> > > > > with
> > > > > > > > latest as first step of build and then use that built image
> by
> > > all
> > > > > > > > subsequent steps. But we can do it as the next step -
> > optimising
> > > > the
> > > > > > > > experience.
> > > > > > > >
> > > > > > > > J.
> > > > > > > >
> > > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > > daniel.imberman@gmail.com>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 on my end as well.
> > > > > > > > >
> > > > > > > > > @jarek does this affect anything involving breeze? Do
> GitHub
> > > > > actions
> > > > > > > have
> > > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > > >
> > > > > > > > > via Newton Mail [
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > > ]
> > > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > > > ash@apache.org
> > > > > >
> > > > > > > > wrote:
> > > > > > > > > Legal: no I don't think so.
> > > > > > > > >
> > > > > > > > > Infra: possibly yes to get secrets in there to run things
> on
> > > our
> > > > > own
> > > > > > > > > "hardware" -
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > > <
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > >
> > > > > > > > > needs someone with Admin rights to create, and I don't see
> > the
> > > > > > Settings
> > > > > > > > tab
> > > > > > > > > at all.
> > > > > > > > >
> > > > > > > > > -ash
> > > > > > > > >
> > > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> > xd.deng.r@gmail.com
> > > >
> > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > +1 for GitHub Actions. I have been using it for months
> for
> > my
> > > > > side
> > > > > > > > > > projects, and it’s working very well. I believe most of
> us
> > > are
> > > > > > quite
> > > > > > > > > tired
> > > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > > >
> > > > > > > > > > The only point I would like to remind is whether we need
> to
> > > > > > > communicate
> > > > > > > > > > with Infra/Legal team for this.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > XD
> > > > > > > > > >
> > > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > > kaxilnaik@gmail.com>
> > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >> +1 for Github actions
> > > > > > > > > >>
> > > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > > ash@apache.org>
> > > > > > > wrote:
> > > > > > > > > >>
> > > > > > > > > >>> Happy with any thing that gives a more seamless CI
> > > > experience -
> > > > > > > > faster
> > > > > > > > > is
> > > > > > > > > >>> good too!
> > > > > > > > > >>>
> > > > > > > > > >>> -a
> > > > > > > > > >>>
> > > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat
> kyzy <
> > > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > > >>>>
> > > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > > >
> > > > > > > > > >>>> wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>>> I am all for it! GitLab has been less-than helpful so
> > far
> > > > and
> > > > > > > > > >>>> recently it
> > > > > > > > > >>>>> seems that running PRs from forks will only be run in
> > > > > > Enterrprise
> > > > > > > > > >>>> Edition,
> > > > > > > > > >>>>> which is less than welcome. I am quite a bit
> > disappointed
> > > > > with
> > > > > > > the
> > > > > > > > > >>>> pace and
> > > > > > > > > >>>>> attitude. Github Actions seems to be much better
> > choice -
> > > > > > > > especially
> > > > > > > > > >>>> that
> > > > > > > > > >>>>> they are closely integrated with Github repo and seem
> > to
> > > > get
> > > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> And they added self-hosted runners as well, which
> makes
> > > it
> > > > > > > possible
> > > > > > > > > >>>> for us
> > > > > > > > > >>>>> to optimise the experience.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> J.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> J.
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > > >>>>> wrote:
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>> Hi all,
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> It sometime since we last discussed using other CI
> > than
> > > > > > Travis.
> > > > > > > > One
> > > > > > > > > >>>> of
> > > > > > > > > >>>>> the
> > > > > > > > > >>>>>> main reasons behind considering Gitlab CI was its
> > > ability
> > > > to
> > > > > > > work
> > > > > > > > > >>>> on
> > > > > > > > > >>>>>> self-hosted runner. However, over time of few long
> > weeks
> > > > > > Github
> > > > > > > > > >>>> Actions
> > > > > > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Github Actions are still growing but using them have
> > few
> > > > big
> > > > > > > > > >>>> advantages:
> > > > > > > > > >>>>>> - they are Github natives
> > > > > > > > > >>>>>> - forking repo and enabling actions will run CI on
> > your
> > > > fork
> > > > > > > > > >>>>> automatically
> > > > > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > > >>>>>> My impression is quite good. I like information
> about
> > > > steps
> > > > > > > > > >>>> successes at
> > > > > > > > > >>>>>> the PR level (no need to go to CI to check which
> step
> > > > > failed).
> > > > > > > The
> > > > > > > > > >>>> build
> > > > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Does any of you have any experience with Github
> > Actions?
> > > > Any
> > > > > > > > > >>>> thoughts
> > > > > > > > > >>>>>> about using it?
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> Best,
> > > > > > > > > >>>>>> Tomek
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > > >>>> wrote:
> > > > > > > > > >>>>>>> FYI: Interesting article about the history behind
> > > > GitLabCI
> > > > > > > > > >>>> (featuring
> > > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > > >>>>>>> wrote:
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can
> fairly
> > > > easily
> > > > > > > > > >>>> replicate
> > > > > > > > > >>>>>> the
> > > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it
> > > > > generally
> > > > > > > > > >>>> works, I
> > > > > > > > > >>>>>> can
> > > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the
> main
> > > > > Airflow
> > > > > > > > > >>>> project
> > > > > > > > > >>>>>> for a
> > > > > > > > > >>>>>>>> few weeks to see how it is doing (while I am no
> > > > holidays)
> > > > > > and
> > > > > > > > > >>>> once we
> > > > > > > > > >>>>>> see
> > > > > > > > > >>>>>>>> it running and get the support for PRs from GitLab
> > we
> > > > can
> > > > > > > > > >>>> switch to
> > > > > > > > > >>>>> it.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> What do you think ? Should i call a vote or just
> try
> > > to
> > > > > set
> > > > > > it
> > > > > > > > > >>>> up ?
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> Some details
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> - I manged to get full working builds in GitLabCI
> +
> > > > > > > > > >>>> kubernetes -
> > > > > > > > > >>>>>>>> without the kubernetes-specific tests yet, but
> this
> > > > should
> > > > > > > > > >>>> be
> > > > > > > > > >>>>>> rather easy
> > > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > > >>>>>>>> - Working example here - you can take a look and
> > > compare
> > > > > the
> > > > > > > > > >>>>> UI/how
> > > > > > > > > >>>>>> it
> > > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > > >>>>>>>>
> > > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far
> > (still
> > > > > > > > > >>>> around 35
> > > > > > > > > >>>>>>>> minutes in total), but I plan to optimise it
> > further.
> > > I
> > > > > can
> > > > > > > > > >>>> play
> > > > > > > > > >>>>>> with
> > > > > > > > > >>>>>>>> memory/cpu settings of individual workers (Got
> some
> > > > > > > > > >>>> reasonable
> > > > > > > > > >>>>>> values now),
> > > > > > > > > >>>>>>>> I can use local SSD disk as Docker
> storage/logs/etc
> > > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for
> initial
> > > > 24) -
> > > > > > > > > >>>> that
> > > > > > > > > >>>>>> should
> > > > > > > > > >>>>>>>> let us build 3 builds in parallel independently
> from
> > > > each
> > > > > > > > > >>>> other.
> > > > > > > > > >>>>>>>> - I managed to get Preemptible nodes working (we
> > have
> > > > > built
> > > > > > > > > >>>> in
> > > > > > > > > >>>>> retry
> > > > > > > > > >>>>>>>> mechanism in GitLab to work in case of system
> > failures
> > > > > like
> > > > > > > > > >>>> that
> > > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We
> > > > should
> > > > > be
> > > > > > > > > >>>> way
> > > > > > > > > >>>>>> below
> > > > > > > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > > > > > > >>>> calculations.
> > > > > > > > > >>>>>> Likely
> > > > > > > > > >>>>>>>> well below
> > > > > > > > > >>>>>>>> - The current setup does not use GCR as cache and
> > > Kaniko
> > > > > as
> > > > > > > > > >>>> I
> > > > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > > > authentication
> > > > > > > > > >>>> (and
> > > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet
> well
> > > > handle
> > > > > > > > > >>>>>> multi-staging
> > > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > > >>>>>>>>
> > > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > > ).
> > > > > > > > > >>>> I
> > > > > > > > > >>>>>> updated
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > > >>>>>> to
> > > > > > > > > >>>>>>>> reflect that.
> > > > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so
> > that
> > > we
> > > > > can
> > > > > > > > > >>>> have
> > > > > > > > > >>>>>>>> reliable downloads not depending on DockerHub's
> > > > stability
> > > > > > > > > >>>> (it has
> > > > > > > > > >>>>>> problems
> > > > > > > > > >>>>>>>> sometimes)
> > > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be
> run
> > in
> > > > any
> > > > > > > > > >>>>>> Kubernetes
> > > > > > > > > >>>>>>>> cluster (some optimisations like local volumes
> > > mounting
> > > > > for
> > > > > > > > > >>>> docker
> > > > > > > > > >>>>>> engine
> > > > > > > > > >>>>>>>> might have GCP-specific assumptions, but should be
> > > > > generally
> > > > > > > > > >>>>>> replicable).
> > > > > > > > > >>>>>>>> - You can take a look at the current source code
> in
> > > > > > > > > >>>>>>>>
> > > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > > >>>>>>>> - There will be some updates (I will get rid of
> > custom
> > > > > > > > > >>>> builder
> > > > > > > > > >>>>>> Docker,
> > > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes tests)
> -
> > > it's
> > > > > > > > > >>>> mostly
> > > > > > > > > >>>>> some
> > > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific variables +
> > > > > gitlab.ci
> > > > > > > > > >>>> yaml
> > > > > > > > > >>>>>> with
> > > > > > > > > >>>>>>>> job definitions.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> J.
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > >>>>>>>> wrote:
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>> So GitLab already works on automatically running
> > > builds
> > > > > > from
> > > > > > > > > >>>> for PRs
> > > > > > > > > >>>>>> :).
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>> Kamil got involved and will be out advocate on
> it:
> > > > > > > > > >>>>>>>>>
> > https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > > >>>>>>>>> J.
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > > >>>>>>>>> napisał:
> > > > > > > > > >>>>>>>>>
> > > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > > > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>>>>>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>> --
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > > Software
> > > > > > > > > >>>> Engineer
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> --
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > Software
> > > > > > > > > >>>> Engineer
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> --
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > Software
> > > > > > > Engineer
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > > >>>>>>>
> > > > > > > > > >>>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> --
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal
> > Software
> > > > > > Engineer
> > > > > > > > > >>>>>
> > > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > <+48660796129
> > > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > > >>>>> [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/>
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > >
> > > > > > > Tomasz Urbaszek
> > > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > > >
> > > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > > >
> > > > > > > Unique Tech
> > > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Jarek Potiuk
> > > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > > >
> > > > > M: +48 660 796 129 <+48660796129>
> > > > > [image: Polidea] <https://www.polidea.com/>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Tomasz Urbaszek
> > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > >
> > > > M: +48 505 628 493 <+48505628493>
> > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > > Unique Tech
> > > > Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
>
>
> --
>
> Tomasz Urbaszek
> Polidea <https://www.polidea.com/> | Software Engineer
>
> M: +48 505 628 493 <+48505628493>
> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <to...@polidea.com>]

Hi all,

Just a small update:
- after Jarek's changes from https://github.com/apache/airflow/pull/6516
kubernetes
  builds started to run (proviously there was an issue with kind)
- I am testing self-hosted runners

It seems that possible migration is getting closer ;)

Bests,
Tomek

On Tue, Dec 17, 2019 at 3:28 PM Philippe Gagnon <ph...@gmail.com>
wrote:

> We have been using Actions on the prestosql project for a little while as a
> Travis replacement and we like it a lot.
>
> On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > :(
> >
> > On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> > tomasz.urbaszek@polidea.com>
> > wrote:
> >
> > > I started to play with self-hosted runner and... well, encountered
> known
> > > error:
> > >
> > >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> > >
> > > It seems that GA is still maturing.
> > >
> > > Bests,
> > > Tomek
> > >
> > > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > wrote:
> > >
> > > > Yeah. All at once seems more than reasonable.
> > > >
> > > > J.
> > > >
> > > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > >
> > > > > Agree with Daniel, let's do it all at once.
> > > > >
> > > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > > daniel.imberman@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > I’d rather we do it all at once and not need to maintain two
> > builds.
> > > > > > Most/all of our CI/CD is dockerized at this point so there
> > shouldn’t
> > > > be a
> > > > > > huge difference.
> > > > > >
> > > > > >
> > > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > I have to solve a problem with our kubernetes test but for your
> > > > > information
> > > > > > I have never experienced a flaky
> > > > > > or timeouted build on Github Actions. Maybe I am lucky or maybe
> > > there's
> > > > > > something different.
> > > > > >
> > > > > > If we agree to move to Github Actions, would we like to migrate
> > > > > > incrementally or fully?
> > > > > >
> > > > > > Bests,
> > > > > > Tomek
> > > > > >
> > > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > > Jarek.Potiuk@polidea.com
> > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > No problem on that side - Tomek is using the same scripts we
> have
> > > on
> > > > > > Travis
> > > > > > > (and they generally work - I think the last step is to make all
> > the
> > > > > > > tests pass. We have still a number of dependencies between
> tests
> > > and
> > > > > some
> > > > > > > environmental flakiness so that some tests consistently fail in
> > > > Github
> > > > > > > Actions where they did not fail in Travis. From latest try by
> > Tomek
> > > > it
> > > > > > > looks like we are 1 test to go (plus some cleanup/setup of
> > project
> > > > and
> > > > > > > making sure all is stable):
> > > > > > >
> > > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in
> 1207.96s
> > > > > > (0:20:07)
> > > > > > > =====
> > > > > > >
> > > > > > > We discussed with Tomek and Kamil that in order to speed it up
> we
> > > > might
> > > > > > > want to run our own workers on the GCP account we have - just
> to
> > > test
> > > > > > > quickly how much we can optimise it and I am inclined to agree.
> > If
> > > we
> > > > > do
> > > > > > it
> > > > > > > this way, the transition might be rather fast.
> > > > > > >
> > > > > > > If we want to use auto-scalable GKE cluster as we originally
> > > planned
> > > > it
> > > > > > > might take more time to setup (similar setup to what I tried
> with
> > > > > > GitLab).
> > > > > > > There we might need to use docker-in-docker to build the CI
> image
> > > > with
> > > > > > > latest as first step of build and then use that built image by
> > all
> > > > > > > subsequent steps. But we can do it as the next step -
> optimising
> > > the
> > > > > > > experience.
> > > > > > >
> > > > > > > J.
> > > > > > >
> > > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > > daniel.imberman@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1 on my end as well.
> > > > > > > >
> > > > > > > > @jarek does this affect anything involving breeze? Do GitHub
> > > > actions
> > > > > > have
> > > > > > > > an easy docker/docker-compose based workflow?
> > > > > > > >
> > > > > > > > via Newton Mail [
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > > ]
> > > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > > ash@apache.org
> > > > >
> > > > > > > wrote:
> > > > > > > > Legal: no I don't think so.
> > > > > > > >
> > > > > > > > Infra: possibly yes to get secrets in there to run things on
> > our
> > > > own
> > > > > > > > "hardware" -
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > > <
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > >
> > > > > > > > needs someone with Admin rights to create, and I don't see
> the
> > > > > Settings
> > > > > > > tab
> > > > > > > > at all.
> > > > > > > >
> > > > > > > > -ash
> > > > > > > >
> > > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <
> xd.deng.r@gmail.com
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > +1 for GitHub Actions. I have been using it for months for
> my
> > > > side
> > > > > > > > > projects, and it’s working very well. I believe most of us
> > are
> > > > > quite
> > > > > > > > tired
> > > > > > > > > of the waiting time using Travis CI.
> > > > > > > > >
> > > > > > > > > The only point I would like to remind is whether we need to
> > > > > > communicate
> > > > > > > > > with Infra/Legal team for this.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > XD
> > > > > > > > >
> > > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> > kaxilnaik@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> +1 for Github actions
> > > > > > > > >>
> > > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> > ash@apache.org>
> > > > > > wrote:
> > > > > > > > >>
> > > > > > > > >>> Happy with any thing that gives a more seamless CI
> > > experience -
> > > > > > > faster
> > > > > > > > is
> > > > > > > > >>> good too!
> > > > > > > > >>>
> > > > > > > > >>> -a
> > > > > > > > >>>
> > > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > > >>>>
> > > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > > Jarek.Potiuk@polidea.com
> > > > > > > > >
> > > > > > > > >>>> wrote:
> > > > > > > > >>>>
> > > > > > > > >>>>> I am all for it! GitLab has been less-than helpful so
> far
> > > and
> > > > > > > > >>>> recently it
> > > > > > > > >>>>> seems that running PRs from forks will only be run in
> > > > > Enterrprise
> > > > > > > > >>>> Edition,
> > > > > > > > >>>>> which is less than welcome. I am quite a bit
> disappointed
> > > > with
> > > > > > the
> > > > > > > > >>>> pace and
> > > > > > > > >>>>> attitude. Github Actions seems to be much better
> choice -
> > > > > > > especially
> > > > > > > > >>>> that
> > > > > > > > >>>>> they are closely integrated with Github repo and seem
> to
> > > get
> > > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > > >>>>>
> > > > > > > > >>>>> And they added self-hosted runners as well, which makes
> > it
> > > > > > possible
> > > > > > > > >>>> for us
> > > > > > > > >>>>> to optimise the experience.
> > > > > > > > >>>>>
> > > > > > > > >>>>> J.
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> J.
> > > > > > > > >>>>>
> > > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > > >>>>> wrote:
> > > > > > > > >>>>>
> > > > > > > > >>>>>> Hi all,
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> It sometime since we last discussed using other CI
> than
> > > > > Travis.
> > > > > > > One
> > > > > > > > >>>> of
> > > > > > > > >>>>> the
> > > > > > > > >>>>>> main reasons behind considering Gitlab CI was its
> > ability
> > > to
> > > > > > work
> > > > > > > > >>>> on
> > > > > > > > >>>>>> self-hosted runner. However, over time of few long
> weeks
> > > > > Github
> > > > > > > > >>>> Actions
> > > > > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Github Actions are still growing but using them have
> few
> > > big
> > > > > > > > >>>> advantages:
> > > > > > > > >>>>>> - they are Github natives
> > > > > > > > >>>>>> - forking repo and enabling actions will run CI on
> your
> > > fork
> > > > > > > > >>>>> automatically
> > > > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > > >>>>>> My impression is quite good. I like information about
> > > steps
> > > > > > > > >>>> successes at
> > > > > > > > >>>>>> the PR level (no need to go to CI to check which step
> > > > failed).
> > > > > > The
> > > > > > > > >>>> build
> > > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Does any of you have any experience with Github
> Actions?
> > > Any
> > > > > > > > >>>> thoughts
> > > > > > > > >>>>>> about using it?
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> Best,
> > > > > > > > >>>>>> Tomek
> > > > > > > > >>>>>>
> > > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > > Jarek.Potiuk@polidea.com>
> > > > > > > > >>>> wrote:
> > > > > > > > >>>>>>> FYI: Interesting article about the history behind
> > > GitLabCI
> > > > > > > > >>>> (featuring
> > > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > > >>>>>>> wrote:
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can fairly
> > > easily
> > > > > > > > >>>> replicate
> > > > > > > > >>>>>> the
> > > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it
> > > > generally
> > > > > > > > >>>> works, I
> > > > > > > > >>>>>> can
> > > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the main
> > > > Airflow
> > > > > > > > >>>> project
> > > > > > > > >>>>>> for a
> > > > > > > > >>>>>>>> few weeks to see how it is doing (while I am no
> > > holidays)
> > > > > and
> > > > > > > > >>>> once we
> > > > > > > > >>>>>> see
> > > > > > > > >>>>>>>> it running and get the support for PRs from GitLab
> we
> > > can
> > > > > > > > >>>> switch to
> > > > > > > > >>>>> it.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> What do you think ? Should i call a vote or just try
> > to
> > > > set
> > > > > it
> > > > > > > > >>>> up ?
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> Some details
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > > > > > > > >>>> kubernetes -
> > > > > > > > >>>>>>>> without the kubernetes-specific tests yet, but this
> > > should
> > > > > > > > >>>> be
> > > > > > > > >>>>>> rather easy
> > > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > > >>>>>>>> - Working example here - you can take a look and
> > compare
> > > > the
> > > > > > > > >>>>> UI/how
> > > > > > > > >>>>>> it
> > > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > > >>>>>>>>
> > > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far
> (still
> > > > > > > > >>>> around 35
> > > > > > > > >>>>>>>> minutes in total), but I plan to optimise it
> further.
> > I
> > > > can
> > > > > > > > >>>> play
> > > > > > > > >>>>>> with
> > > > > > > > >>>>>>>> memory/cpu settings of individual workers (Got some
> > > > > > > > >>>> reasonable
> > > > > > > > >>>>>> values now),
> > > > > > > > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for initial
> > > 24) -
> > > > > > > > >>>> that
> > > > > > > > >>>>>> should
> > > > > > > > >>>>>>>> let us build 3 builds in parallel independently from
> > > each
> > > > > > > > >>>> other.
> > > > > > > > >>>>>>>> - I managed to get Preemptible nodes working (we
> have
> > > > built
> > > > > > > > >>>> in
> > > > > > > > >>>>> retry
> > > > > > > > >>>>>>>> mechanism in GitLab to work in case of system
> failures
> > > > like
> > > > > > > > >>>> that
> > > > > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We
> > > should
> > > > be
> > > > > > > > >>>> way
> > > > > > > > >>>>>> below
> > > > > > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > > > > > >>>> calculations.
> > > > > > > > >>>>>> Likely
> > > > > > > > >>>>>>>> well below
> > > > > > > > >>>>>>>> - The current setup does not use GCR as cache and
> > Kaniko
> > > > as
> > > > > > > > >>>> I
> > > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > > authentication
> > > > > > > > >>>> (and
> > > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well
> > > handle
> > > > > > > > >>>>>> multi-staging
> > > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > > >>>>>>>>
> > > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > > ).
> > > > > > > > >>>> I
> > > > > > > > >>>>>> updated
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > > >>>>>> to
> > > > > > > > >>>>>>>> reflect that.
> > > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so
> that
> > we
> > > > can
> > > > > > > > >>>> have
> > > > > > > > >>>>>>>> reliable downloads not depending on DockerHub's
> > > stability
> > > > > > > > >>>> (it has
> > > > > > > > >>>>>> problems
> > > > > > > > >>>>>>>> sometimes)
> > > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be run
> in
> > > any
> > > > > > > > >>>>>> Kubernetes
> > > > > > > > >>>>>>>> cluster (some optimisations like local volumes
> > mounting
> > > > for
> > > > > > > > >>>> docker
> > > > > > > > >>>>>> engine
> > > > > > > > >>>>>>>> might have GCP-specific assumptions, but should be
> > > > generally
> > > > > > > > >>>>>> replicable).
> > > > > > > > >>>>>>>> - You can take a look at the current source code in
> > > > > > > > >>>>>>>>
> > > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > > >>>>>>>> - There will be some updates (I will get rid of
> custom
> > > > > > > > >>>> builder
> > > > > > > > >>>>>> Docker,
> > > > > > > > >>>>>>>> simplify it a bit and implement kubernetes tests) -
> > it's
> > > > > > > > >>>> mostly
> > > > > > > > >>>>> some
> > > > > > > > >>>>>>>> cleanups + removal of Travis-Specific variables +
> > > > gitlab.ci
> > > > > > > > >>>> yaml
> > > > > > > > >>>>>> with
> > > > > > > > >>>>>>>> job definitions.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> J.
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > >>>>>>>> wrote:
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>> So GitLab already works on automatically running
> > builds
> > > > > from
> > > > > > > > >>>> for PRs
> > > > > > > > >>>>>> :).
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > > > > > > > >>>>>>>>>
> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > > >>>>>>>>> J.
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > > >>>>>>>>> napisał:
> > > > > > > > >>>>>>>>>
> > > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > > > <+48660796129
> > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >>>>>>>>>>>
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>> --
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > > Software
> > > > > > > > >>>> Engineer
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> --
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > Software
> > > > > > > > >>>> Engineer
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > <+48660796129
> > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> --
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal
> > Software
> > > > > > Engineer
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > <+48660796129
> > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > > >>>>>>>
> > > > > > > > >>>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>>
> > > > > > > > >>>>> --
> > > > > > > > >>>>>
> > > > > > > > >>>>> Jarek Potiuk
> > > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal
> Software
> > > > > Engineer
> > > > > > > > >>>>>
> > > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> <+48660796129
> > > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > > >>>>> [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/>
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > Tomasz Urbaszek
> > > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > > >
> > > > > > M: +48 505 628 493 <+48505628493>
> > > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > > >
> > > > > > Unique Tech
> > > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Jarek Potiuk
> > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >
> > > > M: +48 660 796 129 <+48660796129>
> > > > [image: Polidea] <https://www.polidea.com/>
> > > >
> > >
> > >
> > > --
> > >
> > > Tomasz Urbaszek
> > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >
> > > M: +48 505 628 493 <+48505628493>
> > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > > Unique Tech
> > > Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
>


-- 

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Philippe Gagnon <ph...@gmail.com>]

We have been using Actions on the prestosql project for a little while as a
Travis replacement and we like it a lot.

On Tue, Dec 17, 2019 at 9:08 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> :(
>
> On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com>
> wrote:
>
> > I started to play with self-hosted runner and... well, encountered known
> > error:
> >
> >
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
> >
> > It seems that GA is still maturing.
> >
> > Bests,
> > Tomek
> >
> > On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Yeah. All at once seems more than reasonable.
> > >
> > > J.
> > >
> > > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com>
> wrote:
> > >
> > > > Agree with Daniel, let's do it all at once.
> > > >
> > > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > > daniel.imberman@gmail.com
> > > > >
> > > > wrote:
> > > >
> > > > > I’d rather we do it all at once and not need to maintain two
> builds.
> > > > > Most/all of our CI/CD is dockerized at this point so there
> shouldn’t
> > > be a
> > > > > huge difference.
> > > > >
> > > > >
> > > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > > tomasz.urbaszek@polidea.com> wrote:
> > > > > Hi all,
> > > > >
> > > > > I have to solve a problem with our kubernetes test but for your
> > > > information
> > > > > I have never experienced a flaky
> > > > > or timeouted build on Github Actions. Maybe I am lucky or maybe
> > there's
> > > > > something different.
> > > > >
> > > > > If we agree to move to Github Actions, would we like to migrate
> > > > > incrementally or fully?
> > > > >
> > > > > Bests,
> > > > > Tomek
> > > > >
> > > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> > Jarek.Potiuk@polidea.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > No problem on that side - Tomek is using the same scripts we have
> > on
> > > > > Travis
> > > > > > (and they generally work - I think the last step is to make all
> the
> > > > > > tests pass. We have still a number of dependencies between tests
> > and
> > > > some
> > > > > > environmental flakiness so that some tests consistently fail in
> > > Github
> > > > > > Actions where they did not fail in Travis. From latest try by
> Tomek
> > > it
> > > > > > looks like we are 1 test to go (plus some cleanup/setup of
> project
> > > and
> > > > > > making sure all is stable):
> > > > > >
> > > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s
> > > > > (0:20:07)
> > > > > > =====
> > > > > >
> > > > > > We discussed with Tomek and Kamil that in order to speed it up we
> > > might
> > > > > > want to run our own workers on the GCP account we have - just to
> > test
> > > > > > quickly how much we can optimise it and I am inclined to agree.
> If
> > we
> > > > do
> > > > > it
> > > > > > this way, the transition might be rather fast.
> > > > > >
> > > > > > If we want to use auto-scalable GKE cluster as we originally
> > planned
> > > it
> > > > > > might take more time to setup (similar setup to what I tried with
> > > > > GitLab).
> > > > > > There we might need to use docker-in-docker to build the CI image
> > > with
> > > > > > latest as first step of build and then use that built image by
> all
> > > > > > subsequent steps. But we can do it as the next step - optimising
> > the
> > > > > > experience.
> > > > > >
> > > > > > J.
> > > > > >
> > > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > > daniel.imberman@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > +1 on my end as well.
> > > > > > >
> > > > > > > @jarek does this affect anything involving breeze? Do GitHub
> > > actions
> > > > > have
> > > > > > > an easy docker/docker-compose based workflow?
> > > > > > >
> > > > > > > via Newton Mail [
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > > ]
> > > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> > ash@apache.org
> > > >
> > > > > > wrote:
> > > > > > > Legal: no I don't think so.
> > > > > > >
> > > > > > > Infra: possibly yes to get secrets in there to run things on
> our
> > > own
> > > > > > > "hardware" -
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > > <
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > >
> > > > > > > needs someone with Admin rights to create, and I don't see the
> > > > Settings
> > > > > > tab
> > > > > > > at all.
> > > > > > >
> > > > > > > -ash
> > > > > > >
> > > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd.deng.r@gmail.com
> >
> > > > wrote:
> > > > > > > >
> > > > > > > > +1 for GitHub Actions. I have been using it for months for my
> > > side
> > > > > > > > projects, and it’s working very well. I believe most of us
> are
> > > > quite
> > > > > > > tired
> > > > > > > > of the waiting time using Travis CI.
> > > > > > > >
> > > > > > > > The only point I would like to remind is whether we need to
> > > > > communicate
> > > > > > > > with Infra/Legal team for this.
> > > > > > > >
> > > > > > > >
> > > > > > > > XD
> > > > > > > >
> > > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <
> kaxilnaik@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > >> +1 for Github actions
> > > > > > > >>
> > > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <
> ash@apache.org>
> > > > > wrote:
> > > > > > > >>
> > > > > > > >>> Happy with any thing that gives a more seamless CI
> > experience -
> > > > > > faster
> > > > > > > is
> > > > > > > >>> good too!
> > > > > > > >>>
> > > > > > > >>> -a
> > > > > > > >>>
> > > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > > >>>> +1 on GitHub Actions.
> > > > > > > >>>>
> > > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > > Jarek.Potiuk@polidea.com
> > > > > > > >
> > > > > > > >>>> wrote:
> > > > > > > >>>>
> > > > > > > >>>>> I am all for it! GitLab has been less-than helpful so far
> > and
> > > > > > > >>>> recently it
> > > > > > > >>>>> seems that running PRs from forks will only be run in
> > > > Enterrprise
> > > > > > > >>>> Edition,
> > > > > > > >>>>> which is less than welcome. I am quite a bit disappointed
> > > with
> > > > > the
> > > > > > > >>>> pace and
> > > > > > > >>>>> attitude. Github Actions seems to be much better choice -
> > > > > > especially
> > > > > > > >>>> that
> > > > > > > >>>>> they are closely integrated with Github repo and seem to
> > get
> > > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > > >>>>>
> > > > > > > >>>>> And they added self-hosted runners as well, which makes
> it
> > > > > possible
> > > > > > > >>>> for us
> > > > > > > >>>>> to optimise the experience.
> > > > > > > >>>>>
> > > > > > > >>>>> J.
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> J.
> > > > > > > >>>>>
> > > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > > >>>>> wrote:
> > > > > > > >>>>>
> > > > > > > >>>>>> Hi all,
> > > > > > > >>>>>>
> > > > > > > >>>>>> It sometime since we last discussed using other CI than
> > > > Travis.
> > > > > > One
> > > > > > > >>>> of
> > > > > > > >>>>> the
> > > > > > > >>>>>> main reasons behind considering Gitlab CI was its
> ability
> > to
> > > > > work
> > > > > > > >>>> on
> > > > > > > >>>>>> self-hosted runner. However, over time of few long weeks
> > > > Github
> > > > > > > >>>> Actions
> > > > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > > > >>>>>>
> > > > > > > >>>>>> Github Actions are still growing but using them have few
> > big
> > > > > > > >>>> advantages:
> > > > > > > >>>>>> - they are Github natives
> > > > > > > >>>>>> - forking repo and enabling actions will run CI on your
> > fork
> > > > > > > >>>>> automatically
> > > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > > >>>>>>
> > > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > > > > >>>>>> My impression is quite good. I like information about
> > steps
> > > > > > > >>>> successes at
> > > > > > > >>>>>> the PR level (no need to go to CI to check which step
> > > failed).
> > > > > The
> > > > > > > >>>> build
> > > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > > >>>>>>
> > > > > > > >>>>>> Does any of you have any experience with Github Actions?
> > Any
> > > > > > > >>>> thoughts
> > > > > > > >>>>>> about using it?
> > > > > > > >>>>>>
> > > > > > > >>>>>> Best,
> > > > > > > >>>>>> Tomek
> > > > > > > >>>>>>
> > > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > > Jarek.Potiuk@polidea.com>
> > > > > > > >>>> wrote:
> > > > > > > >>>>>>> FYI: Interesting article about the history behind
> > GitLabCI
> > > > > > > >>>> (featuring
> > > > > > > >>>>>>> Kamil, my friend).
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > > >>>> <Ja...@polidea.com>
> > > > > > > >>>>>>> wrote:
> > > > > > > >>>>>>>
> > > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can fairly
> > easily
> > > > > > > >>>> replicate
> > > > > > > >>>>>> the
> > > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it
> > > generally
> > > > > > > >>>> works, I
> > > > > > > >>>>>> can
> > > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the main
> > > Airflow
> > > > > > > >>>> project
> > > > > > > >>>>>> for a
> > > > > > > >>>>>>>> few weeks to see how it is doing (while I am no
> > holidays)
> > > > and
> > > > > > > >>>> once we
> > > > > > > >>>>>> see
> > > > > > > >>>>>>>> it running and get the support for PRs from GitLab we
> > can
> > > > > > > >>>> switch to
> > > > > > > >>>>> it.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> What do you think ? Should i call a vote or just try
> to
> > > set
> > > > it
> > > > > > > >>>> up ?
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Some details
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > > > > > > >>>> kubernetes -
> > > > > > > >>>>>>>> without the kubernetes-specific tests yet, but this
> > should
> > > > > > > >>>> be
> > > > > > > >>>>>> rather easy
> > > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > > >>>>>>>> - Working example here - you can take a look and
> compare
> > > the
> > > > > > > >>>>> UI/how
> > > > > > > >>>>>> it
> > > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > > >>>>>>>>
> > > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > > > > > > >>>> around 35
> > > > > > > >>>>>>>> minutes in total), but I plan to optimise it further.
> I
> > > can
> > > > > > > >>>> play
> > > > > > > >>>>>> with
> > > > > > > >>>>>>>> memory/cpu settings of individual workers (Got some
> > > > > > > >>>> reasonable
> > > > > > > >>>>>> values now),
> > > > > > > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for initial
> > 24) -
> > > > > > > >>>> that
> > > > > > > >>>>>> should
> > > > > > > >>>>>>>> let us build 3 builds in parallel independently from
> > each
> > > > > > > >>>> other.
> > > > > > > >>>>>>>> - I managed to get Preemptible nodes working (we have
> > > built
> > > > > > > >>>> in
> > > > > > > >>>>> retry
> > > > > > > >>>>>>>> mechanism in GitLab to work in case of system failures
> > > like
> > > > > > > >>>> that
> > > > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We
> > should
> > > be
> > > > > > > >>>> way
> > > > > > > >>>>>> below
> > > > > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > > > > >>>> calculations.
> > > > > > > >>>>>> Likely
> > > > > > > >>>>>>>> well below
> > > > > > > >>>>>>>> - The current setup does not use GCR as cache and
> Kaniko
> > > as
> > > > > > > >>>> I
> > > > > > > >>>>>>>> originally planned. GCR would require custom
> > > authentication
> > > > > > > >>>> (and
> > > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well
> > handle
> > > > > > > >>>>>> multi-staging
> > > > > > > >>>>>>>> builds (cache does not work
> > > > > > > >>>>>>>>
> > https://github.com/GoogleContainerTools/kaniko/issues/682
> > > ).
> > > > > > > >>>> I
> > > > > > > >>>>>> updated
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > > >>>>>> to
> > > > > > > >>>>>>>> reflect that.
> > > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that
> we
> > > can
> > > > > > > >>>> have
> > > > > > > >>>>>>>> reliable downloads not depending on DockerHub's
> > stability
> > > > > > > >>>> (it has
> > > > > > > >>>>>> problems
> > > > > > > >>>>>>>> sometimes)
> > > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be run in
> > any
> > > > > > > >>>>>> Kubernetes
> > > > > > > >>>>>>>> cluster (some optimisations like local volumes
> mounting
> > > for
> > > > > > > >>>> docker
> > > > > > > >>>>>> engine
> > > > > > > >>>>>>>> might have GCP-specific assumptions, but should be
> > > generally
> > > > > > > >>>>>> replicable).
> > > > > > > >>>>>>>> - You can take a look at the current source code in
> > > > > > > >>>>>>>>
> > https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > > >>>>>>>> - There will be some updates (I will get rid of custom
> > > > > > > >>>> builder
> > > > > > > >>>>>> Docker,
> > > > > > > >>>>>>>> simplify it a bit and implement kubernetes tests) -
> it's
> > > > > > > >>>> mostly
> > > > > > > >>>>> some
> > > > > > > >>>>>>>> cleanups + removal of Travis-Specific variables +
> > > gitlab.ci
> > > > > > > >>>> yaml
> > > > > > > >>>>>> with
> > > > > > > >>>>>>>> job definitions.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> J.
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > >>>>>>>> wrote:
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> So GitLab already works on automatically running
> builds
> > > > from
> > > > > > > >>>> for PRs
> > > > > > > >>>>>> :).
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > > > > > > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > > >>>>>>>>> J.
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > > >>>>>>>>> napisał:
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > > <+48660796129
> > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> --
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal
> > Software
> > > > > > > >>>> Engineer
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> > <+48660796129
> > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> --
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Jarek Potiuk
> > > > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal
> Software
> > > > > > > >>>> Engineer
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> <+48660796129
> > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> --
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> Jarek Potiuk
> > > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal
> Software
> > > > > Engineer
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> <+48660796129
> > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > > >>>>>>>
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> --
> > > > > > > >>>>>
> > > > > > > >>>>> Jarek Potiuk
> > > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > Engineer
> > > > > > > >>>>>
> > > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > > >>>>> [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/>
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > Tomasz Urbaszek
> > > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > > >
> > > > > M: +48 505 628 493 <+48505628493>
> > > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > > >
> > > > > Unique Tech
> > > > > Check out our projects! <https://www.polidea.com/our-work>
> > > >
> > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48660796129>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
> >
> > --
> >
> > Tomasz Urbaszek
> > Polidea <https://www.polidea.com/> | Junior Software Engineer
> >
> > M: +48 505 628 493 <+48505628493>
> > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >
> > Unique Tech
> > Check out our projects! <https://www.polidea.com/our-work>
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

:(

On Tue, Dec 17, 2019 at 2:35 PM Tomasz Urbaszek <to...@polidea.com>
wrote:

> I started to play with self-hosted runner and... well, encountered known
> error:
>
> https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003
>
> It seems that GA is still maturing.
>
> Bests,
> Tomek
>
> On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Yeah. All at once seems more than reasonable.
> >
> > J.
> >
> > On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com> wrote:
> >
> > > Agree with Daniel, let's do it all at once.
> > >
> > > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> > daniel.imberman@gmail.com
> > > >
> > > wrote:
> > >
> > > > I’d rather we do it all at once and not need to maintain two builds.
> > > > Most/all of our CI/CD is dockerized at this point so there shouldn’t
> > be a
> > > > huge difference.
> > > >
> > > >
> > > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > > tomasz.urbaszek@polidea.com> wrote:
> > > > Hi all,
> > > >
> > > > I have to solve a problem with our kubernetes test but for your
> > > information
> > > > I have never experienced a flaky
> > > > or timeouted build on Github Actions. Maybe I am lucky or maybe
> there's
> > > > something different.
> > > >
> > > > If we agree to move to Github Actions, would we like to migrate
> > > > incrementally or fully?
> > > >
> > > > Bests,
> > > > Tomek
> > > >
> > > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > > > wrote:
> > > >
> > > > > No problem on that side - Tomek is using the same scripts we have
> on
> > > > Travis
> > > > > (and they generally work - I think the last step is to make all the
> > > > > tests pass. We have still a number of dependencies between tests
> and
> > > some
> > > > > environmental flakiness so that some tests consistently fail in
> > Github
> > > > > Actions where they did not fail in Travis. From latest try by Tomek
> > it
> > > > > looks like we are 1 test to go (plus some cleanup/setup of project
> > and
> > > > > making sure all is stable):
> > > > >
> > > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s
> > > > (0:20:07)
> > > > > =====
> > > > >
> > > > > We discussed with Tomek and Kamil that in order to speed it up we
> > might
> > > > > want to run our own workers on the GCP account we have - just to
> test
> > > > > quickly how much we can optimise it and I am inclined to agree. If
> we
> > > do
> > > > it
> > > > > this way, the transition might be rather fast.
> > > > >
> > > > > If we want to use auto-scalable GKE cluster as we originally
> planned
> > it
> > > > > might take more time to setup (similar setup to what I tried with
> > > > GitLab).
> > > > > There we might need to use docker-in-docker to build the CI image
> > with
> > > > > latest as first step of build and then use that built image by all
> > > > > subsequent steps. But we can do it as the next step - optimising
> the
> > > > > experience.
> > > > >
> > > > > J.
> > > > >
> > > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > > daniel.imberman@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > +1 on my end as well.
> > > > > >
> > > > > > @jarek does this affect anything involving breeze? Do GitHub
> > actions
> > > > have
> > > > > > an easy docker/docker-compose based workflow?
> > > > > >
> > > > > > via Newton Mail [
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > > ]
> > > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <
> ash@apache.org
> > >
> > > > > wrote:
> > > > > > Legal: no I don't think so.
> > > > > >
> > > > > > Infra: possibly yes to get secrets in there to run things on our
> > own
> > > > > > "hardware" -
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > > <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > >
> > > > > > needs someone with Admin rights to create, and I don't see the
> > > Settings
> > > > > tab
> > > > > > at all.
> > > > > >
> > > > > > -ash
> > > > > >
> > > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com>
> > > wrote:
> > > > > > >
> > > > > > > +1 for GitHub Actions. I have been using it for months for my
> > side
> > > > > > > projects, and it’s working very well. I believe most of us are
> > > quite
> > > > > > tired
> > > > > > > of the waiting time using Travis CI.
> > > > > > >
> > > > > > > The only point I would like to remind is whether we need to
> > > > communicate
> > > > > > > with Infra/Legal team for this.
> > > > > > >
> > > > > > >
> > > > > > > XD
> > > > > > >
> > > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > >> +1 for Github actions
> > > > > > >>
> > > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org>
> > > > wrote:
> > > > > > >>
> > > > > > >>> Happy with any thing that gives a more seamless CI
> experience -
> > > > > faster
> > > > > > is
> > > > > > >>> good too!
> > > > > > >>>
> > > > > > >>> -a
> > > > > > >>>
> > > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > > > > >>> aizhamal@apache.org> wrote:
> > > > > > >>>> +1 on GitHub Actions.
> > > > > > >>>>
> > > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > > Jarek.Potiuk@polidea.com
> > > > > > >
> > > > > > >>>> wrote:
> > > > > > >>>>
> > > > > > >>>>> I am all for it! GitLab has been less-than helpful so far
> and
> > > > > > >>>> recently it
> > > > > > >>>>> seems that running PRs from forks will only be run in
> > > Enterrprise
> > > > > > >>>> Edition,
> > > > > > >>>>> which is less than welcome. I am quite a bit disappointed
> > with
> > > > the
> > > > > > >>>> pace and
> > > > > > >>>>> attitude. Github Actions seems to be much better choice -
> > > > > especially
> > > > > > >>>> that
> > > > > > >>>>> they are closely integrated with Github repo and seem to
> get
> > > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > > >>>>>
> > > > > > >>>>> And they added self-hosted runners as well, which makes it
> > > > possible
> > > > > > >>>> for us
> > > > > > >>>>> to optimise the experience.
> > > > > > >>>>>
> > > > > > >>>>> J.
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> J.
> > > > > > >>>>>
> > > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > > >>>>> wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Hi all,
> > > > > > >>>>>>
> > > > > > >>>>>> It sometime since we last discussed using other CI than
> > > Travis.
> > > > > One
> > > > > > >>>> of
> > > > > > >>>>> the
> > > > > > >>>>>> main reasons behind considering Gitlab CI was its ability
> to
> > > > work
> > > > > > >>>> on
> > > > > > >>>>>> self-hosted runner. However, over time of few long weeks
> > > Github
> > > > > > >>>> Actions
> > > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > > >>>>>>
> > > > > > >>>>>> Github Actions are still growing but using them have few
> big
> > > > > > >>>> advantages:
> > > > > > >>>>>> - they are Github natives
> > > > > > >>>>>> - forking repo and enabling actions will run CI on your
> fork
> > > > > > >>>>> automatically
> > > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > > >>>>>>
> > > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > > > >>>>>> My impression is quite good. I like information about
> steps
> > > > > > >>>> successes at
> > > > > > >>>>>> the PR level (no need to go to CI to check which step
> > failed).
> > > > The
> > > > > > >>>> build
> > > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > > >>>>>>
> > > > > > >>>>>> Does any of you have any experience with Github Actions?
> Any
> > > > > > >>>> thoughts
> > > > > > >>>>>> about using it?
> > > > > > >>>>>>
> > > > > > >>>>>> Best,
> > > > > > >>>>>> Tomek
> > > > > > >>>>>>
> > > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > > Jarek.Potiuk@polidea.com>
> > > > > > >>>> wrote:
> > > > > > >>>>>>> FYI: Interesting article about the history behind
> GitLabCI
> > > > > > >>>> (featuring
> > > > > > >>>>>>> Kamil, my friend).
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > > >>>>>>>
> > > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > > >>>> <Ja...@polidea.com>
> > > > > > >>>>>>> wrote:
> > > > > > >>>>>>>
> > > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> TL;DR; I think the POC has shown that we can fairly
> easily
> > > > > > >>>> replicate
> > > > > > >>>>>> the
> > > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it
> > generally
> > > > > > >>>> works, I
> > > > > > >>>>>> can
> > > > > > >>>>>>>> plug it in for master/v1-10-test builds in the main
> > Airflow
> > > > > > >>>> project
> > > > > > >>>>>> for a
> > > > > > >>>>>>>> few weeks to see how it is doing (while I am no
> holidays)
> > > and
> > > > > > >>>> once we
> > > > > > >>>>>> see
> > > > > > >>>>>>>> it running and get the support for PRs from GitLab we
> can
> > > > > > >>>> switch to
> > > > > > >>>>> it.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> What do you think ? Should i call a vote or just try to
> > set
> > > it
> > > > > > >>>> up ?
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Some details
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > > > > > >>>> kubernetes -
> > > > > > >>>>>>>> without the kubernetes-specific tests yet, but this
> should
> > > > > > >>>> be
> > > > > > >>>>>> rather easy
> > > > > > >>>>>>>> with kind (looking at it next):
> > > > > > >>>>>>>> - Working example here - you can take a look and compare
> > the
> > > > > > >>>>> UI/how
> > > > > > >>>>>> it
> > > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > > >>>>>>>>
> > https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > > > > > >>>> around 35
> > > > > > >>>>>>>> minutes in total), but I plan to optimise it further. I
> > can
> > > > > > >>>> play
> > > > > > >>>>>> with
> > > > > > >>>>>>>> memory/cpu settings of individual workers (Got some
> > > > > > >>>> reasonable
> > > > > > >>>>>> values now),
> > > > > > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for initial
> 24) -
> > > > > > >>>> that
> > > > > > >>>>>> should
> > > > > > >>>>>>>> let us build 3 builds in parallel independently from
> each
> > > > > > >>>> other.
> > > > > > >>>>>>>> - I managed to get Preemptible nodes working (we have
> > built
> > > > > > >>>> in
> > > > > > >>>>> retry
> > > > > > >>>>>>>> mechanism in GitLab to work in case of system failures
> > like
> > > > > > >>>> that
> > > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We
> should
> > be
> > > > > > >>>> way
> > > > > > >>>>>> below
> > > > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > > > >>>> calculations.
> > > > > > >>>>>> Likely
> > > > > > >>>>>>>> well below
> > > > > > >>>>>>>> - The current setup does not use GCR as cache and Kaniko
> > as
> > > > > > >>>> I
> > > > > > >>>>>>>> originally planned. GCR would require custom
> > authentication
> > > > > > >>>> (and
> > > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well
> handle
> > > > > > >>>>>> multi-staging
> > > > > > >>>>>>>> builds (cache does not work
> > > > > > >>>>>>>>
> https://github.com/GoogleContainerTools/kaniko/issues/682
> > ).
> > > > > > >>>> I
> > > > > > >>>>>> updated
> > > > > > >>>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > > >>>>>> to
> > > > > > >>>>>>>> reflect that.
> > > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we
> > can
> > > > > > >>>> have
> > > > > > >>>>>>>> reliable downloads not depending on DockerHub's
> stability
> > > > > > >>>> (it has
> > > > > > >>>>>> problems
> > > > > > >>>>>>>> sometimes)
> > > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be run in
> any
> > > > > > >>>>>> Kubernetes
> > > > > > >>>>>>>> cluster (some optimisations like local volumes mounting
> > for
> > > > > > >>>> docker
> > > > > > >>>>>> engine
> > > > > > >>>>>>>> might have GCP-specific assumptions, but should be
> > generally
> > > > > > >>>>>> replicable).
> > > > > > >>>>>>>> - You can take a look at the current source code in
> > > > > > >>>>>>>>
> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > > >>>>>>>> - There will be some updates (I will get rid of custom
> > > > > > >>>> builder
> > > > > > >>>>>> Docker,
> > > > > > >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> > > > > > >>>> mostly
> > > > > > >>>>> some
> > > > > > >>>>>>>> cleanups + removal of Travis-Specific variables +
> > gitlab.ci
> > > > > > >>>> yaml
> > > > > > >>>>>> with
> > > > > > >>>>>>>> job definitions.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> J.
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > >>>>>>>> wrote:
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> So GitLab already works on automatically running builds
> > > from
> > > > > > >>>> for PRs
> > > > > > >>>>>> :).
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > > > > > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > > >>>>>>>>> J.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Principal Software Engineer
> > > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > > >>>>>>>>> napisał:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> > <+48660796129
> > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> --
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> Jarek Potiuk
> > > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal
> Software
> > > > > > >>>> Engineer
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129>
> <+48660796129
> > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> --
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Jarek Potiuk
> > > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > > > >>>> Engineer
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>
> > > > > > >>>>>>> --
> > > > > > >>>>>>>
> > > > > > >>>>>>> Jarek Potiuk
> > > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > Engineer
> > > > > > >>>>>>>
> > > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > > >>>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>>> --
> > > > > > >>>>>
> > > > > > >>>>> Jarek Potiuk
> > > > > > >>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > Engineer
> > > > > > >>>>>
> > > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > > >>>>> <+48%20660%20796%20129>>
> > > > > > >>>>> [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/>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Tomasz Urbaszek
> > > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > > >
> > > > M: +48 505 628 493 <+48505628493>
> > > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > > >
> > > > Unique Tech
> > > > Check out our projects! <https://www.polidea.com/our-work>
> > >
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >
>
>
> --
>
> Tomasz Urbaszek
> Polidea <https://www.polidea.com/> | Junior Software Engineer
>
> M: +48 505 628 493 <+48505628493>
> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <to...@polidea.com>]

I started to play with self-hosted runner and... well, encountered known
error:
https://github.community/t5/GitHub-Actions/Github-action-stuck-at-queue/td-p/38003

It seems that GA is still maturing.

Bests,
Tomek

On Fri, Dec 13, 2019 at 5:06 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> Yeah. All at once seems more than reasonable.
>
> J.
>
> On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> > Agree with Daniel, let's do it all at once.
> >
> > On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <
> daniel.imberman@gmail.com
> > >
> > wrote:
> >
> > > I’d rather we do it all at once and not need to maintain two builds.
> > > Most/all of our CI/CD is dockerized at this point so there shouldn’t
> be a
> > > huge difference.
> > >
> > >
> > > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > > tomasz.urbaszek@polidea.com> wrote:
> > > Hi all,
> > >
> > > I have to solve a problem with our kubernetes test but for your
> > information
> > > I have never experienced a flaky
> > > or timeouted build on Github Actions. Maybe I am lucky or maybe there's
> > > something different.
> > >
> > > If we agree to move to Github Actions, would we like to migrate
> > > incrementally or fully?
> > >
> > > Bests,
> > > Tomek
> > >
> > > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > wrote:
> > >
> > > > No problem on that side - Tomek is using the same scripts we have on
> > > Travis
> > > > (and they generally work - I think the last step is to make all the
> > > > tests pass. We have still a number of dependencies between tests and
> > some
> > > > environmental flakiness so that some tests consistently fail in
> Github
> > > > Actions where they did not fail in Travis. From latest try by Tomek
> it
> > > > looks like we are 1 test to go (plus some cleanup/setup of project
> and
> > > > making sure all is stable):
> > > >
> > > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s
> > > (0:20:07)
> > > > =====
> > > >
> > > > We discussed with Tomek and Kamil that in order to speed it up we
> might
> > > > want to run our own workers on the GCP account we have - just to test
> > > > quickly how much we can optimise it and I am inclined to agree. If we
> > do
> > > it
> > > > this way, the transition might be rather fast.
> > > >
> > > > If we want to use auto-scalable GKE cluster as we originally planned
> it
> > > > might take more time to setup (similar setup to what I tried with
> > > GitLab).
> > > > There we might need to use docker-in-docker to build the CI image
> with
> > > > latest as first step of build and then use that built image by all
> > > > subsequent steps. But we can do it as the next step - optimising the
> > > > experience.
> > > >
> > > > J.
> > > >
> > > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > > daniel.imberman@gmail.com>
> > > > wrote:
> > > >
> > > > > +1 on my end as well.
> > > > >
> > > > > @jarek does this affect anything involving breeze? Do GitHub
> actions
> > > have
> > > > > an easy docker/docker-compose based workflow?
> > > > >
> > > > > via Newton Mail [
> > > > >
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > > ]
> > > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <ash@apache.org
> >
> > > > wrote:
> > > > > Legal: no I don't think so.
> > > > >
> > > > > Infra: possibly yes to get secrets in there to run things on our
> own
> > > > > "hardware" -
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > > <
> > > > >
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > >
> > > > > needs someone with Admin rights to create, and I don't see the
> > Settings
> > > > tab
> > > > > at all.
> > > > >
> > > > > -ash
> > > > >
> > > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com>
> > wrote:
> > > > > >
> > > > > > +1 for GitHub Actions. I have been using it for months for my
> side
> > > > > > projects, and it’s working very well. I believe most of us are
> > quite
> > > > > tired
> > > > > > of the waiting time using Travis CI.
> > > > > >
> > > > > > The only point I would like to remind is whether we need to
> > > communicate
> > > > > > with Infra/Legal team for this.
> > > > > >
> > > > > >
> > > > > > XD
> > > > > >
> > > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com>
> > > wrote:
> > > > > >
> > > > > >> +1 for Github actions
> > > > > >>
> > > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org>
> > > wrote:
> > > > > >>
> > > > > >>> Happy with any thing that gives a more seamless CI experience -
> > > > faster
> > > > > is
> > > > > >>> good too!
> > > > > >>>
> > > > > >>> -a
> > > > > >>>
> > > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > > > >>> aizhamal@apache.org> wrote:
> > > > > >>>> +1 on GitHub Actions.
> > > > > >>>>
> > > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > > Jarek.Potiuk@polidea.com
> > > > > >
> > > > > >>>> wrote:
> > > > > >>>>
> > > > > >>>>> I am all for it! GitLab has been less-than helpful so far and
> > > > > >>>> recently it
> > > > > >>>>> seems that running PRs from forks will only be run in
> > Enterrprise
> > > > > >>>> Edition,
> > > > > >>>>> which is less than welcome. I am quite a bit disappointed
> with
> > > the
> > > > > >>>> pace and
> > > > > >>>>> attitude. Github Actions seems to be much better choice -
> > > > especially
> > > > > >>>> that
> > > > > >>>>> they are closely integrated with Github repo and seem to get
> > > > > >>>>> attention/focus from Github/Microsoft.
> > > > > >>>>>
> > > > > >>>>> And they added self-hosted runners as well, which makes it
> > > possible
> > > > > >>>> for us
> > > > > >>>>> to optimise the experience.
> > > > > >>>>>
> > > > > >>>>> J.
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> J.
> > > > > >>>>>
> > > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > > >>>>> wrote:
> > > > > >>>>>
> > > > > >>>>>> Hi all,
> > > > > >>>>>>
> > > > > >>>>>> It sometime since we last discussed using other CI than
> > Travis.
> > > > One
> > > > > >>>> of
> > > > > >>>>> the
> > > > > >>>>>> main reasons behind considering Gitlab CI was its ability to
> > > work
> > > > > >>>> on
> > > > > >>>>>> self-hosted runner. However, over time of few long weeks
> > Github
> > > > > >>>> Actions
> > > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > > >>>>>>
> > > > > >>>>>> Github Actions are still growing but using them have few big
> > > > > >>>> advantages:
> > > > > >>>>>> - they are Github natives
> > > > > >>>>>> - forking repo and enabling actions will run CI on your fork
> > > > > >>>>> automatically
> > > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > > >>>>>>
> > > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > > >>>>>> My impression is quite good. I like information about steps
> > > > > >>>> successes at
> > > > > >>>>>> the PR level (no need to go to CI to check which step
> failed).
> > > The
> > > > > >>>> build
> > > > > >>>>>> log view is a little bit clumsy but it works.
> > > > > >>>>>>
> > > > > >>>>>> Does any of you have any experience with Github Actions? Any
> > > > > >>>> thoughts
> > > > > >>>>>> about using it?
> > > > > >>>>>>
> > > > > >>>>>> Best,
> > > > > >>>>>> Tomek
> > > > > >>>>>>
> > > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> > Jarek.Potiuk@polidea.com>
> > > > > >>>> wrote:
> > > > > >>>>>>> FYI: Interesting article about the history behind GitLabCI
> > > > > >>>> (featuring
> > > > > >>>>>>> Kamil, my friend).
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > > >>>>>>>
> > > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > > >>>> <Ja...@polidea.com>
> > > > > >>>>>>> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > > >>>>>>>>
> > > > > >>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
> > > > > >>>> replicate
> > > > > >>>>>> the
> > > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it
> generally
> > > > > >>>> works, I
> > > > > >>>>>> can
> > > > > >>>>>>>> plug it in for master/v1-10-test builds in the main
> Airflow
> > > > > >>>> project
> > > > > >>>>>> for a
> > > > > >>>>>>>> few weeks to see how it is doing (while I am no holidays)
> > and
> > > > > >>>> once we
> > > > > >>>>>> see
> > > > > >>>>>>>> it running and get the support for PRs from GitLab we can
> > > > > >>>> switch to
> > > > > >>>>> it.
> > > > > >>>>>>>>
> > > > > >>>>>>>> What do you think ? Should i call a vote or just try to
> set
> > it
> > > > > >>>> up ?
> > > > > >>>>>>>>
> > > > > >>>>>>>> Some details
> > > > > >>>>>>>>
> > > > > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > > > > >>>> kubernetes -
> > > > > >>>>>>>> without the kubernetes-specific tests yet, but this should
> > > > > >>>> be
> > > > > >>>>>> rather easy
> > > > > >>>>>>>> with kind (looking at it next):
> > > > > >>>>>>>> - Working example here - you can take a look and compare
> the
> > > > > >>>>> UI/how
> > > > > >>>>>> it
> > > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > > >>>>>>>>
> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > > > > >>>> around 35
> > > > > >>>>>>>> minutes in total), but I plan to optimise it further. I
> can
> > > > > >>>> play
> > > > > >>>>>> with
> > > > > >>>>>>>> memory/cpu settings of individual workers (Got some
> > > > > >>>> reasonable
> > > > > >>>>>> values now),
> > > > > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > > > > >>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
> > > > > >>>> that
> > > > > >>>>>> should
> > > > > >>>>>>>> let us build 3 builds in parallel independently from each
> > > > > >>>> other.
> > > > > >>>>>>>> - I managed to get Preemptible nodes working (we have
> built
> > > > > >>>> in
> > > > > >>>>> retry
> > > > > >>>>>>>> mechanism in GitLab to work in case of system failures
> like
> > > > > >>>> that
> > > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We should
> be
> > > > > >>>> way
> > > > > >>>>>> below
> > > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > > >>>> calculations.
> > > > > >>>>>> Likely
> > > > > >>>>>>>> well below
> > > > > >>>>>>>> - The current setup does not use GCR as cache and Kaniko
> as
> > > > > >>>> I
> > > > > >>>>>>>> originally planned. GCR would require custom
> authentication
> > > > > >>>> (and
> > > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
> > > > > >>>>>> multi-staging
> > > > > >>>>>>>> builds (cache does not work
> > > > > >>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682
> ).
> > > > > >>>> I
> > > > > >>>>>> updated
> > > > > >>>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > > >>>>>> to
> > > > > >>>>>>>> reflect that.
> > > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we
> can
> > > > > >>>> have
> > > > > >>>>>>>> reliable downloads not depending on DockerHub's stability
> > > > > >>>> (it has
> > > > > >>>>>> problems
> > > > > >>>>>>>> sometimes)
> > > > > >>>>>>>> - All in-all, it's GCP-independent. It could be run in any
> > > > > >>>>>> Kubernetes
> > > > > >>>>>>>> cluster (some optimisations like local volumes mounting
> for
> > > > > >>>> docker
> > > > > >>>>>> engine
> > > > > >>>>>>>> might have GCP-specific assumptions, but should be
> generally
> > > > > >>>>>> replicable).
> > > > > >>>>>>>> - You can take a look at the current source code in
> > > > > >>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > > >>>>>>>> - There will be some updates (I will get rid of custom
> > > > > >>>> builder
> > > > > >>>>>> Docker,
> > > > > >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> > > > > >>>> mostly
> > > > > >>>>> some
> > > > > >>>>>>>> cleanups + removal of Travis-Specific variables +
> gitlab.ci
> > > > > >>>> yaml
> > > > > >>>>>> with
> > > > > >>>>>>>> job definitions.
> > > > > >>>>>>>>
> > > > > >>>>>>>> J.
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > >>>>>>>> wrote:
> > > > > >>>>>>>>
> > > > > >>>>>>>>> So GitLab already works on automatically running builds
> > from
> > > > > >>>> for PRs
> > > > > >>>>>> :).
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > > > > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > > >>>>>>>>> J.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Principal Software Engineer
> > > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > > >>>>>>>>> napisał:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129>
> <+48660796129
> > > > > >>>>> <+48%20660%20796%20129>>
> > > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> --
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> Jarek Potiuk
> > > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > > >>>> Engineer
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > >>>>> <+48%20660%20796%20129>>
> > > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> --
> > > > > >>>>>>>>
> > > > > >>>>>>>> Jarek Potiuk
> > > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > > >>>> Engineer
> > > > > >>>>>>>>
> > > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > >>>>> <+48%20660%20796%20129>>
> > > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>>> --
> > > > > >>>>>>>
> > > > > >>>>>>> Jarek Potiuk
> > > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > Engineer
> > > > > >>>>>>>
> > > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > >>>>> <+48%20660%20796%20129>>
> > > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > > >>>>>>>
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> --
> > > > > >>>>>
> > > > > >>>>> Jarek Potiuk
> > > > > >>>>> Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > > >>>>>
> > > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > > >>>>> <+48%20660%20796%20129>>
> > > > > >>>>> [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/>
> > > >
> > >
> > >
> > > --
> > >
> > > Tomasz Urbaszek
> > > Polidea <https://www.polidea.com/> | Junior Software Engineer
> > >
> > > M: +48 505 628 493 <+48505628493>
> > > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> > >
> > > Unique Tech
> > > Check out our projects! <https://www.polidea.com/our-work>
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>


-- 

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Junior Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

Yeah. All at once seems more than reasonable.

J.

On Fri, Dec 13, 2019 at 4:50 PM Kaxil Naik <ka...@gmail.com> wrote:

> Agree with Daniel, let's do it all at once.
>
> On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <daniel.imberman@gmail.com
> >
> wrote:
>
> > I’d rather we do it all at once and not need to maintain two builds.
> > Most/all of our CI/CD is dockerized at this point so there shouldn’t be a
> > huge difference.
> >
> >
> > On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> > tomasz.urbaszek@polidea.com> wrote:
> > Hi all,
> >
> > I have to solve a problem with our kubernetes test but for your
> information
> > I have never experienced a flaky
> > or timeouted build on Github Actions. Maybe I am lucky or maybe there's
> > something different.
> >
> > If we agree to move to Github Actions, would we like to migrate
> > incrementally or fully?
> >
> > Bests,
> > Tomek
> >
> > On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > No problem on that side - Tomek is using the same scripts we have on
> > Travis
> > > (and they generally work - I think the last step is to make all the
> > > tests pass. We have still a number of dependencies between tests and
> some
> > > environmental flakiness so that some tests consistently fail in Github
> > > Actions where they did not fail in Travis. From latest try by Tomek it
> > > looks like we are 1 test to go (plus some cleanup/setup of project and
> > > making sure all is stable):
> > >
> > > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s
> > (0:20:07)
> > > =====
> > >
> > > We discussed with Tomek and Kamil that in order to speed it up we might
> > > want to run our own workers on the GCP account we have - just to test
> > > quickly how much we can optimise it and I am inclined to agree. If we
> do
> > it
> > > this way, the transition might be rather fast.
> > >
> > > If we want to use auto-scalable GKE cluster as we originally planned it
> > > might take more time to setup (similar setup to what I tried with
> > GitLab).
> > > There we might need to use docker-in-docker to build the CI image with
> > > latest as first step of build and then use that built image by all
> > > subsequent steps. But we can do it as the next step - optimising the
> > > experience.
> > >
> > > J.
> > >
> > > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > > daniel.imberman@gmail.com>
> > > wrote:
> > >
> > > > +1 on my end as well.
> > > >
> > > > @jarek does this affect anything involving breeze? Do GitHub actions
> > have
> > > > an easy docker/docker-compose based workflow?
> > > >
> > > > via Newton Mail [
> > > >
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > > ]
> > > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <as...@apache.org>
> > > wrote:
> > > > Legal: no I don't think so.
> > > >
> > > > Infra: possibly yes to get secrets in there to run things on our own
> > > > "hardware" -
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > > <
> > > >
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > >
> > > > needs someone with Admin rights to create, and I don't see the
> Settings
> > > tab
> > > > at all.
> > > >
> > > > -ash
> > > >
> > > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com>
> wrote:
> > > > >
> > > > > +1 for GitHub Actions. I have been using it for months for my side
> > > > > projects, and it’s working very well. I believe most of us are
> quite
> > > > tired
> > > > > of the waiting time using Travis CI.
> > > > >
> > > > > The only point I would like to remind is whether we need to
> > communicate
> > > > > with Infra/Legal team for this.
> > > > >
> > > > >
> > > > > XD
> > > > >
> > > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com>
> > wrote:
> > > > >
> > > > >> +1 for Github actions
> > > > >>
> > > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org>
> > wrote:
> > > > >>
> > > > >>> Happy with any thing that gives a more seamless CI experience -
> > > faster
> > > > is
> > > > >>> good too!
> > > > >>>
> > > > >>> -a
> > > > >>>
> > > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > > >>> aizhamal@apache.org> wrote:
> > > > >>>> +1 on GitHub Actions.
> > > > >>>>
> > > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > > Jarek.Potiuk@polidea.com
> > > > >
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> I am all for it! GitLab has been less-than helpful so far and
> > > > >>>> recently it
> > > > >>>>> seems that running PRs from forks will only be run in
> Enterrprise
> > > > >>>> Edition,
> > > > >>>>> which is less than welcome. I am quite a bit disappointed with
> > the
> > > > >>>> pace and
> > > > >>>>> attitude. Github Actions seems to be much better choice -
> > > especially
> > > > >>>> that
> > > > >>>>> they are closely integrated with Github repo and seem to get
> > > > >>>>> attention/focus from Github/Microsoft.
> > > > >>>>>
> > > > >>>>> And they added self-hosted runners as well, which makes it
> > possible
> > > > >>>> for us
> > > > >>>>> to optimise the experience.
> > > > >>>>>
> > > > >>>>> J.
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> J.
> > > > >>>>>
> > > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > > >>>>> tomasz.urbaszek@polidea.com>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>>> Hi all,
> > > > >>>>>>
> > > > >>>>>> It sometime since we last discussed using other CI than
> Travis.
> > > One
> > > > >>>> of
> > > > >>>>> the
> > > > >>>>>> main reasons behind considering Gitlab CI was its ability to
> > work
> > > > >>>> on
> > > > >>>>>> self-hosted runner. However, over time of few long weeks
> Github
> > > > >>>> Actions
> > > > >>>>>> matured enough to allow using self-hosted runners!
> > > > >>>>>>
> > > > >>>>>> Github Actions are still growing but using them have few big
> > > > >>>> advantages:
> > > > >>>>>> - they are Github natives
> > > > >>>>>> - forking repo and enabling actions will run CI on your fork
> > > > >>>>> automatically
> > > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > > >>>>>>
> > > > >>>>>> I put together a PoC of CI in our internal repo:
> > > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > > >>>>>> My impression is quite good. I like information about steps
> > > > >>>> successes at
> > > > >>>>>> the PR level (no need to go to CI to check which step failed).
> > The
> > > > >>>> build
> > > > >>>>>> log view is a little bit clumsy but it works.
> > > > >>>>>>
> > > > >>>>>> Does any of you have any experience with Github Actions? Any
> > > > >>>> thoughts
> > > > >>>>>> about using it?
> > > > >>>>>>
> > > > >>>>>> Best,
> > > > >>>>>> Tomek
> > > > >>>>>>
> > > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > > > >>>> wrote:
> > > > >>>>>>> FYI: Interesting article about the history behind GitLabCI
> > > > >>>> (featuring
> > > > >>>>>>> Kamil, my friend).
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > > >>>>>>>
> > > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > > >>>> <Ja...@polidea.com>
> > > > >>>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> Some update on my GitLab experiences so far:
> > > > >>>>>>>>
> > > > >>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
> > > > >>>> replicate
> > > > >>>>>> the
> > > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
> > > > >>>> works, I
> > > > >>>>>> can
> > > > >>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
> > > > >>>> project
> > > > >>>>>> for a
> > > > >>>>>>>> few weeks to see how it is doing (while I am no holidays)
> and
> > > > >>>> once we
> > > > >>>>>> see
> > > > >>>>>>>> it running and get the support for PRs from GitLab we can
> > > > >>>> switch to
> > > > >>>>> it.
> > > > >>>>>>>>
> > > > >>>>>>>> What do you think ? Should i call a vote or just try to set
> it
> > > > >>>> up ?
> > > > >>>>>>>>
> > > > >>>>>>>> Some details
> > > > >>>>>>>>
> > > > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > > > >>>> kubernetes -
> > > > >>>>>>>> without the kubernetes-specific tests yet, but this should
> > > > >>>> be
> > > > >>>>>> rather easy
> > > > >>>>>>>> with kind (looking at it next):
> > > > >>>>>>>> - Working example here - you can take a look and compare the
> > > > >>>>> UI/how
> > > > >>>>>> it
> > > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > > >>>>>>>> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > > > >>>> around 35
> > > > >>>>>>>> minutes in total), but I plan to optimise it further. I can
> > > > >>>> play
> > > > >>>>>> with
> > > > >>>>>>>> memory/cpu settings of individual workers (Got some
> > > > >>>> reasonable
> > > > >>>>>> values now),
> > > > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > > > >>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
> > > > >>>> that
> > > > >>>>>> should
> > > > >>>>>>>> let us build 3 builds in parallel independently from each
> > > > >>>> other.
> > > > >>>>>>>> - I managed to get Preemptible nodes working (we have built
> > > > >>>> in
> > > > >>>>> retry
> > > > >>>>>>>> mechanism in GitLab to work in case of system failures like
> > > > >>>> that
> > > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We should be
> > > > >>>> way
> > > > >>>>>> below
> > > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > > >>>> calculations.
> > > > >>>>>> Likely
> > > > >>>>>>>> well below
> > > > >>>>>>>> - The current setup does not use GCR as cache and Kaniko as
> > > > >>>> I
> > > > >>>>>>>> originally planned. GCR would require custom authentication
> > > > >>>> (and
> > > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
> > > > >>>>>> multi-staging
> > > > >>>>>>>> builds (cache does not work
> > > > >>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682).
> > > > >>>> I
> > > > >>>>>> updated
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > > >>>>>> to
> > > > >>>>>>>> reflect that.
> > > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we can
> > > > >>>> have
> > > > >>>>>>>> reliable downloads not depending on DockerHub's stability
> > > > >>>> (it has
> > > > >>>>>> problems
> > > > >>>>>>>> sometimes)
> > > > >>>>>>>> - All in-all, it's GCP-independent. It could be run in any
> > > > >>>>>> Kubernetes
> > > > >>>>>>>> cluster (some optimisations like local volumes mounting for
> > > > >>>> docker
> > > > >>>>>> engine
> > > > >>>>>>>> might have GCP-specific assumptions, but should be generally
> > > > >>>>>> replicable).
> > > > >>>>>>>> - You can take a look at the current source code in
> > > > >>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > > >>>>>>>> - There will be some updates (I will get rid of custom
> > > > >>>> builder
> > > > >>>>>> Docker,
> > > > >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> > > > >>>> mostly
> > > > >>>>> some
> > > > >>>>>>>> cleanups + removal of Travis-Specific variables + gitlab.ci
> > > > >>>> yaml
> > > > >>>>>> with
> > > > >>>>>>>> job definitions.
> > > > >>>>>>>>
> > > > >>>>>>>> J.
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> So GitLab already works on automatically running builds
> from
> > > > >>>> for PRs
> > > > >>>>>> :).
> > > > >>>>>>>>>
> > > > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > > > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > > >>>>>>>>> J.
> > > > >>>>>>>>>
> > > > >>>>>>>>> Principal Software Engineer
> > > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > > >>>>>>>>>
> > > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > > >>>>>> Jarek.Potiuk@polidea.com>
> > > > >>>>>>>>> napisał:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > > > >>>>> <+48%20660%20796%20129>>
> > > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> --
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Jarek Potiuk
> > > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > >>>> Engineer
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > >>>>> <+48%20660%20796%20129>>
> > > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> --
> > > > >>>>>>>>
> > > > >>>>>>>> Jarek Potiuk
> > > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > > >>>> Engineer
> > > > >>>>>>>>
> > > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > >>>>> <+48%20660%20796%20129>>
> > > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>>> --
> > > > >>>>>>>
> > > > >>>>>>> Jarek Potiuk
> > > > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > Engineer
> > > > >>>>>>>
> > > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > >>>>> <+48%20660%20796%20129>>
> > > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > > >>>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> --
> > > > >>>>>
> > > > >>>>> Jarek Potiuk
> > > > >>>>> Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > > >>>>>
> > > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > > >>>>> <+48%20660%20796%20129>>
> > > > >>>>> [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/>
> > >
> >
> >
> > --
> >
> > Tomasz Urbaszek
> > Polidea <https://www.polidea.com/> | Junior Software Engineer
> >
> > M: +48 505 628 493 <+48505628493>
> > E: tomasz.urbaszek@polidea.com <to...@polidea.com>
> >
> > Unique Tech
> > Check out our projects! <https://www.polidea.com/our-work>
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kaxil Naik <ka...@gmail.com>]

Agree with Daniel, let's do it all at once.

On Fri, Dec 13, 2019 at 3:49 PM Daniel Imberman <da...@gmail.com>
wrote:

> I’d rather we do it all at once and not need to maintain two builds.
> Most/all of our CI/CD is dockerized at this point so there shouldn’t be a
> huge difference.
>
>
> On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com> wrote:
> Hi all,
>
> I have to solve a problem with our kubernetes test but for your information
> I have never experienced a flaky
> or timeouted build on Github Actions. Maybe I am lucky or maybe there's
> something different.
>
> If we agree to move to Github Actions, would we like to migrate
> incrementally or fully?
>
> Bests,
> Tomek
>
> On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > No problem on that side - Tomek is using the same scripts we have on
> Travis
> > (and they generally work - I think the last step is to make all the
> > tests pass. We have still a number of dependencies between tests and some
> > environmental flakiness so that some tests consistently fail in Github
> > Actions where they did not fail in Travis. From latest try by Tomek it
> > looks like we are 1 test to go (plus some cleanup/setup of project and
> > making sure all is stable):
> >
> > ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s
> (0:20:07)
> > =====
> >
> > We discussed with Tomek and Kamil that in order to speed it up we might
> > want to run our own workers on the GCP account we have - just to test
> > quickly how much we can optimise it and I am inclined to agree. If we do
> it
> > this way, the transition might be rather fast.
> >
> > If we want to use auto-scalable GKE cluster as we originally planned it
> > might take more time to setup (similar setup to what I tried with
> GitLab).
> > There we might need to use docker-in-docker to build the CI image with
> > latest as first step of build and then use that built image by all
> > subsequent steps. But we can do it as the next step - optimising the
> > experience.
> >
> > J.
> >
> > On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> > daniel.imberman@gmail.com>
> > wrote:
> >
> > > +1 on my end as well.
> > >
> > > @jarek does this affect anything involving breeze? Do GitHub actions
> have
> > > an easy docker/docker-compose based workflow?
> > >
> > > via Newton Mail [
> > >
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > > ]
> > > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <as...@apache.org>
> > wrote:
> > > Legal: no I don't think so.
> > >
> > > Infra: possibly yes to get secrets in there to run things on our own
> > > "hardware" -
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > > <
> > >
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > >
> > > needs someone with Admin rights to create, and I don't see the Settings
> > tab
> > > at all.
> > >
> > > -ash
> > >
> > > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com> wrote:
> > > >
> > > > +1 for GitHub Actions. I have been using it for months for my side
> > > > projects, and it’s working very well. I believe most of us are quite
> > > tired
> > > > of the waiting time using Travis CI.
> > > >
> > > > The only point I would like to remind is whether we need to
> communicate
> > > > with Infra/Legal team for this.
> > > >
> > > >
> > > > XD
> > > >
> > > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com>
> wrote:
> > > >
> > > >> +1 for Github actions
> > > >>
> > > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org>
> wrote:
> > > >>
> > > >>> Happy with any thing that gives a more seamless CI experience -
> > faster
> > > is
> > > >>> good too!
> > > >>>
> > > >>> -a
> > > >>>
> > > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > >>> aizhamal@apache.org> wrote:
> > > >>>> +1 on GitHub Actions.
> > > >>>>
> > > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> > Jarek.Potiuk@polidea.com
> > > >
> > > >>>> wrote:
> > > >>>>
> > > >>>>> I am all for it! GitLab has been less-than helpful so far and
> > > >>>> recently it
> > > >>>>> seems that running PRs from forks will only be run in Enterrprise
> > > >>>> Edition,
> > > >>>>> which is less than welcome. I am quite a bit disappointed with
> the
> > > >>>> pace and
> > > >>>>> attitude. Github Actions seems to be much better choice -
> > especially
> > > >>>> that
> > > >>>>> they are closely integrated with Github repo and seem to get
> > > >>>>> attention/focus from Github/Microsoft.
> > > >>>>>
> > > >>>>> And they added self-hosted runners as well, which makes it
> possible
> > > >>>> for us
> > > >>>>> to optimise the experience.
> > > >>>>>
> > > >>>>> J.
> > > >>>>>
> > > >>>>>
> > > >>>>> J.
> > > >>>>>
> > > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > >>>>> tomasz.urbaszek@polidea.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hi all,
> > > >>>>>>
> > > >>>>>> It sometime since we last discussed using other CI than Travis.
> > One
> > > >>>> of
> > > >>>>> the
> > > >>>>>> main reasons behind considering Gitlab CI was its ability to
> work
> > > >>>> on
> > > >>>>>> self-hosted runner. However, over time of few long weeks Github
> > > >>>> Actions
> > > >>>>>> matured enough to allow using self-hosted runners!
> > > >>>>>>
> > > >>>>>> Github Actions are still growing but using them have few big
> > > >>>> advantages:
> > > >>>>>> - they are Github natives
> > > >>>>>> - forking repo and enabling actions will run CI on your fork
> > > >>>>> automatically
> > > >>>>>> - variety of actions (PR checks, greetings, etc)
> > > >>>>>>
> > > >>>>>> I put together a PoC of CI in our internal repo:
> > > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > > >>>>>> My impression is quite good. I like information about steps
> > > >>>> successes at
> > > >>>>>> the PR level (no need to go to CI to check which step failed).
> The
> > > >>>> build
> > > >>>>>> log view is a little bit clumsy but it works.
> > > >>>>>>
> > > >>>>>> Does any of you have any experience with Github Actions? Any
> > > >>>> thoughts
> > > >>>>>> about using it?
> > > >>>>>>
> > > >>>>>> Best,
> > > >>>>>> Tomek
> > > >>>>>>
> > > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> > > >>>> wrote:
> > > >>>>>>> FYI: Interesting article about the history behind GitLabCI
> > > >>>> (featuring
> > > >>>>>>> Kamil, my friend).
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > >>>>>>>
> > > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > >>>> <Ja...@polidea.com>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Some update on my GitLab experiences so far:
> > > >>>>>>>>
> > > >>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
> > > >>>> replicate
> > > >>>>>> the
> > > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
> > > >>>> works, I
> > > >>>>>> can
> > > >>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
> > > >>>> project
> > > >>>>>> for a
> > > >>>>>>>> few weeks to see how it is doing (while I am no holidays) and
> > > >>>> once we
> > > >>>>>> see
> > > >>>>>>>> it running and get the support for PRs from GitLab we can
> > > >>>> switch to
> > > >>>>> it.
> > > >>>>>>>>
> > > >>>>>>>> What do you think ? Should i call a vote or just try to set it
> > > >>>> up ?
> > > >>>>>>>>
> > > >>>>>>>> Some details
> > > >>>>>>>>
> > > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > > >>>> kubernetes -
> > > >>>>>>>> without the kubernetes-specific tests yet, but this should
> > > >>>> be
> > > >>>>>> rather easy
> > > >>>>>>>> with kind (looking at it next):
> > > >>>>>>>> - Working example here - you can take a look and compare the
> > > >>>>> UI/how
> > > >>>>>> it
> > > >>>>>>>> is to navigate, comparing to Travis etc:
> > > >>>>>>>> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > > >>>> around 35
> > > >>>>>>>> minutes in total), but I plan to optimise it further. I can
> > > >>>> play
> > > >>>>>> with
> > > >>>>>>>> memory/cpu settings of individual workers (Got some
> > > >>>> reasonable
> > > >>>>>> values now),
> > > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > > >>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
> > > >>>> that
> > > >>>>>> should
> > > >>>>>>>> let us build 3 builds in parallel independently from each
> > > >>>> other.
> > > >>>>>>>> - I managed to get Preemptible nodes working (we have built
> > > >>>> in
> > > >>>>> retry
> > > >>>>>>>> mechanism in GitLab to work in case of system failures like
> > > >>>> that
> > > >>>>>>>> - Current spending with > 120 builds is 40 USD. We should be
> > > >>>> way
> > > >>>>>> below
> > > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > > >>>> calculations.
> > > >>>>>> Likely
> > > >>>>>>>> well below
> > > >>>>>>>> - The current setup does not use GCR as cache and Kaniko as
> > > >>>> I
> > > >>>>>>>> originally planned. GCR would require custom authentication
> > > >>>> (and
> > > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
> > > >>>>>> multi-staging
> > > >>>>>>>> builds (cache does not work
> > > >>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682).
> > > >>>> I
> > > >>>>>> updated
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > >>>>>> to
> > > >>>>>>>> reflect that.
> > > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we can
> > > >>>> have
> > > >>>>>>>> reliable downloads not depending on DockerHub's stability
> > > >>>> (it has
> > > >>>>>> problems
> > > >>>>>>>> sometimes)
> > > >>>>>>>> - All in-all, it's GCP-independent. It could be run in any
> > > >>>>>> Kubernetes
> > > >>>>>>>> cluster (some optimisations like local volumes mounting for
> > > >>>> docker
> > > >>>>>> engine
> > > >>>>>>>> might have GCP-specific assumptions, but should be generally
> > > >>>>>> replicable).
> > > >>>>>>>> - You can take a look at the current source code in
> > > >>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > >>>>>>>> - There will be some updates (I will get rid of custom
> > > >>>> builder
> > > >>>>>> Docker,
> > > >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> > > >>>> mostly
> > > >>>>> some
> > > >>>>>>>> cleanups + removal of Travis-Specific variables + gitlab.ci
> > > >>>> yaml
> > > >>>>>> with
> > > >>>>>>>> job definitions.
> > > >>>>>>>>
> > > >>>>>>>> J.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > >>>>>> Jarek.Potiuk@polidea.com>
> > > >>>>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> So GitLab already works on automatically running builds from
> > > >>>> for PRs
> > > >>>>>> :).
> > > >>>>>>>>>
> > > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > >>>>>>>>> J.
> > > >>>>>>>>>
> > > >>>>>>>>> Principal Software Engineer
> > > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > > >>>>>>>>>
> > > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > >>>>>> Jarek.Potiuk@polidea.com>
> > > >>>>>>>>> napisał:
> > > >>>>>>>>>
> > > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > > >>>>> <+48%20660%20796%20129>>
> > > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>> --
> > > >>>>>>>>>>
> > > >>>>>>>>>> Jarek Potiuk
> > > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > >>>> Engineer
> > > >>>>>>>>>>
> > > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >>>>> <+48%20660%20796%20129>>
> > > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>>
> > > >>>>>>>> Jarek Potiuk
> > > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > > >>>> Engineer
> > > >>>>>>>>
> > > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >>>>> <+48%20660%20796%20129>>
> > > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>>
> > > >>>>>>> Jarek Potiuk
> > > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > >>>>>>>
> > > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >>>>> <+48%20660%20796%20129>>
> > > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> --
> > > >>>>>
> > > >>>>> Jarek Potiuk
> > > >>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >>>>>
> > > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >>>>> <+48%20660%20796%20129>>
> > > >>>>> [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/>
> >
>
>
> --
>
> Tomasz Urbaszek
> Polidea <https://www.polidea.com/> | Junior Software Engineer
>
> M: +48 505 628 493 <+48505628493>
> E: tomasz.urbaszek@polidea.com <to...@polidea.com>
>
> Unique Tech
> Check out our projects! <https://www.polidea.com/our-work>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Daniel Imberman <da...@gmail.com>]

I’d rather we do it all at once and not need to maintain two builds. Most/all of our CI/CD is dockerized at this point so there shouldn’t be a huge difference.


On Fri, Dec 13, 2019 at 1:23 AM, Tomasz Urbaszek <to...@polidea.com> wrote:
Hi all,

I have to solve a problem with our kubernetes test but for your information
I have never experienced a flaky
or timeouted build on Github Actions. Maybe I am lucky or maybe there's
something different.

If we agree to move to Github Actions, would we like to migrate
incrementally or fully?

Bests,
Tomek

On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> No problem on that side - Tomek is using the same scripts we have on Travis
> (and they generally work - I think the last step is to make all the
> tests pass. We have still a number of dependencies between tests and some
> environmental flakiness so that some tests consistently fail in Github
> Actions where they did not fail in Travis. From latest try by Tomek it
> looks like we are 1 test to go (plus some cleanup/setup of project and
> making sure all is stable):
>
> ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s (0:20:07)
> =====
>
> We discussed with Tomek and Kamil that in order to speed it up we might
> want to run our own workers on the GCP account we have - just to test
> quickly how much we can optimise it and I am inclined to agree. If we do it
> this way, the transition might be rather fast.
>
> If we want to use auto-scalable GKE cluster as we originally planned it
> might take more time to setup (similar setup to what I tried with GitLab).
> There we might need to use docker-in-docker to build the CI image with
> latest as first step of build and then use that built image by all
> subsequent steps. But we can do it as the next step - optimising the
> experience.
>
> J.
>
> On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> daniel.imberman@gmail.com>
> wrote:
>
> > +1 on my end as well.
> >
> > @jarek does this affect anything involving breeze? Do GitHub actions have
> > an easy docker/docker-compose based workflow?
> >
> > via Newton Mail [
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > ]
> > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <as...@apache.org>
> wrote:
> > Legal: no I don't think so.
> >
> > Infra: possibly yes to get secrets in there to run things on our own
> > "hardware" -
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > <
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> >
> > needs someone with Admin rights to create, and I don't see the Settings
> tab
> > at all.
> >
> > -ash
> >
> > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com> wrote:
> > >
> > > +1 for GitHub Actions. I have been using it for months for my side
> > > projects, and it’s working very well. I believe most of us are quite
> > tired
> > > of the waiting time using Travis CI.
> > >
> > > The only point I would like to remind is whether we need to communicate
> > > with Infra/Legal team for this.
> > >
> > >
> > > XD
> > >
> > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com> wrote:
> > >
> > >> +1 for Github actions
> > >>
> > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
> > >>
> > >>> Happy with any thing that gives a more seamless CI experience -
> faster
> > is
> > >>> good too!
> > >>>
> > >>> -a
> > >>>
> > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > >>> aizhamal@apache.org> wrote:
> > >>>> +1 on GitHub Actions.
> > >>>>
> > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> I am all for it! GitLab has been less-than helpful so far and
> > >>>> recently it
> > >>>>> seems that running PRs from forks will only be run in Enterrprise
> > >>>> Edition,
> > >>>>> which is less than welcome. I am quite a bit disappointed with the
> > >>>> pace and
> > >>>>> attitude. Github Actions seems to be much better choice -
> especially
> > >>>> that
> > >>>>> they are closely integrated with Github repo and seem to get
> > >>>>> attention/focus from Github/Microsoft.
> > >>>>>
> > >>>>> And they added self-hosted runners as well, which makes it possible
> > >>>> for us
> > >>>>> to optimise the experience.
> > >>>>>
> > >>>>> J.
> > >>>>>
> > >>>>>
> > >>>>> J.
> > >>>>>
> > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > >>>>> tomasz.urbaszek@polidea.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> It sometime since we last discussed using other CI than Travis.
> One
> > >>>> of
> > >>>>> the
> > >>>>>> main reasons behind considering Gitlab CI was its ability to work
> > >>>> on
> > >>>>>> self-hosted runner. However, over time of few long weeks Github
> > >>>> Actions
> > >>>>>> matured enough to allow using self-hosted runners!
> > >>>>>>
> > >>>>>> Github Actions are still growing but using them have few big
> > >>>> advantages:
> > >>>>>> - they are Github natives
> > >>>>>> - forking repo and enabling actions will run CI on your fork
> > >>>>> automatically
> > >>>>>> - variety of actions (PR checks, greetings, etc)
> > >>>>>>
> > >>>>>> I put together a PoC of CI in our internal repo:
> > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > >>>>>> My impression is quite good. I like information about steps
> > >>>> successes at
> > >>>>>> the PR level (no need to go to CI to check which step failed). The
> > >>>> build
> > >>>>>> log view is a little bit clumsy but it works.
> > >>>>>>
> > >>>>>> Does any of you have any experience with Github Actions? Any
> > >>>> thoughts
> > >>>>>> about using it?
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Tomek
> > >>>>>>
> > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> > >>>> wrote:
> > >>>>>>> FYI: Interesting article about the history behind GitLabCI
> > >>>> (featuring
> > >>>>>>> Kamil, my friend).
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > >>>>>>>
> > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > >>>> <Ja...@polidea.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Some update on my GitLab experiences so far:
> > >>>>>>>>
> > >>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
> > >>>> replicate
> > >>>>>> the
> > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
> > >>>> works, I
> > >>>>>> can
> > >>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
> > >>>> project
> > >>>>>> for a
> > >>>>>>>> few weeks to see how it is doing (while I am no holidays) and
> > >>>> once we
> > >>>>>> see
> > >>>>>>>> it running and get the support for PRs from GitLab we can
> > >>>> switch to
> > >>>>> it.
> > >>>>>>>>
> > >>>>>>>> What do you think ? Should i call a vote or just try to set it
> > >>>> up ?
> > >>>>>>>>
> > >>>>>>>> Some details
> > >>>>>>>>
> > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > >>>> kubernetes -
> > >>>>>>>> without the kubernetes-specific tests yet, but this should
> > >>>> be
> > >>>>>> rather easy
> > >>>>>>>> with kind (looking at it next):
> > >>>>>>>> - Working example here - you can take a look and compare the
> > >>>>> UI/how
> > >>>>>> it
> > >>>>>>>> is to navigate, comparing to Travis etc:
> > >>>>>>>> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > >>>> around 35
> > >>>>>>>> minutes in total), but I plan to optimise it further. I can
> > >>>> play
> > >>>>>> with
> > >>>>>>>> memory/cpu settings of individual workers (Got some
> > >>>> reasonable
> > >>>>>> values now),
> > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > >>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
> > >>>> that
> > >>>>>> should
> > >>>>>>>> let us build 3 builds in parallel independently from each
> > >>>> other.
> > >>>>>>>> - I managed to get Preemptible nodes working (we have built
> > >>>> in
> > >>>>> retry
> > >>>>>>>> mechanism in GitLab to work in case of system failures like
> > >>>> that
> > >>>>>>>> - Current spending with > 120 builds is 40 USD. We should be
> > >>>> way
> > >>>>>> below
> > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > >>>> calculations.
> > >>>>>> Likely
> > >>>>>>>> well below
> > >>>>>>>> - The current setup does not use GCR as cache and Kaniko as
> > >>>> I
> > >>>>>>>> originally planned. GCR would require custom authentication
> > >>>> (and
> > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
> > >>>>>> multi-staging
> > >>>>>>>> builds (cache does not work
> > >>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682).
> > >>>> I
> > >>>>>> updated
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > >>>>>> to
> > >>>>>>>> reflect that.
> > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we can
> > >>>> have
> > >>>>>>>> reliable downloads not depending on DockerHub's stability
> > >>>> (it has
> > >>>>>> problems
> > >>>>>>>> sometimes)
> > >>>>>>>> - All in-all, it's GCP-independent. It could be run in any
> > >>>>>> Kubernetes
> > >>>>>>>> cluster (some optimisations like local volumes mounting for
> > >>>> docker
> > >>>>>> engine
> > >>>>>>>> might have GCP-specific assumptions, but should be generally
> > >>>>>> replicable).
> > >>>>>>>> - You can take a look at the current source code in
> > >>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > >>>>>>>> - There will be some updates (I will get rid of custom
> > >>>> builder
> > >>>>>> Docker,
> > >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> > >>>> mostly
> > >>>>> some
> > >>>>>>>> cleanups + removal of Travis-Specific variables + gitlab.ci
> > >>>> yaml
> > >>>>>> with
> > >>>>>>>> job definitions.
> > >>>>>>>>
> > >>>>>>>> J.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > >>>>>> Jarek.Potiuk@polidea.com>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> So GitLab already works on automatically running builds from
> > >>>> for PRs
> > >>>>>> :).
> > >>>>>>>>>
> > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > >>>>>>>>> J.
> > >>>>>>>>>
> > >>>>>>>>> Principal Software Engineer
> > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > >>>>>>>>>
> > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > >>>>>> Jarek.Potiuk@polidea.com>
> > >>>>>>>>> napisał:
> > >>>>>>>>>
> > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>>
> > >>>>>>>>>> Jarek Potiuk
> > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > >>>> Engineer
> > >>>>>>>>>>
> > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>>
> > >>>>>>>> Jarek Potiuk
> > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > >>>> Engineer
> > >>>>>>>>
> > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>>
> > >>>>>>> Jarek Potiuk
> > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>>>>>>
> > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>>
> > >>>>> Jarek Potiuk
> > >>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>>>>
> > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>> [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/>
>


--

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Junior Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <to...@polidea.com>]

Hi all,

I have to solve a problem with our kubernetes test but for your information
I have never experienced a flaky
or timeouted build on Github Actions. Maybe I am lucky or maybe there's
something different.

If we agree to move to Github Actions, would we like to migrate
incrementally or fully?

Bests,
Tomek

On Wed, Dec 11, 2019 at 1:06 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> No problem on that side - Tomek is using the same scripts we have on Travis
> (and they generally work - I think the last step is to make all the
> tests pass. We have still a number of dependencies between tests and some
> environmental flakiness so that some tests consistently fail in Github
> Actions where they did not fail in Travis. From latest try by Tomek it
> looks like we are 1 test to go (plus some cleanup/setup of project and
> making sure all is stable):
>
> ==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s (0:20:07)
> =====
>
> We discussed with Tomek and Kamil that in order to speed it up we might
> want to run our own workers on the GCP account we have - just to test
> quickly how much we can optimise it and I am inclined to agree. If we do it
> this way, the transition might be rather fast.
>
> If we want to use auto-scalable GKE cluster as we originally planned it
> might take more time to setup (similar setup to what I tried with GitLab).
> There we might need to use docker-in-docker to build the CI image with
> latest as first step of build and then use that built image by all
> subsequent steps. But we can do it as the next step - optimising the
> experience.
>
> J.
>
> On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <
> daniel.imberman@gmail.com>
> wrote:
>
> > +1 on my end as well.
> >
> > @jarek does this affect anything involving breeze? Do GitHub actions have
> > an easy docker/docker-compose based workflow?
> >
> > via Newton Mail [
> >
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> > ]
> > On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <as...@apache.org>
> wrote:
> > Legal: no I don't think so.
> >
> > Infra: possibly yes to get secrets in there to run things on our own
> > "hardware" -
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> > <
> >
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> >
> > needs someone with Admin rights to create, and I don't see the Settings
> tab
> > at all.
> >
> > -ash
> >
> > > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com> wrote:
> > >
> > > +1 for GitHub Actions. I have been using it for months for my side
> > > projects, and it’s working very well. I believe most of us are quite
> > tired
> > > of the waiting time using Travis CI.
> > >
> > > The only point I would like to remind is whether we need to communicate
> > > with Infra/Legal team for this.
> > >
> > >
> > > XD
> > >
> > > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com> wrote:
> > >
> > >> +1 for Github actions
> > >>
> > >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
> > >>
> > >>> Happy with any thing that gives a more seamless CI experience -
> faster
> > is
> > >>> good too!
> > >>>
> > >>> -a
> > >>>
> > >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > >>> aizhamal@apache.org> wrote:
> > >>>> +1 on GitHub Actions.
> > >>>>
> > >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > >>>> wrote:
> > >>>>
> > >>>>> I am all for it! GitLab has been less-than helpful so far and
> > >>>> recently it
> > >>>>> seems that running PRs from forks will only be run in Enterrprise
> > >>>> Edition,
> > >>>>> which is less than welcome. I am quite a bit disappointed with the
> > >>>> pace and
> > >>>>> attitude. Github Actions seems to be much better choice -
> especially
> > >>>> that
> > >>>>> they are closely integrated with Github repo and seem to get
> > >>>>> attention/focus from Github/Microsoft.
> > >>>>>
> > >>>>> And they added self-hosted runners as well, which makes it possible
> > >>>> for us
> > >>>>> to optimise the experience.
> > >>>>>
> > >>>>> J.
> > >>>>>
> > >>>>>
> > >>>>> J.
> > >>>>>
> > >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > >>>>> tomasz.urbaszek@polidea.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> It sometime since we last discussed using other CI than Travis.
> One
> > >>>> of
> > >>>>> the
> > >>>>>> main reasons behind considering Gitlab CI was its ability to work
> > >>>> on
> > >>>>>> self-hosted runner. However, over time of few long weeks Github
> > >>>> Actions
> > >>>>>> matured enough to allow using self-hosted runners!
> > >>>>>>
> > >>>>>> Github Actions are still growing but using them have few big
> > >>>> advantages:
> > >>>>>> - they are Github natives
> > >>>>>> - forking repo and enabling actions will run CI on your fork
> > >>>>> automatically
> > >>>>>> - variety of actions (PR checks, greetings, etc)
> > >>>>>>
> > >>>>>> I put together a PoC of CI in our internal repo:
> > >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> > >>>>>> My impression is quite good. I like information about steps
> > >>>> successes at
> > >>>>>> the PR level (no need to go to CI to check which step failed). The
> > >>>> build
> > >>>>>> log view is a little bit clumsy but it works.
> > >>>>>>
> > >>>>>> Does any of you have any experience with Github Actions? Any
> > >>>> thoughts
> > >>>>>> about using it?
> > >>>>>>
> > >>>>>> Best,
> > >>>>>> Tomek
> > >>>>>>
> > >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> > >>>> wrote:
> > >>>>>>> FYI: Interesting article about the history behind GitLabCI
> > >>>> (featuring
> > >>>>>>> Kamil, my friend).
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > >>>>>>>
> > >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > >>>> <Ja...@polidea.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Some update on my GitLab experiences so far:
> > >>>>>>>>
> > >>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
> > >>>> replicate
> > >>>>>> the
> > >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
> > >>>> works, I
> > >>>>>> can
> > >>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
> > >>>> project
> > >>>>>> for a
> > >>>>>>>> few weeks to see how it is doing (while I am no holidays) and
> > >>>> once we
> > >>>>>> see
> > >>>>>>>> it running and get the support for PRs from GitLab we can
> > >>>> switch to
> > >>>>> it.
> > >>>>>>>>
> > >>>>>>>> What do you think ? Should i call a vote or just try to set it
> > >>>> up ?
> > >>>>>>>>
> > >>>>>>>> Some details
> > >>>>>>>>
> > >>>>>>>> - I manged to get full working builds in GitLabCI +
> > >>>> kubernetes -
> > >>>>>>>> without the kubernetes-specific tests yet, but this should
> > >>>> be
> > >>>>>> rather easy
> > >>>>>>>> with kind (looking at it next):
> > >>>>>>>> - Working example here - you can take a look and compare the
> > >>>>> UI/how
> > >>>>>> it
> > >>>>>>>> is to navigate, comparing to Travis etc:
> > >>>>>>>> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> > >>>> around 35
> > >>>>>>>> minutes in total), but I plan to optimise it further. I can
> > >>>> play
> > >>>>>> with
> > >>>>>>>> memory/cpu settings of individual workers (Got some
> > >>>> reasonable
> > >>>>>> values now),
> > >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> > >>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
> > >>>> that
> > >>>>>> should
> > >>>>>>>> let us build 3 builds in parallel independently from each
> > >>>> other.
> > >>>>>>>> - I managed to get Preemptible nodes working (we have built
> > >>>> in
> > >>>>> retry
> > >>>>>>>> mechanism in GitLab to work in case of system failures like
> > >>>> that
> > >>>>>>>> - Current spending with > 120 builds is 40 USD. We should be
> > >>>> way
> > >>>>>> below
> > >>>>>>>> 500 USD/month according to my back-of-the-envelope
> > >>>> calculations.
> > >>>>>> Likely
> > >>>>>>>> well below
> > >>>>>>>> - The current setup does not use GCR as cache and Kaniko as
> > >>>> I
> > >>>>>>>> originally planned. GCR would require custom authentication
> > >>>> (and
> > >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
> > >>>>>> multi-staging
> > >>>>>>>> builds (cache does not work
> > >>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682).
> > >>>> I
> > >>>>>> updated
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > >>>>>> to
> > >>>>>>>> reflect that.
> > >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we can
> > >>>> have
> > >>>>>>>> reliable downloads not depending on DockerHub's stability
> > >>>> (it has
> > >>>>>> problems
> > >>>>>>>> sometimes)
> > >>>>>>>> - All in-all, it's GCP-independent. It could be run in any
> > >>>>>> Kubernetes
> > >>>>>>>> cluster (some optimisations like local volumes mounting for
> > >>>> docker
> > >>>>>> engine
> > >>>>>>>> might have GCP-specific assumptions, but should be generally
> > >>>>>> replicable).
> > >>>>>>>> - You can take a look at the current source code in
> > >>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > >>>>>>>> - There will be some updates (I will get rid of custom
> > >>>> builder
> > >>>>>> Docker,
> > >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> > >>>> mostly
> > >>>>> some
> > >>>>>>>> cleanups + removal of Travis-Specific variables + gitlab.ci
> > >>>> yaml
> > >>>>>> with
> > >>>>>>>> job definitions.
> > >>>>>>>>
> > >>>>>>>> J.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > >>>>>> Jarek.Potiuk@polidea.com>
> > >>>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> So GitLab already works on automatically running builds from
> > >>>> for PRs
> > >>>>>> :).
> > >>>>>>>>>
> > >>>>>>>>> Kamil got involved and will be out advocate on it:
> > >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > >>>>>>>>> J.
> > >>>>>>>>>
> > >>>>>>>>> Principal Software Engineer
> > >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> > >>>>>>>>>
> > >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > >>>>>> Jarek.Potiuk@polidea.com>
> > >>>>>>>>> napisał:
> > >>>>>>>>>
> > >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> --
> > >>>>>>>>>>
> > >>>>>>>>>> Jarek Potiuk
> > >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > >>>> Engineer
> > >>>>>>>>>>
> > >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>>
> > >>>>>>>> Jarek Potiuk
> > >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> > >>>> Engineer
> > >>>>>>>>
> > >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>>
> > >>>>>>> Jarek Potiuk
> > >>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>>>>>>
> > >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>>>> [image: Polidea] <https://www.polidea.com/>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> --
> > >>>>>
> > >>>>> Jarek Potiuk
> > >>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>>>>
> > >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >>>>> <+48%20660%20796%20129>>
> > >>>>> [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/>
>


-- 

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Junior Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

No problem on that side - Tomek is using the same scripts we have on Travis
(and they generally work - I think the last step is to make all the
tests pass. We have still a number of dependencies between tests and some
environmental flakiness so that some tests consistently fail in Github
Actions where they did not fail in Travis. From latest try by Tomek it
looks like we are 1 test to go (plus some cleanup/setup of project and
making sure all is stable):

==== 1 failed, 4030 passed, 119 skipped, 16 warnings in 1207.96s (0:20:07)
=====

We discussed with Tomek and Kamil that in order to speed it up we might
want to run our own workers on the GCP account we have - just to test
quickly how much we can optimise it and I am inclined to agree. If we do it
this way, the transition might be rather fast.

If we want to use auto-scalable GKE cluster as we originally planned it
might take more time to setup (similar setup to what I tried with GitLab).
There we might need to use docker-in-docker to build the CI image with
latest as first step of build and then use that built image by all
subsequent steps. But we can do it as the next step - optimising the
experience.

J.

On Tue, Dec 10, 2019 at 11:34 PM Daniel Imberman <da...@gmail.com>
wrote:

> +1 on my end as well.
>
> @jarek does this affect anything involving breeze? Do GitHub actions have
> an easy docker/docker-compose based workflow?
>
> via Newton Mail [
> https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2
> ]
> On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <as...@apache.org> wrote:
> Legal: no I don't think so.
>
> Infra: possibly yes to get secrets in there to run things on our own
> "hardware" -
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets
> <
> https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets>
> needs someone with Admin rights to create, and I don't see the Settings tab
> at all.
>
> -ash
>
> > On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com> wrote:
> >
> > +1 for GitHub Actions. I have been using it for months for my side
> > projects, and it’s working very well. I believe most of us are quite
> tired
> > of the waiting time using Travis CI.
> >
> > The only point I would like to remind is whether we need to communicate
> > with Infra/Legal team for this.
> >
> >
> > XD
> >
> > On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com> wrote:
> >
> >> +1 for Github actions
> >>
> >> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
> >>
> >>> Happy with any thing that gives a more seamless CI experience - faster
> is
> >>> good too!
> >>>
> >>> -a
> >>>
> >>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> >>> aizhamal@apache.org> wrote:
> >>>> +1 on GitHub Actions.
> >>>>
> >>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> >>>> wrote:
> >>>>
> >>>>> I am all for it! GitLab has been less-than helpful so far and
> >>>> recently it
> >>>>> seems that running PRs from forks will only be run in Enterrprise
> >>>> Edition,
> >>>>> which is less than welcome. I am quite a bit disappointed with the
> >>>> pace and
> >>>>> attitude. Github Actions seems to be much better choice - especially
> >>>> that
> >>>>> they are closely integrated with Github repo and seem to get
> >>>>> attention/focus from Github/Microsoft.
> >>>>>
> >>>>> And they added self-hosted runners as well, which makes it possible
> >>>> for us
> >>>>> to optimise the experience.
> >>>>>
> >>>>> J.
> >>>>>
> >>>>>
> >>>>> J.
> >>>>>
> >>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> >>>>> tomasz.urbaszek@polidea.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> It sometime since we last discussed using other CI than Travis. One
> >>>> of
> >>>>> the
> >>>>>> main reasons behind considering Gitlab CI was its ability to work
> >>>> on
> >>>>>> self-hosted runner. However, over time of few long weeks Github
> >>>> Actions
> >>>>>> matured enough to allow using self-hosted runners!
> >>>>>>
> >>>>>> Github Actions are still growing but using them have few big
> >>>> advantages:
> >>>>>> - they are Github natives
> >>>>>> - forking repo and enabling actions will run CI on your fork
> >>>>> automatically
> >>>>>> - variety of actions (PR checks, greetings, etc)
> >>>>>>
> >>>>>> I put together a PoC of CI in our internal repo:
> >>>>>> https://github.com/PolideaInternal/airflow/pull/542
> >>>>>> My impression is quite good. I like information about steps
> >>>> successes at
> >>>>>> the PR level (no need to go to CI to check which step failed). The
> >>>> build
> >>>>>> log view is a little bit clumsy but it works.
> >>>>>>
> >>>>>> Does any of you have any experience with Github Actions? Any
> >>>> thoughts
> >>>>>> about using it?
> >>>>>>
> >>>>>> Best,
> >>>>>> Tomek
> >>>>>>
> >>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> >>>> wrote:
> >>>>>>> FYI: Interesting article about the history behind GitLabCI
> >>>> (featuring
> >>>>>>> Kamil, my friend).
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> >>>>>>>
> >>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> >>>> <Ja...@polidea.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Some update on my GitLab experiences so far:
> >>>>>>>>
> >>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
> >>>> replicate
> >>>>>> the
> >>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
> >>>> works, I
> >>>>>> can
> >>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
> >>>> project
> >>>>>> for a
> >>>>>>>> few weeks to see how it is doing (while I am no holidays) and
> >>>> once we
> >>>>>> see
> >>>>>>>> it running and get the support for PRs from GitLab we can
> >>>> switch to
> >>>>> it.
> >>>>>>>>
> >>>>>>>> What do you think ? Should i call a vote or just try to set it
> >>>> up ?
> >>>>>>>>
> >>>>>>>> Some details
> >>>>>>>>
> >>>>>>>> - I manged to get full working builds in GitLabCI +
> >>>> kubernetes -
> >>>>>>>> without the kubernetes-specific tests yet, but this should
> >>>> be
> >>>>>> rather easy
> >>>>>>>> with kind (looking at it next):
> >>>>>>>> - Working example here - you can take a look and compare the
> >>>>> UI/how
> >>>>>> it
> >>>>>>>> is to navigate, comparing to Travis etc:
> >>>>>>>> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> >>>>>>>> - Per-job it is a bit slower than Travis so far (still
> >>>> around 35
> >>>>>>>> minutes in total), but I plan to optimise it further. I can
> >>>> play
> >>>>>> with
> >>>>>>>> memory/cpu settings of individual workers (Got some
> >>>> reasonable
> >>>>>> values now),
> >>>>>>>> I can use local SSD disk as Docker storage/logs/etc
> >>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
> >>>> that
> >>>>>> should
> >>>>>>>> let us build 3 builds in parallel independently from each
> >>>> other.
> >>>>>>>> - I managed to get Preemptible nodes working (we have built
> >>>> in
> >>>>> retry
> >>>>>>>> mechanism in GitLab to work in case of system failures like
> >>>> that
> >>>>>>>> - Current spending with > 120 builds is 40 USD. We should be
> >>>> way
> >>>>>> below
> >>>>>>>> 500 USD/month according to my back-of-the-envelope
> >>>> calculations.
> >>>>>> Likely
> >>>>>>>> well below
> >>>>>>>> - The current setup does not use GCR as cache and Kaniko as
> >>>> I
> >>>>>>>> originally planned. GCR would require custom authentication
> >>>> (and
> >>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
> >>>>>> multi-staging
> >>>>>>>> builds (cache does not work
> >>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682).
> >>>> I
> >>>>>> updated
> >>>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> >>>>>> to
> >>>>>>>> reflect that.
> >>>>>>>> - We only use GCR as mirroring of DockerHub - so that we can
> >>>> have
> >>>>>>>> reliable downloads not depending on DockerHub's stability
> >>>> (it has
> >>>>>> problems
> >>>>>>>> sometimes)
> >>>>>>>> - All in-all, it's GCP-independent. It could be run in any
> >>>>>> Kubernetes
> >>>>>>>> cluster (some optimisations like local volumes mounting for
> >>>> docker
> >>>>>> engine
> >>>>>>>> might have GCP-specific assumptions, but should be generally
> >>>>>> replicable).
> >>>>>>>> - You can take a look at the current source code in
> >>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
> >>>>>>>> - There will be some updates (I will get rid of custom
> >>>> builder
> >>>>>> Docker,
> >>>>>>>> simplify it a bit and implement kubernetes tests) - it's
> >>>> mostly
> >>>>> some
> >>>>>>>> cleanups + removal of Travis-Specific variables + gitlab.ci
> >>>> yaml
> >>>>>> with
> >>>>>>>> job definitions.
> >>>>>>>>
> >>>>>>>> J.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> >>>>>> Jarek.Potiuk@polidea.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> So GitLab already works on automatically running builds from
> >>>> for PRs
> >>>>>> :).
> >>>>>>>>>
> >>>>>>>>> Kamil got involved and will be out advocate on it:
> >>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> >>>>>>>>> J.
> >>>>>>>>>
> >>>>>>>>> Principal Software Engineer
> >>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
> >>>>>>>>>
> >>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> >>>>>> Jarek.Potiuk@polidea.com>
> >>>>>>>>> napisał:
> >>>>>>>>>
> >>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> >>>>> <+48%20660%20796%20129>>
> >>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>>
> >>>>>>>>>> Jarek Potiuk
> >>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> >>>> Engineer
> >>>>>>>>>>
> >>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >>>>> <+48%20660%20796%20129>>
> >>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>
> >>>>>>>> Jarek Potiuk
> >>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
> >>>> Engineer
> >>>>>>>>
> >>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >>>>> <+48%20660%20796%20129>>
> >>>>>>>> [image: Polidea] <https://www.polidea.com/>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>> Jarek Potiuk
> >>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> >>>>>>>
> >>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >>>>> <+48%20660%20796%20129>>
> >>>>>>> [image: Polidea] <https://www.polidea.com/>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>>
> >>>>> Jarek Potiuk
> >>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> >>>>>
> >>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >>>>> <+48%20660%20796%20129>>
> >>>>> [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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Daniel Imberman <da...@gmail.com>]

+1 on my end as well.

@jarek does this affect anything involving breeze? Do GitHub actions have an easy docker/docker-compose based workflow?

via Newton Mail [https://cloudmagic.com/k/d/mailapp?ct=dx&cv=10.0.32&pv=10.14.5&source=email_footer_2]
On Tue, Dec 10, 2019 at 5:28 AM, Ash Berlin-Taylor <as...@apache.org> wrote:
Legal: no I don't think so.

Infra: possibly yes to get secrets in there to run things on our own "hardware" - https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets <https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets> needs someone with Admin rights to create, and I don't see the Settings tab at all.

-ash

> On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com> wrote:
>
> +1 for GitHub Actions. I have been using it for months for my side
> projects, and it’s working very well. I believe most of us are quite tired
> of the waiting time using Travis CI.
>
> The only point I would like to remind is whether we need to communicate
> with Infra/Legal team for this.
>
>
> XD
>
> On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com> wrote:
>
>> +1 for Github actions
>>
>> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
>>
>>> Happy with any thing that gives a more seamless CI experience - faster is
>>> good too!
>>>
>>> -a
>>>
>>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
>>> aizhamal@apache.org> wrote:
>>>> +1 on GitHub Actions.
>>>>
>>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
>>>> wrote:
>>>>
>>>>> I am all for it! GitLab has been less-than helpful so far and
>>>> recently it
>>>>> seems that running PRs from forks will only be run in Enterrprise
>>>> Edition,
>>>>> which is less than welcome. I am quite a bit disappointed with the
>>>> pace and
>>>>> attitude. Github Actions seems to be much better choice - especially
>>>> that
>>>>> they are closely integrated with Github repo and seem to get
>>>>> attention/focus from Github/Microsoft.
>>>>>
>>>>> And they added self-hosted runners as well, which makes it possible
>>>> for us
>>>>> to optimise the experience.
>>>>>
>>>>> J.
>>>>>
>>>>>
>>>>> J.
>>>>>
>>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
>>>>> tomasz.urbaszek@polidea.com>
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> It sometime since we last discussed using other CI than Travis. One
>>>> of
>>>>> the
>>>>>> main reasons behind considering Gitlab CI was its ability to work
>>>> on
>>>>>> self-hosted runner. However, over time of few long weeks Github
>>>> Actions
>>>>>> matured enough to allow using self-hosted runners!
>>>>>>
>>>>>> Github Actions are still growing but using them have few big
>>>> advantages:
>>>>>> - they are Github natives
>>>>>> - forking repo and enabling actions will run CI on your fork
>>>>> automatically
>>>>>> - variety of actions (PR checks, greetings, etc)
>>>>>>
>>>>>> I put together a PoC of CI in our internal repo:
>>>>>> https://github.com/PolideaInternal/airflow/pull/542
>>>>>> My impression is quite good. I like information about steps
>>>> successes at
>>>>>> the PR level (no need to go to CI to check which step failed). The
>>>> build
>>>>>> log view is a little bit clumsy but it works.
>>>>>>
>>>>>> Does any of you have any experience with Github Actions? Any
>>>> thoughts
>>>>>> about using it?
>>>>>>
>>>>>> Best,
>>>>>> Tomek
>>>>>>
>>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
>>>> wrote:
>>>>>>> FYI: Interesting article about the history behind GitLabCI
>>>> (featuring
>>>>>>> Kamil, my friend).
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
>>>>>>>
>>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
>>>> <Ja...@polidea.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Some update on my GitLab experiences so far:
>>>>>>>>
>>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
>>>> replicate
>>>>>> the
>>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
>>>> works, I
>>>>>> can
>>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
>>>> project
>>>>>> for a
>>>>>>>> few weeks to see how it is doing (while I am no holidays) and
>>>> once we
>>>>>> see
>>>>>>>> it running and get the support for PRs from GitLab we can
>>>> switch to
>>>>> it.
>>>>>>>>
>>>>>>>> What do you think ? Should i call a vote or just try to set it
>>>> up ?
>>>>>>>>
>>>>>>>> Some details
>>>>>>>>
>>>>>>>> - I manged to get full working builds in GitLabCI +
>>>> kubernetes -
>>>>>>>> without the kubernetes-specific tests yet, but this should
>>>> be
>>>>>> rather easy
>>>>>>>> with kind (looking at it next):
>>>>>>>> - Working example here - you can take a look and compare the
>>>>> UI/how
>>>>>> it
>>>>>>>> is to navigate, comparing to Travis etc:
>>>>>>>> https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
>>>>>>>> - Per-job it is a bit slower than Travis so far (still
>>>> around 35
>>>>>>>> minutes in total), but I plan to optimise it further. I can
>>>> play
>>>>>> with
>>>>>>>> memory/cpu settings of individual workers (Got some
>>>> reasonable
>>>>>> values now),
>>>>>>>> I can use local SSD disk as Docker storage/logs/etc
>>>>>>>> - I got an approval for 72vCPU quota (up for initial 24) -
>>>> that
>>>>>> should
>>>>>>>> let us build 3 builds in parallel independently from each
>>>> other.
>>>>>>>> - I managed to get Preemptible nodes working (we have built
>>>> in
>>>>> retry
>>>>>>>> mechanism in GitLab to work in case of system failures like
>>>> that
>>>>>>>> - Current spending with > 120 builds is 40 USD. We should be
>>>> way
>>>>>> below
>>>>>>>> 500 USD/month according to my back-of-the-envelope
>>>> calculations.
>>>>>> Likely
>>>>>>>> well below
>>>>>>>> - The current setup does not use GCR as cache and Kaniko as
>>>> I
>>>>>>>> originally planned. GCR would require custom authentication
>>>> (and
>>>>>>>> easy-to-steal secrets) and Kaniko does not yet well handle
>>>>>> multi-staging
>>>>>>>> builds (cache does not work
>>>>>>>> https://github.com/GoogleContainerTools/kaniko/issues/682).
>>>> I
>>>>>> updated
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>>>>>> to
>>>>>>>> reflect that.
>>>>>>>> - We only use GCR as mirroring of DockerHub - so that we can
>>>> have
>>>>>>>> reliable downloads not depending on DockerHub's stability
>>>> (it has
>>>>>> problems
>>>>>>>> sometimes)
>>>>>>>> - All in-all, it's GCP-independent. It could be run in any
>>>>>> Kubernetes
>>>>>>>> cluster (some optimisations like local volumes mounting for
>>>> docker
>>>>>> engine
>>>>>>>> might have GCP-specific assumptions, but should be generally
>>>>>> replicable).
>>>>>>>> - You can take a look at the current source code in
>>>>>>>> https://github.com/potiuk/airflow/commits/test-gitlab-ci
>>>>>>>> - There will be some updates (I will get rid of custom
>>>> builder
>>>>>> Docker,
>>>>>>>> simplify it a bit and implement kubernetes tests) - it's
>>>> mostly
>>>>> some
>>>>>>>> cleanups + removal of Travis-Specific variables + gitlab.ci
>>>> yaml
>>>>>> with
>>>>>>>> job definitions.
>>>>>>>>
>>>>>>>> J.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
>>>>>> Jarek.Potiuk@polidea.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> So GitLab already works on automatically running builds from
>>>> for PRs
>>>>>> :).
>>>>>>>>>
>>>>>>>>> Kamil got involved and will be out advocate on it:
>>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
>>>>>>>>> J.
>>>>>>>>>
>>>>>>>>> Principal Software Engineer
>>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
>>>>>>>>>
>>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
>>>>>> Jarek.Potiuk@polidea.com>
>>>>>>>>> napisał:
>>>>>>>>>
>>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> Jarek Potiuk
>>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
>>>> Engineer
>>>>>>>>>>
>>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> Jarek Potiuk
>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
>>>> Engineer
>>>>>>>>
>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> Jarek Potiuk
>>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>>>>>>
>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Jarek Potiuk
>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>>>>
>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>
>>>
>>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Ash Berlin-Taylor <as...@apache.org>]

Legal: no I don't think so.

Infra: possibly yes to get secrets in there to run things on our own "hardware" - https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets <https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets> needs someone with Admin rights to create, and I don't see the Settings tab at all.

-ash

> On 10 Dec 2019, at 02:46, Deng Xiaodong <xd...@gmail.com> wrote:
> 
> +1 for GitHub Actions. I have been using it for months for my side
> projects, and it’s working very well. I believe most of us are quite tired
> of the waiting time using Travis CI.
> 
> The only point I would like to remind is whether we need to communicate
> with Infra/Legal team for this.
> 
> 
> XD
> 
> On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com> wrote:
> 
>> +1 for Github actions
>> 
>> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
>> 
>>> Happy with any thing that gives a more seamless CI experience - faster is
>>> good too!
>>> 
>>> -a
>>> 
>>> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
>>> aizhamal@apache.org> wrote:
>>>> +1 on GitHub Actions.
>>>> 
>>>> On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
>>>> wrote:
>>>> 
>>>>> I am all for it! GitLab has been less-than helpful so far and
>>>> recently it
>>>>> seems that running PRs from forks will only be run in Enterrprise
>>>> Edition,
>>>>> which is less than welcome. I am quite a bit disappointed with the
>>>> pace and
>>>>> attitude. Github Actions seems to be much better choice - especially
>>>> that
>>>>> they are closely integrated with Github repo and seem to get
>>>>> attention/focus from Github/Microsoft.
>>>>> 
>>>>> And they added self-hosted runners as well, which makes it possible
>>>> for us
>>>>> to optimise the experience.
>>>>> 
>>>>> J.
>>>>> 
>>>>> 
>>>>> J.
>>>>> 
>>>>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
>>>>> tomasz.urbaszek@polidea.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> It sometime since we last discussed using other CI than Travis. One
>>>> of
>>>>> the
>>>>>> main reasons behind considering Gitlab CI was its ability to work
>>>> on
>>>>>> self-hosted runner. However, over time of few long weeks Github
>>>> Actions
>>>>>> matured enough to allow using self-hosted runners!
>>>>>> 
>>>>>> Github Actions are still growing but using them have few big
>>>> advantages:
>>>>>> - they are Github natives
>>>>>> - forking repo and enabling actions will run CI on your fork
>>>>> automatically
>>>>>> - variety of actions (PR checks, greetings, etc)
>>>>>> 
>>>>>> I put together a PoC of CI in our internal repo:
>>>>>> https://github.com/PolideaInternal/airflow/pull/542
>>>>>> My impression is quite good. I like information about steps
>>>> successes at
>>>>>> the PR level (no need to go to CI to check which step failed). The
>>>> build
>>>>>> log view is a little bit clumsy but it works.
>>>>>> 
>>>>>> Does any of you have any experience with Github Actions? Any
>>>> thoughts
>>>>>> about using it?
>>>>>> 
>>>>>> Best,
>>>>>> Tomek
>>>>>> 
>>>>>> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
>>>> wrote:
>>>>>>> FYI: Interesting article about the history behind GitLabCI
>>>> (featuring
>>>>>>> Kamil, my friend).
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
>>>>>>> 
>>>>>>> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
>>>> <Ja...@polidea.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Some update on my GitLab experiences so far:
>>>>>>>> 
>>>>>>>> TL;DR; I think the POC has shown that we can fairly easily
>>>> replicate
>>>>>> the
>>>>>>>> CI in GitLab + Kubernetes. I think i can say - it generally
>>>> works, I
>>>>>> can
>>>>>>>> plug it in for master/v1-10-test builds in the main Airflow
>>>> project
>>>>>> for a
>>>>>>>> few weeks to see how it is doing (while I am no holidays) and
>>>> once we
>>>>>> see
>>>>>>>> it running and get the support for PRs from GitLab we can
>>>> switch to
>>>>> it.
>>>>>>>> 
>>>>>>>> What do you think ? Should i call a vote or just try to set it
>>>> up ?
>>>>>>>> 
>>>>>>>> Some details
>>>>>>>> 
>>>>>>>>   - I manged to get full working builds in GitLabCI +
>>>> kubernetes -
>>>>>>>>   without the kubernetes-specific tests yet, but this should
>>>> be
>>>>>> rather easy
>>>>>>>>   with kind (looking at it next):
>>>>>>>>   - Working example here - you can take a look and compare the
>>>>> UI/how
>>>>>> it
>>>>>>>>   is to navigate, comparing to Travis etc:
>>>>>>>>   https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
>>>>>>>>   - Per-job it is a bit slower than Travis so far (still
>>>> around 35
>>>>>>>>   minutes in total), but I plan to optimise it further. I can
>>>> play
>>>>>> with
>>>>>>>>   memory/cpu settings of individual workers (Got some
>>>> reasonable
>>>>>> values now),
>>>>>>>>   I can use local SSD disk as Docker storage/logs/etc
>>>>>>>>   - I got an approval for 72vCPU quota (up for initial 24) -
>>>> that
>>>>>> should
>>>>>>>>   let us build 3 builds in parallel independently from each
>>>> other.
>>>>>>>>   - I managed to get Preemptible nodes working (we have built
>>>> in
>>>>> retry
>>>>>>>>   mechanism in GitLab to work in case of system failures like
>>>> that
>>>>>>>>   - Current spending with > 120 builds is 40 USD. We should be
>>>> way
>>>>>> below
>>>>>>>>   500 USD/month according to my back-of-the-envelope
>>>> calculations.
>>>>>> Likely
>>>>>>>>   well below
>>>>>>>>   - The current setup does not use GCR as cache and Kaniko as
>>>> I
>>>>>>>>   originally planned. GCR would require custom authentication
>>>> (and
>>>>>>>>   easy-to-steal secrets) and Kaniko does not yet well handle
>>>>>> multi-staging
>>>>>>>>   builds (cache does not work
>>>>>>>>   https://github.com/GoogleContainerTools/kaniko/issues/682).
>>>> I
>>>>>> updated
>>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>>>>>> to
>>>>>>>>   reflect that.
>>>>>>>>   - We only use GCR as mirroring of DockerHub - so that we can
>>>> have
>>>>>>>>   reliable downloads not depending on DockerHub's stability
>>>> (it has
>>>>>> problems
>>>>>>>>   sometimes)
>>>>>>>>   - All in-all, it's GCP-independent. It could be run in any
>>>>>> Kubernetes
>>>>>>>>   cluster (some optimisations like local volumes mounting for
>>>> docker
>>>>>> engine
>>>>>>>>   might have GCP-specific assumptions, but should be generally
>>>>>> replicable).
>>>>>>>>   - You can take a look at the current source code in
>>>>>>>>   https://github.com/potiuk/airflow/commits/test-gitlab-ci
>>>>>>>>   - There will be some updates (I will get rid of custom
>>>> builder
>>>>>> Docker,
>>>>>>>>   simplify it a bit and implement kubernetes tests) - it's
>>>> mostly
>>>>> some
>>>>>>>>   cleanups + removal of Travis-Specific variables + gitlab.ci
>>>> yaml
>>>>>> with
>>>>>>>>   job definitions.
>>>>>>>> 
>>>>>>>> J.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
>>>>>> Jarek.Potiuk@polidea.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> So GitLab already works on automatically running builds from
>>>> for PRs
>>>>>> :).
>>>>>>>>> 
>>>>>>>>> Kamil got involved and will be out advocate on it:
>>>>>>>>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
>>>>>>>>> J.
>>>>>>>>> 
>>>>>>>>> Principal Software Engineer
>>>>>>>>> Phone: +48660796129 <+48%20660%20796%20129>
>>>>>>>>> 
>>>>>>>>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
>>>>>> Jarek.Potiuk@polidea.com>
>>>>>>>>> napisał:
>>>>>>>>> 
>>>>>>>>>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> 
>>>>>>>>>> Jarek Potiuk
>>>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
>>>> Engineer
>>>>>>>>>> 
>>>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> --
>>>>>>>> 
>>>>>>>> Jarek Potiuk
>>>>>>>> Polidea <https://www.polidea.com/> | Principal Software
>>>> Engineer
>>>>>>>> 
>>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> 
>>>>>>> Jarek Potiuk
>>>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>>>>>> 
>>>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> 
>>>>> Jarek Potiuk
>>>>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>>>> 
>>>>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>>>>> <+48%20660%20796%20129>>
>>>>> [image: Polidea] <https://www.polidea.com/>
>>>>> 
>>> 
>> 

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Deng Xiaodong <xd...@gmail.com>]

+1 for GitHub Actions. I have been using it for months for my side
projects, and it’s working very well. I believe most of us are quite tired
of the waiting time using Travis CI.

The only point I would like to remind is whether we need to communicate
with Infra/Legal team for this.


XD

On Tue, Dec 10, 2019 at 06:49 Kaxil Naik <ka...@gmail.com> wrote:

> +1 for Github actions
>
> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
>
> > Happy with any thing that gives a more seamless CI experience - faster is
> > good too!
> >
> > -a
> >
> > On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > aizhamal@apache.org> wrote:
> > >+1 on GitHub Actions.
> > >
> > >On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
> > >wrote:
> > >
> > >> I am all for it! GitLab has been less-than helpful so far and
> > >recently it
> > >> seems that running PRs from forks will only be run in Enterrprise
> > >Edition,
> > >> which is less than welcome. I am quite a bit disappointed with the
> > >pace and
> > >> attitude. Github Actions seems to be much better choice - especially
> > >that
> > >> they are closely integrated with Github repo and seem to get
> > >> attention/focus from Github/Microsoft.
> > >>
> > >> And they added self-hosted runners as well, which makes it possible
> > >for us
> > >> to optimise the experience.
> > >>
> > >> J.
> > >>
> > >>
> > >> J.
> > >>
> > >> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > >> tomasz.urbaszek@polidea.com>
> > >> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > It sometime since we last discussed using other CI than Travis. One
> > >of
> > >> the
> > >> > main reasons behind considering Gitlab CI was its ability to work
> > >on
> > >> > self-hosted runner. However, over time of few long weeks Github
> > >Actions
> > >> > matured enough to allow using self-hosted runners!
> > >> >
> > >> > Github Actions are still growing but using them have few big
> > >advantages:
> > >> > - they are Github natives
> > >> > - forking repo and enabling actions will run CI on your fork
> > >> automatically
> > >> > - variety of actions (PR checks, greetings, etc)
> > >> >
> > >> > I put together a PoC of CI in our internal repo:
> > >> > https://github.com/PolideaInternal/airflow/pull/542
> > >> > My impression is quite good. I like information about steps
> > >successes at
> > >> > the PR level (no need to go to CI to check which step failed). The
> > >build
> > >> > log view is a little bit clumsy but it works.
> > >> >
> > >> > Does any of you have any experience with Github Actions? Any
> > >thoughts
> > >> > about using it?
> > >> >
> > >> > Best,
> > >> > Tomek
> > >> >
> > >> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> > >wrote:
> > >> > > FYI: Interesting article about the history behind GitLabCI
> > >(featuring
> > >> > > Kamil, my friend).
> > >> > >
> > >> >
> > >>
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > >> > >
> > >> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > ><Ja...@polidea.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Some update on my GitLab experiences so far:
> > >> > > >
> > >> > > > TL;DR; I think the POC has shown that we can fairly easily
> > >replicate
> > >> > the
> > >> > > > CI in GitLab + Kubernetes. I think i can say - it generally
> > >works, I
> > >> > can
> > >> > > > plug it in for master/v1-10-test builds in the main Airflow
> > >project
> > >> > for a
> > >> > > > few weeks to see how it is doing (while I am no holidays) and
> > >once we
> > >> > see
> > >> > > > it running and get the support for PRs from GitLab we can
> > >switch to
> > >> it.
> > >> > > >
> > >> > > > What do you think ? Should i call a vote or just try to set it
> > >up ?
> > >> > > >
> > >> > > > Some details
> > >> > > >
> > >> > > >    - I manged to get full working builds in GitLabCI +
> > >kubernetes -
> > >> > > >    without the kubernetes-specific tests yet, but this should
> > >be
> > >> > rather easy
> > >> > > >    with kind (looking at it next):
> > >> > > >    - Working example here - you can take a look and compare the
> > >> UI/how
> > >> > it
> > >> > > >    is to navigate, comparing to Travis etc:
> > >> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > >> > > >    - Per-job it is a bit slower than Travis so far (still
> > >around 35
> > >> > > >    minutes in total), but I plan to optimise it further. I can
> > >play
> > >> > with
> > >> > > >    memory/cpu settings of individual workers (Got some
> > >reasonable
> > >> > values now),
> > >> > > >    I can use local SSD disk as Docker storage/logs/etc
> > >> > > >    - I got an approval for 72vCPU quota (up for initial 24) -
> > >that
> > >> > should
> > >> > > >    let us build 3 builds in parallel independently from each
> > >other.
> > >> > > >    - I managed to get Preemptible nodes working (we have built
> > >in
> > >> retry
> > >> > > >    mechanism in GitLab to work in case of system failures like
> > >that
> > >> > > >    - Current spending with > 120 builds is 40 USD. We should be
> > >way
> > >> > below
> > >> > > >    500 USD/month according to my back-of-the-envelope
> > >calculations.
> > >> > Likely
> > >> > > >    well below
> > >> > > >    - The current setup does not use GCR as cache and Kaniko as
> > >I
> > >> > > >    originally planned. GCR would require custom authentication
> > >(and
> > >> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
> > >> > multi-staging
> > >> > > >    builds (cache does not work
> > >> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682).
> > >I
> > >> > updated
> > >> > > >
> > >> >
> > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > >> > to
> > >> > > >    reflect that.
> > >> > > >    - We only use GCR as mirroring of DockerHub - so that we can
> > >have
> > >> > > >    reliable downloads not depending on DockerHub's stability
> > >(it has
> > >> > problems
> > >> > > >    sometimes)
> > >> > > >    - All in-all, it's GCP-independent. It could be run in any
> > >> > Kubernetes
> > >> > > >    cluster (some optimisations like local volumes mounting for
> > >docker
> > >> > engine
> > >> > > >    might have GCP-specific assumptions, but should be generally
> > >> > replicable).
> > >> > > >    - You can take a look at the current source code in
> > >> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > >> > > >    - There will be some updates (I will get rid of custom
> > >builder
> > >> > Docker,
> > >> > > >    simplify it a bit and implement kubernetes tests) - it's
> > >mostly
> > >> some
> > >> > > >    cleanups + removal of Travis-Specific variables + gitlab.ci
> > >yaml
> > >> > with
> > >> > > >    job definitions.
> > >> > > >
> > >> > > > J.
> > >> > > >
> > >> > > >
> > >> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > >> > Jarek.Potiuk@polidea.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > >> So GitLab already works on automatically running builds from
> > >for PRs
> > >> > :).
> > >> > > >>
> > >> > > >> Kamil got involved and will be out advocate on it:
> > >> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > >> > > >> J.
> > >> > > >>
> > >> > > >> Principal Software Engineer
> > >> > > >> Phone: +48660796129 <+48%20660%20796%20129>
> > >> > > >>
> > >> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > >> > Jarek.Potiuk@polidea.com>
> > >> > > >> napisał:
> > >> > > >>
> > >> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > >>>> > [image: Polidea] <https://www.polidea.com/>
> > >> > > >>>>
> > >> > > >>>
> > >> > > >>>
> > >> > > >>> --
> > >> > > >>>
> > >> > > >>> Jarek Potiuk
> > >> > > >>> Polidea <https://www.polidea.com/> | Principal Software
> > >Engineer
> > >> > > >>>
> > >> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > >>> [image: Polidea] <https://www.polidea.com/>
> > >> > > >>>
> > >> > > >>>
> > >> > > >
> > >> > > > --
> > >> > > >
> > >> > > > Jarek Potiuk
> > >> > > > Polidea <https://www.polidea.com/> | Principal Software
> > >Engineer
> > >> > > >
> > >> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > > [image: Polidea] <https://www.polidea.com/>
> > >> > > >
> > >> > > >
> > >> > >
> > >> > > --
> > >> > >
> > >> > > Jarek Potiuk
> > >> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >> > >
> > >> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > [image: Polidea] <https://www.polidea.com/>
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> Jarek Potiuk
> > >> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>
> > >> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> [image: Polidea] <https://www.polidea.com/>
> > >>
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

["Driesprong, Fokko" <fo...@driesprong.frl>]

+1 for Github Actions.

I've noticed that Spark is also using this:
https://github.com/apache/spark/pull/26644

Cheers, Fokko

Op di 10 dec. 2019 om 11:45 schreef Kamil Breguła <kamil.bregula@polidea.com
>:

> +1 for Github Actions
>
> On Mon, Dec 9, 2019 at 11:49 PM Kaxil Naik <ka...@gmail.com> wrote:
>
> > +1 for Github actions
> >
> > On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
> >
> > > Happy with any thing that gives a more seamless CI experience - faster
> is
> > > good too!
> > >
> > > -a
> > >
> > > On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > > aizhamal@apache.org> wrote:
> > > >+1 on GitHub Actions.
> > > >
> > > >On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> > > >wrote:
> > > >
> > > >> I am all for it! GitLab has been less-than helpful so far and
> > > >recently it
> > > >> seems that running PRs from forks will only be run in Enterrprise
> > > >Edition,
> > > >> which is less than welcome. I am quite a bit disappointed with the
> > > >pace and
> > > >> attitude. Github Actions seems to be much better choice - especially
> > > >that
> > > >> they are closely integrated with Github repo and seem to get
> > > >> attention/focus from Github/Microsoft.
> > > >>
> > > >> And they added self-hosted runners as well, which makes it possible
> > > >for us
> > > >> to optimise the experience.
> > > >>
> > > >> J.
> > > >>
> > > >>
> > > >> J.
> > > >>
> > > >> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > > >> tomasz.urbaszek@polidea.com>
> > > >> wrote:
> > > >>
> > > >> > Hi all,
> > > >> >
> > > >> > It sometime since we last discussed using other CI than Travis.
> One
> > > >of
> > > >> the
> > > >> > main reasons behind considering Gitlab CI was its ability to work
> > > >on
> > > >> > self-hosted runner. However, over time of few long weeks Github
> > > >Actions
> > > >> > matured enough to allow using self-hosted runners!
> > > >> >
> > > >> > Github Actions are still growing but using them have few big
> > > >advantages:
> > > >> > - they are Github natives
> > > >> > - forking repo and enabling actions will run CI on your fork
> > > >> automatically
> > > >> > - variety of actions (PR checks, greetings, etc)
> > > >> >
> > > >> > I put together a PoC of CI in our internal repo:
> > > >> > https://github.com/PolideaInternal/airflow/pull/542
> > > >> > My impression is quite good. I like information about steps
> > > >successes at
> > > >> > the PR level (no need to go to CI to check which step failed). The
> > > >build
> > > >> > log view is a little bit clumsy but it works.
> > > >> >
> > > >> > Does any of you have any experience with Github Actions? Any
> > > >thoughts
> > > >> > about using it?
> > > >> >
> > > >> > Best,
> > > >> > Tomek
> > > >> >
> > > >> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> > > >wrote:
> > > >> > > FYI: Interesting article about the history behind GitLabCI
> > > >(featuring
> > > >> > > Kamil, my friend).
> > > >> > >
> > > >> >
> > > >>
> > > >
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > > >> > >
> > > >> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > > ><Ja...@polidea.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Some update on my GitLab experiences so far:
> > > >> > > >
> > > >> > > > TL;DR; I think the POC has shown that we can fairly easily
> > > >replicate
> > > >> > the
> > > >> > > > CI in GitLab + Kubernetes. I think i can say - it generally
> > > >works, I
> > > >> > can
> > > >> > > > plug it in for master/v1-10-test builds in the main Airflow
> > > >project
> > > >> > for a
> > > >> > > > few weeks to see how it is doing (while I am no holidays) and
> > > >once we
> > > >> > see
> > > >> > > > it running and get the support for PRs from GitLab we can
> > > >switch to
> > > >> it.
> > > >> > > >
> > > >> > > > What do you think ? Should i call a vote or just try to set it
> > > >up ?
> > > >> > > >
> > > >> > > > Some details
> > > >> > > >
> > > >> > > >    - I manged to get full working builds in GitLabCI +
> > > >kubernetes -
> > > >> > > >    without the kubernetes-specific tests yet, but this should
> > > >be
> > > >> > rather easy
> > > >> > > >    with kind (looking at it next):
> > > >> > > >    - Working example here - you can take a look and compare
> the
> > > >> UI/how
> > > >> > it
> > > >> > > >    is to navigate, comparing to Travis etc:
> > > >> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > >> > > >    - Per-job it is a bit slower than Travis so far (still
> > > >around 35
> > > >> > > >    minutes in total), but I plan to optimise it further. I can
> > > >play
> > > >> > with
> > > >> > > >    memory/cpu settings of individual workers (Got some
> > > >reasonable
> > > >> > values now),
> > > >> > > >    I can use local SSD disk as Docker storage/logs/etc
> > > >> > > >    - I got an approval for 72vCPU quota (up for initial 24) -
> > > >that
> > > >> > should
> > > >> > > >    let us build 3 builds in parallel independently from each
> > > >other.
> > > >> > > >    - I managed to get Preemptible nodes working (we have built
> > > >in
> > > >> retry
> > > >> > > >    mechanism in GitLab to work in case of system failures like
> > > >that
> > > >> > > >    - Current spending with > 120 builds is 40 USD. We should
> be
> > > >way
> > > >> > below
> > > >> > > >    500 USD/month according to my back-of-the-envelope
> > > >calculations.
> > > >> > Likely
> > > >> > > >    well below
> > > >> > > >    - The current setup does not use GCR as cache and Kaniko as
> > > >I
> > > >> > > >    originally planned. GCR would require custom authentication
> > > >(and
> > > >> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
> > > >> > multi-staging
> > > >> > > >    builds (cache does not work
> > > >> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682
> ).
> > > >I
> > > >> > updated
> > > >> > > >
> > > >> >
> > > >>
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > > >> > to
> > > >> > > >    reflect that.
> > > >> > > >    - We only use GCR as mirroring of DockerHub - so that we
> can
> > > >have
> > > >> > > >    reliable downloads not depending on DockerHub's stability
> > > >(it has
> > > >> > problems
> > > >> > > >    sometimes)
> > > >> > > >    - All in-all, it's GCP-independent. It could be run in any
> > > >> > Kubernetes
> > > >> > > >    cluster (some optimisations like local volumes mounting for
> > > >docker
> > > >> > engine
> > > >> > > >    might have GCP-specific assumptions, but should be
> generally
> > > >> > replicable).
> > > >> > > >    - You can take a look at the current source code in
> > > >> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > >> > > >    - There will be some updates (I will get rid of custom
> > > >builder
> > > >> > Docker,
> > > >> > > >    simplify it a bit and implement kubernetes tests) - it's
> > > >mostly
> > > >> some
> > > >> > > >    cleanups + removal of Travis-Specific variables +
> gitlab.ci
> > > >yaml
> > > >> > with
> > > >> > > >    job definitions.
> > > >> > > >
> > > >> > > > J.
> > > >> > > >
> > > >> > > >
> > > >> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > > >> > Jarek.Potiuk@polidea.com>
> > > >> > > > wrote:
> > > >> > > >
> > > >> > > >> So GitLab already works on automatically running builds from
> > > >for PRs
> > > >> > :).
> > > >> > > >>
> > > >> > > >> Kamil got involved and will be out advocate on it:
> > > >> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > >> > > >> J.
> > > >> > > >>
> > > >> > > >> Principal Software Engineer
> > > >> > > >> Phone: +48660796129 <+48%20660%20796%20129>
> > > >> > > >>
> > > >> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > > >> > Jarek.Potiuk@polidea.com>
> > > >> > > >> napisał:
> > > >> > > >>
> > > >> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > > >> <+48%20660%20796%20129>>
> > > >> > > >>>> > [image: Polidea] <https://www.polidea.com/>
> > > >> > > >>>>
> > > >> > > >>>
> > > >> > > >>>
> > > >> > > >>> --
> > > >> > > >>>
> > > >> > > >>> Jarek Potiuk
> > > >> > > >>> Polidea <https://www.polidea.com/> | Principal Software
> > > >Engineer
> > > >> > > >>>
> > > >> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >> <+48%20660%20796%20129>>
> > > >> > > >>> [image: Polidea] <https://www.polidea.com/>
> > > >> > > >>>
> > > >> > > >>>
> > > >> > > >
> > > >> > > > --
> > > >> > > >
> > > >> > > > Jarek Potiuk
> > > >> > > > Polidea <https://www.polidea.com/> | Principal Software
> > > >Engineer
> > > >> > > >
> > > >> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >> <+48%20660%20796%20129>>
> > > >> > > > [image: Polidea] <https://www.polidea.com/>
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >> > > --
> > > >> > >
> > > >> > > Jarek Potiuk
> > > >> > > Polidea <https://www.polidea.com/> | Principal Software
> Engineer
> > > >> > >
> > > >> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >> <+48%20660%20796%20129>>
> > > >> > > [image: Polidea] <https://www.polidea.com/>
> > > >> > >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >>
> > > >> Jarek Potiuk
> > > >> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >>
> > > >> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > > >> <+48%20660%20796%20129>>
> > > >> [image: Polidea] <https://www.polidea.com/>
> > > >>
> > >
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kamil Breguła <ka...@polidea.com>]

+1 for Github Actions

On Mon, Dec 9, 2019 at 11:49 PM Kaxil Naik <ka...@gmail.com> wrote:

> +1 for Github actions
>
> On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:
>
> > Happy with any thing that gives a more seamless CI experience - faster is
> > good too!
> >
> > -a
> >
> > On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> > aizhamal@apache.org> wrote:
> > >+1 on GitHub Actions.
> > >
> > >On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
> > >wrote:
> > >
> > >> I am all for it! GitLab has been less-than helpful so far and
> > >recently it
> > >> seems that running PRs from forks will only be run in Enterrprise
> > >Edition,
> > >> which is less than welcome. I am quite a bit disappointed with the
> > >pace and
> > >> attitude. Github Actions seems to be much better choice - especially
> > >that
> > >> they are closely integrated with Github repo and seem to get
> > >> attention/focus from Github/Microsoft.
> > >>
> > >> And they added self-hosted runners as well, which makes it possible
> > >for us
> > >> to optimise the experience.
> > >>
> > >> J.
> > >>
> > >>
> > >> J.
> > >>
> > >> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> > >> tomasz.urbaszek@polidea.com>
> > >> wrote:
> > >>
> > >> > Hi all,
> > >> >
> > >> > It sometime since we last discussed using other CI than Travis. One
> > >of
> > >> the
> > >> > main reasons behind considering Gitlab CI was its ability to work
> > >on
> > >> > self-hosted runner. However, over time of few long weeks Github
> > >Actions
> > >> > matured enough to allow using self-hosted runners!
> > >> >
> > >> > Github Actions are still growing but using them have few big
> > >advantages:
> > >> > - they are Github natives
> > >> > - forking repo and enabling actions will run CI on your fork
> > >> automatically
> > >> > - variety of actions (PR checks, greetings, etc)
> > >> >
> > >> > I put together a PoC of CI in our internal repo:
> > >> > https://github.com/PolideaInternal/airflow/pull/542
> > >> > My impression is quite good. I like information about steps
> > >successes at
> > >> > the PR level (no need to go to CI to check which step failed). The
> > >build
> > >> > log view is a little bit clumsy but it works.
> > >> >
> > >> > Does any of you have any experience with Github Actions? Any
> > >thoughts
> > >> > about using it?
> > >> >
> > >> > Best,
> > >> > Tomek
> > >> >
> > >> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> > >wrote:
> > >> > > FYI: Interesting article about the history behind GitLabCI
> > >(featuring
> > >> > > Kamil, my friend).
> > >> > >
> > >> >
> > >>
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > >> > >
> > >> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> > ><Ja...@polidea.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Some update on my GitLab experiences so far:
> > >> > > >
> > >> > > > TL;DR; I think the POC has shown that we can fairly easily
> > >replicate
> > >> > the
> > >> > > > CI in GitLab + Kubernetes. I think i can say - it generally
> > >works, I
> > >> > can
> > >> > > > plug it in for master/v1-10-test builds in the main Airflow
> > >project
> > >> > for a
> > >> > > > few weeks to see how it is doing (while I am no holidays) and
> > >once we
> > >> > see
> > >> > > > it running and get the support for PRs from GitLab we can
> > >switch to
> > >> it.
> > >> > > >
> > >> > > > What do you think ? Should i call a vote or just try to set it
> > >up ?
> > >> > > >
> > >> > > > Some details
> > >> > > >
> > >> > > >    - I manged to get full working builds in GitLabCI +
> > >kubernetes -
> > >> > > >    without the kubernetes-specific tests yet, but this should
> > >be
> > >> > rather easy
> > >> > > >    with kind (looking at it next):
> > >> > > >    - Working example here - you can take a look and compare the
> > >> UI/how
> > >> > it
> > >> > > >    is to navigate, comparing to Travis etc:
> > >> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > >> > > >    - Per-job it is a bit slower than Travis so far (still
> > >around 35
> > >> > > >    minutes in total), but I plan to optimise it further. I can
> > >play
> > >> > with
> > >> > > >    memory/cpu settings of individual workers (Got some
> > >reasonable
> > >> > values now),
> > >> > > >    I can use local SSD disk as Docker storage/logs/etc
> > >> > > >    - I got an approval for 72vCPU quota (up for initial 24) -
> > >that
> > >> > should
> > >> > > >    let us build 3 builds in parallel independently from each
> > >other.
> > >> > > >    - I managed to get Preemptible nodes working (we have built
> > >in
> > >> retry
> > >> > > >    mechanism in GitLab to work in case of system failures like
> > >that
> > >> > > >    - Current spending with > 120 builds is 40 USD. We should be
> > >way
> > >> > below
> > >> > > >    500 USD/month according to my back-of-the-envelope
> > >calculations.
> > >> > Likely
> > >> > > >    well below
> > >> > > >    - The current setup does not use GCR as cache and Kaniko as
> > >I
> > >> > > >    originally planned. GCR would require custom authentication
> > >(and
> > >> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
> > >> > multi-staging
> > >> > > >    builds (cache does not work
> > >> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682).
> > >I
> > >> > updated
> > >> > > >
> > >> >
> > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > >> > to
> > >> > > >    reflect that.
> > >> > > >    - We only use GCR as mirroring of DockerHub - so that we can
> > >have
> > >> > > >    reliable downloads not depending on DockerHub's stability
> > >(it has
> > >> > problems
> > >> > > >    sometimes)
> > >> > > >    - All in-all, it's GCP-independent. It could be run in any
> > >> > Kubernetes
> > >> > > >    cluster (some optimisations like local volumes mounting for
> > >docker
> > >> > engine
> > >> > > >    might have GCP-specific assumptions, but should be generally
> > >> > replicable).
> > >> > > >    - You can take a look at the current source code in
> > >> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > >> > > >    - There will be some updates (I will get rid of custom
> > >builder
> > >> > Docker,
> > >> > > >    simplify it a bit and implement kubernetes tests) - it's
> > >mostly
> > >> some
> > >> > > >    cleanups + removal of Travis-Specific variables + gitlab.ci
> > >yaml
> > >> > with
> > >> > > >    job definitions.
> > >> > > >
> > >> > > > J.
> > >> > > >
> > >> > > >
> > >> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > >> > Jarek.Potiuk@polidea.com>
> > >> > > > wrote:
> > >> > > >
> > >> > > >> So GitLab already works on automatically running builds from
> > >for PRs
> > >> > :).
> > >> > > >>
> > >> > > >> Kamil got involved and will be out advocate on it:
> > >> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > >> > > >> J.
> > >> > > >>
> > >> > > >> Principal Software Engineer
> > >> > > >> Phone: +48660796129 <+48%20660%20796%20129>
> > >> > > >>
> > >> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > >> > Jarek.Potiuk@polidea.com>
> > >> > > >> napisał:
> > >> > > >>
> > >> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > >>>> > [image: Polidea] <https://www.polidea.com/>
> > >> > > >>>>
> > >> > > >>>
> > >> > > >>>
> > >> > > >>> --
> > >> > > >>>
> > >> > > >>> Jarek Potiuk
> > >> > > >>> Polidea <https://www.polidea.com/> | Principal Software
> > >Engineer
> > >> > > >>>
> > >> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > >>> [image: Polidea] <https://www.polidea.com/>
> > >> > > >>>
> > >> > > >>>
> > >> > > >
> > >> > > > --
> > >> > > >
> > >> > > > Jarek Potiuk
> > >> > > > Polidea <https://www.polidea.com/> | Principal Software
> > >Engineer
> > >> > > >
> > >> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > > [image: Polidea] <https://www.polidea.com/>
> > >> > > >
> > >> > > >
> > >> > >
> > >> > > --
> > >> > >
> > >> > > Jarek Potiuk
> > >> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >> > >
> > >> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> > > [image: Polidea] <https://www.polidea.com/>
> > >> > >
> > >> >
> > >>
> > >>
> > >> --
> > >>
> > >> Jarek Potiuk
> > >> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>
> > >> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > >> <+48%20660%20796%20129>>
> > >> [image: Polidea] <https://www.polidea.com/>
> > >>
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kaxil Naik <ka...@gmail.com>]

+1 for Github actions

On Mon, Dec 9, 2019, 22:16 Ash Berlin-Taylor <as...@apache.org> wrote:

> Happy with any thing that gives a more seamless CI experience - faster is
> good too!
>
> -a
>
> On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <
> aizhamal@apache.org> wrote:
> >+1 on GitHub Actions.
> >
> >On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
> >wrote:
> >
> >> I am all for it! GitLab has been less-than helpful so far and
> >recently it
> >> seems that running PRs from forks will only be run in Enterrprise
> >Edition,
> >> which is less than welcome. I am quite a bit disappointed with the
> >pace and
> >> attitude. Github Actions seems to be much better choice - especially
> >that
> >> they are closely integrated with Github repo and seem to get
> >> attention/focus from Github/Microsoft.
> >>
> >> And they added self-hosted runners as well, which makes it possible
> >for us
> >> to optimise the experience.
> >>
> >> J.
> >>
> >>
> >> J.
> >>
> >> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> >> tomasz.urbaszek@polidea.com>
> >> wrote:
> >>
> >> > Hi all,
> >> >
> >> > It sometime since we last discussed using other CI than Travis. One
> >of
> >> the
> >> > main reasons behind considering Gitlab CI was its ability to work
> >on
> >> > self-hosted runner. However, over time of few long weeks Github
> >Actions
> >> > matured enough to allow using self-hosted runners!
> >> >
> >> > Github Actions are still growing but using them have few big
> >advantages:
> >> > - they are Github natives
> >> > - forking repo and enabling actions will run CI on your fork
> >> automatically
> >> > - variety of actions (PR checks, greetings, etc)
> >> >
> >> > I put together a PoC of CI in our internal repo:
> >> > https://github.com/PolideaInternal/airflow/pull/542
> >> > My impression is quite good. I like information about steps
> >successes at
> >> > the PR level (no need to go to CI to check which step failed). The
> >build
> >> > log view is a little bit clumsy but it works.
> >> >
> >> > Does any of you have any experience with Github Actions? Any
> >thoughts
> >> > about using it?
> >> >
> >> > Best,
> >> > Tomek
> >> >
> >> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
> >wrote:
> >> > > FYI: Interesting article about the history behind GitLabCI
> >(featuring
> >> > > Kamil, my friend).
> >> > >
> >> >
> >>
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> >> > >
> >> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
> ><Ja...@polidea.com>
> >> > > wrote:
> >> > >
> >> > > > Some update on my GitLab experiences so far:
> >> > > >
> >> > > > TL;DR; I think the POC has shown that we can fairly easily
> >replicate
> >> > the
> >> > > > CI in GitLab + Kubernetes. I think i can say - it generally
> >works, I
> >> > can
> >> > > > plug it in for master/v1-10-test builds in the main Airflow
> >project
> >> > for a
> >> > > > few weeks to see how it is doing (while I am no holidays) and
> >once we
> >> > see
> >> > > > it running and get the support for PRs from GitLab we can
> >switch to
> >> it.
> >> > > >
> >> > > > What do you think ? Should i call a vote or just try to set it
> >up ?
> >> > > >
> >> > > > Some details
> >> > > >
> >> > > >    - I manged to get full working builds in GitLabCI +
> >kubernetes -
> >> > > >    without the kubernetes-specific tests yet, but this should
> >be
> >> > rather easy
> >> > > >    with kind (looking at it next):
> >> > > >    - Working example here - you can take a look and compare the
> >> UI/how
> >> > it
> >> > > >    is to navigate, comparing to Travis etc:
> >> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> >> > > >    - Per-job it is a bit slower than Travis so far (still
> >around 35
> >> > > >    minutes in total), but I plan to optimise it further. I can
> >play
> >> > with
> >> > > >    memory/cpu settings of individual workers (Got some
> >reasonable
> >> > values now),
> >> > > >    I can use local SSD disk as Docker storage/logs/etc
> >> > > >    - I got an approval for 72vCPU quota (up for initial 24) -
> >that
> >> > should
> >> > > >    let us build 3 builds in parallel independently from each
> >other.
> >> > > >    - I managed to get Preemptible nodes working (we have built
> >in
> >> retry
> >> > > >    mechanism in GitLab to work in case of system failures like
> >that
> >> > > >    - Current spending with > 120 builds is 40 USD. We should be
> >way
> >> > below
> >> > > >    500 USD/month according to my back-of-the-envelope
> >calculations.
> >> > Likely
> >> > > >    well below
> >> > > >    - The current setup does not use GCR as cache and Kaniko as
> >I
> >> > > >    originally planned. GCR would require custom authentication
> >(and
> >> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
> >> > multi-staging
> >> > > >    builds (cache does not work
> >> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682).
> >I
> >> > updated
> >> > > >
> >> >
> >>
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> >> > to
> >> > > >    reflect that.
> >> > > >    - We only use GCR as mirroring of DockerHub - so that we can
> >have
> >> > > >    reliable downloads not depending on DockerHub's stability
> >(it has
> >> > problems
> >> > > >    sometimes)
> >> > > >    - All in-all, it's GCP-independent. It could be run in any
> >> > Kubernetes
> >> > > >    cluster (some optimisations like local volumes mounting for
> >docker
> >> > engine
> >> > > >    might have GCP-specific assumptions, but should be generally
> >> > replicable).
> >> > > >    - You can take a look at the current source code in
> >> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> >> > > >    - There will be some updates (I will get rid of custom
> >builder
> >> > Docker,
> >> > > >    simplify it a bit and implement kubernetes tests) - it's
> >mostly
> >> some
> >> > > >    cleanups + removal of Travis-Specific variables + gitlab.ci
> >yaml
> >> > with
> >> > > >    job definitions.
> >> > > >
> >> > > > J.
> >> > > >
> >> > > >
> >> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> >> > Jarek.Potiuk@polidea.com>
> >> > > > wrote:
> >> > > >
> >> > > >> So GitLab already works on automatically running builds from
> >for PRs
> >> > :).
> >> > > >>
> >> > > >> Kamil got involved and will be out advocate on it:
> >> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> >> > > >> J.
> >> > > >>
> >> > > >> Principal Software Engineer
> >> > > >> Phone: +48660796129 <+48%20660%20796%20129>
> >> > > >>
> >> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> >> > Jarek.Potiuk@polidea.com>
> >> > > >> napisał:
> >> > > >>
> >> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> >> <+48%20660%20796%20129>>
> >> > > >>>> > [image: Polidea] <https://www.polidea.com/>
> >> > > >>>>
> >> > > >>>
> >> > > >>>
> >> > > >>> --
> >> > > >>>
> >> > > >>> Jarek Potiuk
> >> > > >>> Polidea <https://www.polidea.com/> | Principal Software
> >Engineer
> >> > > >>>
> >> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >> <+48%20660%20796%20129>>
> >> > > >>> [image: Polidea] <https://www.polidea.com/>
> >> > > >>>
> >> > > >>>
> >> > > >
> >> > > > --
> >> > > >
> >> > > > Jarek Potiuk
> >> > > > Polidea <https://www.polidea.com/> | Principal Software
> >Engineer
> >> > > >
> >> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >> <+48%20660%20796%20129>>
> >> > > > [image: Polidea] <https://www.polidea.com/>
> >> > > >
> >> > > >
> >> > >
> >> > > --
> >> > >
> >> > > Jarek Potiuk
> >> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >> > >
> >> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >> <+48%20660%20796%20129>>
> >> > > [image: Polidea] <https://www.polidea.com/>
> >> > >
> >> >
> >>
> >>
> >> --
> >>
> >> Jarek Potiuk
> >> Polidea <https://www.polidea.com/> | Principal Software Engineer
> >>
> >> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> >> <+48%20660%20796%20129>>
> >> [image: Polidea] <https://www.polidea.com/>
> >>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Ash Berlin-Taylor <as...@apache.org>]

Happy with any thing that gives a more seamless CI experience - faster is good too!

-a

On 9 December 2019 22:12:05 GMT, Aizhamal Nurmamat kyzy <ai...@apache.org> wrote:
>+1 on GitHub Actions.
>
>On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
>wrote:
>
>> I am all for it! GitLab has been less-than helpful so far and
>recently it
>> seems that running PRs from forks will only be run in Enterrprise
>Edition,
>> which is less than welcome. I am quite a bit disappointed with the
>pace and
>> attitude. Github Actions seems to be much better choice - especially
>that
>> they are closely integrated with Github repo and seem to get
>> attention/focus from Github/Microsoft.
>>
>> And they added self-hosted runners as well, which makes it possible
>for us
>> to optimise the experience.
>>
>> J.
>>
>>
>> J.
>>
>> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
>> tomasz.urbaszek@polidea.com>
>> wrote:
>>
>> > Hi all,
>> >
>> > It sometime since we last discussed using other CI than Travis. One
>of
>> the
>> > main reasons behind considering Gitlab CI was its ability to work
>on
>> > self-hosted runner. However, over time of few long weeks Github
>Actions
>> > matured enough to allow using self-hosted runners!
>> >
>> > Github Actions are still growing but using them have few big
>advantages:
>> > - they are Github natives
>> > - forking repo and enabling actions will run CI on your fork
>> automatically
>> > - variety of actions (PR checks, greetings, etc)
>> >
>> > I put together a PoC of CI in our internal repo:
>> > https://github.com/PolideaInternal/airflow/pull/542
>> > My impression is quite good. I like information about steps
>successes at
>> > the PR level (no need to go to CI to check which step failed). The
>build
>> > log view is a little bit clumsy but it works.
>> >
>> > Does any of you have any experience with Github Actions? Any
>thoughts
>> > about using it?
>> >
>> > Best,
>> > Tomek
>> >
>> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com>
>wrote:
>> > > FYI: Interesting article about the history behind GitLabCI
>(featuring
>> > > Kamil, my friend).
>> > >
>> >
>>
>https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
>> > >
>> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk
><Ja...@polidea.com>
>> > > wrote:
>> > >
>> > > > Some update on my GitLab experiences so far:
>> > > >
>> > > > TL;DR; I think the POC has shown that we can fairly easily
>replicate
>> > the
>> > > > CI in GitLab + Kubernetes. I think i can say - it generally
>works, I
>> > can
>> > > > plug it in for master/v1-10-test builds in the main Airflow
>project
>> > for a
>> > > > few weeks to see how it is doing (while I am no holidays) and
>once we
>> > see
>> > > > it running and get the support for PRs from GitLab we can
>switch to
>> it.
>> > > >
>> > > > What do you think ? Should i call a vote or just try to set it
>up ?
>> > > >
>> > > > Some details
>> > > >
>> > > >    - I manged to get full working builds in GitLabCI +
>kubernetes -
>> > > >    without the kubernetes-specific tests yet, but this should
>be
>> > rather easy
>> > > >    with kind (looking at it next):
>> > > >    - Working example here - you can take a look and compare the
>> UI/how
>> > it
>> > > >    is to navigate, comparing to Travis etc:
>> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
>> > > >    - Per-job it is a bit slower than Travis so far (still
>around 35
>> > > >    minutes in total), but I plan to optimise it further. I can
>play
>> > with
>> > > >    memory/cpu settings of individual workers (Got some
>reasonable
>> > values now),
>> > > >    I can use local SSD disk as Docker storage/logs/etc
>> > > >    - I got an approval for 72vCPU quota (up for initial 24) -
>that
>> > should
>> > > >    let us build 3 builds in parallel independently from each
>other.
>> > > >    - I managed to get Preemptible nodes working (we have built
>in
>> retry
>> > > >    mechanism in GitLab to work in case of system failures like
>that
>> > > >    - Current spending with > 120 builds is 40 USD. We should be
>way
>> > below
>> > > >    500 USD/month according to my back-of-the-envelope
>calculations.
>> > Likely
>> > > >    well below
>> > > >    - The current setup does not use GCR as cache and Kaniko as
>I
>> > > >    originally planned. GCR would require custom authentication
>(and
>> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
>> > multi-staging
>> > > >    builds (cache does not work
>> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682).
>I
>> > updated
>> > > >
>> >
>>
>https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
>> > to
>> > > >    reflect that.
>> > > >    - We only use GCR as mirroring of DockerHub - so that we can
>have
>> > > >    reliable downloads not depending on DockerHub's stability
>(it has
>> > problems
>> > > >    sometimes)
>> > > >    - All in-all, it's GCP-independent. It could be run in any
>> > Kubernetes
>> > > >    cluster (some optimisations like local volumes mounting for
>docker
>> > engine
>> > > >    might have GCP-specific assumptions, but should be generally
>> > replicable).
>> > > >    - You can take a look at the current source code in
>> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
>> > > >    - There will be some updates (I will get rid of custom
>builder
>> > Docker,
>> > > >    simplify it a bit and implement kubernetes tests) - it's
>mostly
>> some
>> > > >    cleanups + removal of Travis-Specific variables + gitlab.ci
>yaml
>> > with
>> > > >    job definitions.
>> > > >
>> > > > J.
>> > > >
>> > > >
>> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
>> > Jarek.Potiuk@polidea.com>
>> > > > wrote:
>> > > >
>> > > >> So GitLab already works on automatically running builds from
>for PRs
>> > :).
>> > > >>
>> > > >> Kamil got involved and will be out advocate on it:
>> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
>> > > >> J.
>> > > >>
>> > > >> Principal Software Engineer
>> > > >> Phone: +48660796129 <+48%20660%20796%20129>
>> > > >>
>> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
>> > Jarek.Potiuk@polidea.com>
>> > > >> napisał:
>> > > >>
>> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
>> <+48%20660%20796%20129>>
>> > > >>>> > [image: Polidea] <https://www.polidea.com/>
>> > > >>>>
>> > > >>>
>> > > >>>
>> > > >>> --
>> > > >>>
>> > > >>> Jarek Potiuk
>> > > >>> Polidea <https://www.polidea.com/> | Principal Software
>Engineer
>> > > >>>
>> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>> <+48%20660%20796%20129>>
>> > > >>> [image: Polidea] <https://www.polidea.com/>
>> > > >>>
>> > > >>>
>> > > >
>> > > > --
>> > > >
>> > > > Jarek Potiuk
>> > > > Polidea <https://www.polidea.com/> | Principal Software
>Engineer
>> > > >
>> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>> <+48%20660%20796%20129>>
>> > > > [image: Polidea] <https://www.polidea.com/>
>> > > >
>> > > >
>> > >
>> > > --
>> > >
>> > > Jarek Potiuk
>> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
>> > >
>> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>> <+48%20660%20796%20129>>
>> > > [image: Polidea] <https://www.polidea.com/>
>> > >
>> >
>>
>>
>> --
>>
>> Jarek Potiuk
>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>
>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
>> <+48%20660%20796%20129>>
>> [image: Polidea] <https://www.polidea.com/>
>>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Aizhamal Nurmamat kyzy <ai...@apache.org>]

+1 on GitHub Actions.

On Mon, Dec 9, 2019 at 2:10 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> I am all for it! GitLab has been less-than helpful so far and recently it
> seems that running PRs from forks will only be run in Enterrprise Edition,
> which is less than welcome. I am quite a bit disappointed with the pace and
> attitude. Github Actions seems to be much better choice - especially that
> they are closely integrated with Github repo and seem to get
> attention/focus from Github/Microsoft.
>
> And they added self-hosted runners as well, which makes it possible for us
> to optimise the experience.
>
> J.
>
>
> J.
>
> On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com>
> wrote:
>
> > Hi all,
> >
> > It sometime since we last discussed using other CI than Travis. One of
> the
> > main reasons behind considering Gitlab CI was its ability to work on
> > self-hosted runner. However, over time of few long weeks Github Actions
> > matured enough to allow using self-hosted runners!
> >
> > Github Actions are still growing but using them have few big advantages:
> > - they are Github natives
> > - forking repo and enabling actions will run CI on your fork
> automatically
> > - variety of actions (PR checks, greetings, etc)
> >
> > I put together a PoC of CI in our internal repo:
> > https://github.com/PolideaInternal/airflow/pull/542
> > My impression is quite good. I like information about steps successes at
> > the PR level (no need to go to CI to check which step failed). The build
> > log view is a little bit clumsy but it works.
> >
> > Does any of you have any experience with Github Actions? Any thoughts
> > about using it?
> >
> > Best,
> > Tomek
> >
> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com> wrote:
> > > FYI: Interesting article about the history behind GitLabCI (featuring
> > > Kamil, my friend).
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > >
> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk <Ja...@polidea.com>
> > > wrote:
> > >
> > > > Some update on my GitLab experiences so far:
> > > >
> > > > TL;DR; I think the POC has shown that we can fairly easily replicate
> > the
> > > > CI in GitLab + Kubernetes. I think i can say - it generally works, I
> > can
> > > > plug it in for master/v1-10-test builds in the main Airflow project
> > for a
> > > > few weeks to see how it is doing (while I am no holidays) and once we
> > see
> > > > it running and get the support for PRs from GitLab we can switch to
> it.
> > > >
> > > > What do you think ? Should i call a vote or just try to set it up ?
> > > >
> > > > Some details
> > > >
> > > >    - I manged to get full working builds in GitLabCI + kubernetes -
> > > >    without the kubernetes-specific tests yet, but this should be
> > rather easy
> > > >    with kind (looking at it next):
> > > >    - Working example here - you can take a look and compare the
> UI/how
> > it
> > > >    is to navigate, comparing to Travis etc:
> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > >    - Per-job it is a bit slower than Travis so far (still around 35
> > > >    minutes in total), but I plan to optimise it further. I can play
> > with
> > > >    memory/cpu settings of individual workers (Got some reasonable
> > values now),
> > > >    I can use local SSD disk as Docker storage/logs/etc
> > > >    - I got an approval for 72vCPU quota (up for initial 24) - that
> > should
> > > >    let us build 3 builds in parallel independently from each other.
> > > >    - I managed to get Preemptible nodes working (we have built in
> retry
> > > >    mechanism in GitLab to work in case of system failures like that
> > > >    - Current spending with > 120 builds is 40 USD. We should be way
> > below
> > > >    500 USD/month according to my back-of-the-envelope calculations.
> > Likely
> > > >    well below
> > > >    - The current setup does not use GCR as cache and Kaniko as I
> > > >    originally planned. GCR would require custom authentication (and
> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
> > multi-staging
> > > >    builds (cache does not work
> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682). I
> > updated
> > > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > to
> > > >    reflect that.
> > > >    - We only use GCR as mirroring of DockerHub - so that we can have
> > > >    reliable downloads not depending on DockerHub's stability (it has
> > problems
> > > >    sometimes)
> > > >    - All in-all, it's GCP-independent. It could be run in any
> > Kubernetes
> > > >    cluster (some optimisations like local volumes mounting for docker
> > engine
> > > >    might have GCP-specific assumptions, but should be generally
> > replicable).
> > > >    - You can take a look at the current source code in
> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > >    - There will be some updates (I will get rid of custom builder
> > Docker,
> > > >    simplify it a bit and implement kubernetes tests) - it's mostly
> some
> > > >    cleanups + removal of Travis-Specific variables + gitlab.ci yaml
> > with
> > > >    job definitions.
> > > >
> > > > J.
> > > >
> > > >
> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > Jarek.Potiuk@polidea.com>
> > > > wrote:
> > > >
> > > >> So GitLab already works on automatically running builds from for PRs
> > :).
> > > >>
> > > >> Kamil got involved and will be out advocate on it:
> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > >> J.
> > > >>
> > > >> Principal Software Engineer
> > > >> Phone: +48660796129 <+48%20660%20796%20129>
> > > >>
> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > Jarek.Potiuk@polidea.com>
> > > >> napisał:
> > > >>
> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > > >>>> > [image: Polidea] <https://www.polidea.com/>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> Jarek Potiuk
> > > >>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >>>
> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > > >>> [image: Polidea] <https://www.polidea.com/>
> > > >>>
> > > >>>
> > > >
> > > > --
> > > >
> > > > Jarek Potiuk
> > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >
> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > > > [image: Polidea] <https://www.polidea.com/>
> > > >
> > > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> [image: Polidea] <https://www.polidea.com/>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

I am all for it! GitLab has been less-than helpful so far and recently it
seems that running PRs from forks will only be run in Enterrprise Edition,
which is less than welcome. I am quite a bit disappointed with the pace and
attitude. Github Actions seems to be much better choice - especially that
they are closely integrated with Github repo and seem to get
attention/focus from Github/Microsoft.

And they added self-hosted runners as well, which makes it possible for us
to optimise the experience.

J.


J.

On Mon, Dec 9, 2019 at 10:57 PM Tomasz Urbaszek <to...@polidea.com>
wrote:

> Hi all,
>
> It sometime since we last discussed using other CI than Travis. One of the
> main reasons behind considering Gitlab CI was its ability to work on
> self-hosted runner. However, over time of few long weeks Github Actions
> matured enough to allow using self-hosted runners!
>
> Github Actions are still growing but using them have few big advantages:
> - they are Github natives
> - forking repo and enabling actions will run CI on your fork automatically
> - variety of actions (PR checks, greetings, etc)
>
> I put together a PoC of CI in our internal repo:
> https://github.com/PolideaInternal/airflow/pull/542
> My impression is quite good. I like information about steps successes at
> the PR level (no need to go to CI to check which step failed). The build
> log view is a little bit clumsy but it works.
>
> Does any of you have any experience with Github Actions? Any thoughts
> about using it?
>
> Best,
> Tomek
>
> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com> wrote:
> > FYI: Interesting article about the history behind GitLabCI (featuring
> > Kamil, my friend).
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> >
> > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Some update on my GitLab experiences so far:
> > >
> > > TL;DR; I think the POC has shown that we can fairly easily replicate
> the
> > > CI in GitLab + Kubernetes. I think i can say - it generally works, I
> can
> > > plug it in for master/v1-10-test builds in the main Airflow project
> for a
> > > few weeks to see how it is doing (while I am no holidays) and once we
> see
> > > it running and get the support for PRs from GitLab we can switch to it.
> > >
> > > What do you think ? Should i call a vote or just try to set it up ?
> > >
> > > Some details
> > >
> > >    - I manged to get full working builds in GitLabCI + kubernetes -
> > >    without the kubernetes-specific tests yet, but this should be
> rather easy
> > >    with kind (looking at it next):
> > >    - Working example here - you can take a look and compare the UI/how
> it
> > >    is to navigate, comparing to Travis etc:
> > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > >    - Per-job it is a bit slower than Travis so far (still around 35
> > >    minutes in total), but I plan to optimise it further. I can play
> with
> > >    memory/cpu settings of individual workers (Got some reasonable
> values now),
> > >    I can use local SSD disk as Docker storage/logs/etc
> > >    - I got an approval for 72vCPU quota (up for initial 24) - that
> should
> > >    let us build 3 builds in parallel independently from each other.
> > >    - I managed to get Preemptible nodes working (we have built in retry
> > >    mechanism in GitLab to work in case of system failures like that
> > >    - Current spending with > 120 builds is 40 USD. We should be way
> below
> > >    500 USD/month according to my back-of-the-envelope calculations.
> Likely
> > >    well below
> > >    - The current setup does not use GCR as cache and Kaniko as I
> > >    originally planned. GCR would require custom authentication (and
> > >    easy-to-steal secrets) and Kaniko does not yet well handle
> multi-staging
> > >    builds (cache does not work
> > >    https://github.com/GoogleContainerTools/kaniko/issues/682). I
> updated
> > >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> to
> > >    reflect that.
> > >    - We only use GCR as mirroring of DockerHub - so that we can have
> > >    reliable downloads not depending on DockerHub's stability (it has
> problems
> > >    sometimes)
> > >    - All in-all, it's GCP-independent. It could be run in any
> Kubernetes
> > >    cluster (some optimisations like local volumes mounting for docker
> engine
> > >    might have GCP-specific assumptions, but should be generally
> replicable).
> > >    - You can take a look at the current source code in
> > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > >    - There will be some updates (I will get rid of custom builder
> Docker,
> > >    simplify it a bit and implement kubernetes tests) - it's mostly some
> > >    cleanups + removal of Travis-Specific variables + gitlab.ci yaml
> with
> > >    job definitions.
> > >
> > > J.
> > >
> > >
> > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > > wrote:
> > >
> > >> So GitLab already works on automatically running builds from for PRs
> :).
> > >>
> > >> Kamil got involved and will be out advocate on it:
> > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > >> J.
> > >>
> > >> Principal Software Engineer
> > >> Phone: +48660796129
> > >>
> > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > >> napisał:
> > >>
> > >>> 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.bregula@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.Potiuk@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/>
> > >>>
> > >>>
> > >
> > > --
> > >
> > > 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/>
> >
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <to...@polidea.com>]

By default builds are run on Github runners. A public repo has 2000 minutes
monthly,
that's definitely not enough for us. But having having GCP resources
 donated to us
we should be able to overcome this problem.

T.

On Mon, Dec 9, 2019 at 11:02 PM Pablo Estrada <pa...@google.com.invalid>
wrote:

> That looks pretty cool! It helps that they're github native. Where does the
> compute power come from? Is it provided by github?
>
> On Mon, Dec 9, 2019 at 1:57 PM Tomasz Urbaszek <
> tomasz.urbaszek@polidea.com>
> wrote:
>
> > Hi all,
> >
> > It sometime since we last discussed using other CI than Travis. One of
> the
> > main reasons behind considering Gitlab CI was its ability to work on
> > self-hosted runner. However, over time of few long weeks Github Actions
> > matured enough to allow using self-hosted runners!
> >
> > Github Actions are still growing but using them have few big advantages:
> > - they are Github natives
> > - forking repo and enabling actions will run CI on your fork
> automatically
> > - variety of actions (PR checks, greetings, etc)
> >
> > I put together a PoC of CI in our internal repo:
> > https://github.com/PolideaInternal/airflow/pull/542
> > My impression is quite good. I like information about steps successes at
> > the PR level (no need to go to CI to check which step failed). The build
> > log view is a little bit clumsy but it works.
> >
> > Does any of you have any experience with Github Actions? Any thoughts
> > about using it?
> >
> > Best,
> > Tomek
> >
> > On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com> wrote:
> > > FYI: Interesting article about the history behind GitLabCI (featuring
> > > Kamil, my friend).
> > >
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> > >
> > > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk <Ja...@polidea.com>
> > > wrote:
> > >
> > > > Some update on my GitLab experiences so far:
> > > >
> > > > TL;DR; I think the POC has shown that we can fairly easily replicate
> > the
> > > > CI in GitLab + Kubernetes. I think i can say - it generally works, I
> > can
> > > > plug it in for master/v1-10-test builds in the main Airflow project
> > for a
> > > > few weeks to see how it is doing (while I am no holidays) and once we
> > see
> > > > it running and get the support for PRs from GitLab we can switch to
> it.
> > > >
> > > > What do you think ? Should i call a vote or just try to set it up ?
> > > >
> > > > Some details
> > > >
> > > >    - I manged to get full working builds in GitLabCI + kubernetes -
> > > >    without the kubernetes-specific tests yet, but this should be
> > rather easy
> > > >    with kind (looking at it next):
> > > >    - Working example here - you can take a look and compare the
> UI/how
> > it
> > > >    is to navigate, comparing to Travis etc:
> > > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > > >    - Per-job it is a bit slower than Travis so far (still around 35
> > > >    minutes in total), but I plan to optimise it further. I can play
> > with
> > > >    memory/cpu settings of individual workers (Got some reasonable
> > values now),
> > > >    I can use local SSD disk as Docker storage/logs/etc
> > > >    - I got an approval for 72vCPU quota (up for initial 24) - that
> > should
> > > >    let us build 3 builds in parallel independently from each other.
> > > >    - I managed to get Preemptible nodes working (we have built in
> retry
> > > >    mechanism in GitLab to work in case of system failures like that
> > > >    - Current spending with > 120 builds is 40 USD. We should be way
> > below
> > > >    500 USD/month according to my back-of-the-envelope calculations.
> > Likely
> > > >    well below
> > > >    - The current setup does not use GCR as cache and Kaniko as I
> > > >    originally planned. GCR would require custom authentication (and
> > > >    easy-to-steal secrets) and Kaniko does not yet well handle
> > multi-staging
> > > >    builds (cache does not work
> > > >    https://github.com/GoogleContainerTools/kaniko/issues/682). I
> > updated
> > > >
> >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> > to
> > > >    reflect that.
> > > >    - We only use GCR as mirroring of DockerHub - so that we can have
> > > >    reliable downloads not depending on DockerHub's stability (it has
> > problems
> > > >    sometimes)
> > > >    - All in-all, it's GCP-independent. It could be run in any
> > Kubernetes
> > > >    cluster (some optimisations like local volumes mounting for docker
> > engine
> > > >    might have GCP-specific assumptions, but should be generally
> > replicable).
> > > >    - You can take a look at the current source code in
> > > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > > >    - There will be some updates (I will get rid of custom builder
> > Docker,
> > > >    simplify it a bit and implement kubernetes tests) - it's mostly
> some
> > > >    cleanups + removal of Travis-Specific variables + gitlab.ci yaml
> > with
> > > >    job definitions.
> > > >
> > > > J.
> > > >
> > > >
> > > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> > Jarek.Potiuk@polidea.com>
> > > > wrote:
> > > >
> > > >> So GitLab already works on automatically running builds from for PRs
> > :).
> > > >>
> > > >> Kamil got involved and will be out advocate on it:
> > > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > > >> J.
> > > >>
> > > >> Principal Software Engineer
> > > >> Phone: +48660796129 <+48%20660%20796%20129>
> > > >>
> > > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> > Jarek.Potiuk@polidea.com>
> > > >> napisał:
> > > >>
> > > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> > <+48%20660%20796%20129>>
> > > >>>> > [image: Polidea] <https://www.polidea.com/>
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>>
> > > >>> Jarek Potiuk
> > > >>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >>>
> > > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > <+48%20660%20796%20129>>
> > > >>> [image: Polidea] <https://www.polidea.com/>
> > > >>>
> > > >>>
> > > >
> > > > --
> > > >
> > > > Jarek Potiuk
> > > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > > >
> > > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > <+48%20660%20796%20129>>
> > > > [image: Polidea] <https://www.polidea.com/>
> > > >
> > > >
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> > <+48%20660%20796%20129>>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> >
>


-- 

Tomasz Urbaszek
Polidea <https://www.polidea.com/> | Junior Software Engineer

M: +48 505 628 493 <+48505628493>
E: tomasz.urbaszek@polidea.com <to...@polidea.com>

Unique Tech
Check out our projects! <https://www.polidea.com/our-work>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Pablo Estrada <pa...@google.com.INVALID>]

That looks pretty cool! It helps that they're github native. Where does the
compute power come from? Is it provided by github?

On Mon, Dec 9, 2019 at 1:57 PM Tomasz Urbaszek <to...@polidea.com>
wrote:

> Hi all,
>
> It sometime since we last discussed using other CI than Travis. One of the
> main reasons behind considering Gitlab CI was its ability to work on
> self-hosted runner. However, over time of few long weeks Github Actions
> matured enough to allow using self-hosted runners!
>
> Github Actions are still growing but using them have few big advantages:
> - they are Github natives
> - forking repo and enabling actions will run CI on your fork automatically
> - variety of actions (PR checks, greetings, etc)
>
> I put together a PoC of CI in our internal repo:
> https://github.com/PolideaInternal/airflow/pull/542
> My impression is quite good. I like information about steps successes at
> the PR level (no need to go to CI to check which step failed). The build
> log view is a little bit clumsy but it works.
>
> Does any of you have any experience with Github Actions? Any thoughts
> about using it?
>
> Best,
> Tomek
>
> On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com> wrote:
> > FYI: Interesting article about the history behind GitLabCI (featuring
> > Kamil, my friend).
> >
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> >
> > On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > Some update on my GitLab experiences so far:
> > >
> > > TL;DR; I think the POC has shown that we can fairly easily replicate
> the
> > > CI in GitLab + Kubernetes. I think i can say - it generally works, I
> can
> > > plug it in for master/v1-10-test builds in the main Airflow project
> for a
> > > few weeks to see how it is doing (while I am no holidays) and once we
> see
> > > it running and get the support for PRs from GitLab we can switch to it.
> > >
> > > What do you think ? Should i call a vote or just try to set it up ?
> > >
> > > Some details
> > >
> > >    - I manged to get full working builds in GitLabCI + kubernetes -
> > >    without the kubernetes-specific tests yet, but this should be
> rather easy
> > >    with kind (looking at it next):
> > >    - Working example here - you can take a look and compare the UI/how
> it
> > >    is to navigate, comparing to Travis etc:
> > >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> > >    - Per-job it is a bit slower than Travis so far (still around 35
> > >    minutes in total), but I plan to optimise it further. I can play
> with
> > >    memory/cpu settings of individual workers (Got some reasonable
> values now),
> > >    I can use local SSD disk as Docker storage/logs/etc
> > >    - I got an approval for 72vCPU quota (up for initial 24) - that
> should
> > >    let us build 3 builds in parallel independently from each other.
> > >    - I managed to get Preemptible nodes working (we have built in retry
> > >    mechanism in GitLab to work in case of system failures like that
> > >    - Current spending with > 120 builds is 40 USD. We should be way
> below
> > >    500 USD/month according to my back-of-the-envelope calculations.
> Likely
> > >    well below
> > >    - The current setup does not use GCR as cache and Kaniko as I
> > >    originally planned. GCR would require custom authentication (and
> > >    easy-to-steal secrets) and Kaniko does not yet well handle
> multi-staging
> > >    builds (cache does not work
> > >    https://github.com/GoogleContainerTools/kaniko/issues/682). I
> updated
> > >
> https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
> to
> > >    reflect that.
> > >    - We only use GCR as mirroring of DockerHub - so that we can have
> > >    reliable downloads not depending on DockerHub's stability (it has
> problems
> > >    sometimes)
> > >    - All in-all, it's GCP-independent. It could be run in any
> Kubernetes
> > >    cluster (some optimisations like local volumes mounting for docker
> engine
> > >    might have GCP-specific assumptions, but should be generally
> replicable).
> > >    - You can take a look at the current source code in
> > >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> > >    - There will be some updates (I will get rid of custom builder
> Docker,
> > >    simplify it a bit and implement kubernetes tests) - it's mostly some
> > >    cleanups + removal of Travis-Specific variables + gitlab.ci yaml
> with
> > >    job definitions.
> > >
> > > J.
> > >
> > >
> > > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > > wrote:
> > >
> > >> So GitLab already works on automatically running builds from for PRs
> :).
> > >>
> > >> Kamil got involved and will be out advocate on it:
> > >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> > >> J.
> > >>
> > >> Principal Software Engineer
> > >> Phone: +48660796129 <+48%20660%20796%20129>
> > >>
> > >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > >> napisał:
> > >>
> > >>> 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.bregula@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.Potiuk@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 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > >>>> > [image: Polidea] <https://www.polidea.com/>
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>>
> > >>> Jarek Potiuk
> > >>> Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >>>
> > >>> M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > >>> [image: Polidea] <https://www.polidea.com/>
> > >>>
> > >>>
> > >
> > > --
> > >
> > > Jarek Potiuk
> > > Polidea <https://www.polidea.com/> | Principal Software Engineer
> > >
> > > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > > [image: Polidea] <https://www.polidea.com/>
> > >
> > >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48%20660%20796%20129> <+48660796129
> <+48%20660%20796%20129>>
> > [image: Polidea] <https://www.polidea.com/>
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Tomasz Urbaszek <to...@polidea.com>]

Hi all,

It sometime since we last discussed using other CI than Travis. One of the main reasons behind considering Gitlab CI was its ability to work on self-hosted runner. However, over time of few long weeks Github Actions matured enough to allow using self-hosted runners!

Github Actions are still growing but using them have few big advantages:
- they are Github natives
- forking repo and enabling actions will run CI on your fork automatically
- variety of actions (PR checks, greetings, etc)

I put together a PoC of CI in our internal repo: https://github.com/PolideaInternal/airflow/pull/542
My impression is quite good. I like information about steps successes at the PR level (no need to go to CI to check which step failed). The build log view is a little bit clumsy but it works.

Does any of you have any experience with Github Actions? Any thoughts about using it?

Best,
Tomek

On 2019/08/09 13:55:11, Jarek Potiuk <Ja...@polidea.com> wrote: 
> FYI: Interesting article about the history behind GitLabCI (featuring
> Kamil, my friend).
> https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk
> 
> On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
> 
> > Some update on my GitLab experiences so far:
> >
> > TL;DR; I think the POC has shown that we can fairly easily replicate the
> > CI in GitLab + Kubernetes. I think i can say - it generally works, I can
> > plug it in for master/v1-10-test builds in the main Airflow project for a
> > few weeks to see how it is doing (while I am no holidays) and once we see
> > it running and get the support for PRs from GitLab we can switch to it.
> >
> > What do you think ? Should i call a vote or just try to set it up ?
> >
> > Some details
> >
> >    - I manged to get full working builds in GitLabCI + kubernetes -
> >    without the kubernetes-specific tests yet, but this should be rather easy
> >    with kind (looking at it next):
> >    - Working example here - you can take a look and compare the UI/how it
> >    is to navigate, comparing to Travis etc:
> >    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
> >    - Per-job it is a bit slower than Travis so far (still around 35
> >    minutes in total), but I plan to optimise it further. I can play with
> >    memory/cpu settings of individual workers (Got some reasonable values now),
> >    I can use local SSD disk as Docker storage/logs/etc
> >    - I got an approval for 72vCPU quota (up for initial 24) - that should
> >    let us build 3 builds in parallel independently from each other.
> >    - I managed to get Preemptible nodes working (we have built in retry
> >    mechanism in GitLab to work in case of system failures like that
> >    - Current spending with > 120 builds is 40 USD. We should be way below
> >    500 USD/month according to my back-of-the-envelope calculations. Likely
> >    well below
> >    - The current setup does not use GCR as cache and Kaniko as I
> >    originally planned. GCR would require custom authentication (and
> >    easy-to-steal secrets) and Kaniko does not yet well handle multi-staging
> >    builds (cache does not work
> >    https://github.com/GoogleContainerTools/kaniko/issues/682). I updated
> >    https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI to
> >    reflect that.
> >    - We only use GCR as mirroring of DockerHub - so that we can have
> >    reliable downloads not depending on DockerHub's stability (it has problems
> >    sometimes)
> >    - All in-all, it's GCP-independent. It could be run in any Kubernetes
> >    cluster (some optimisations like local volumes mounting for docker engine
> >    might have GCP-specific assumptions, but should be generally replicable).
> >    - You can take a look at the current source code in
> >    https://github.com/potiuk/airflow/commits/test-gitlab-ci
> >    - There will be some updates (I will get rid of custom builder Docker,
> >    simplify it a bit and implement kubernetes tests) - it's mostly some
> >    cleanups + removal of Travis-Specific variables + gitlab.ci yaml with
> >    job definitions.
> >
> > J.
> >
> >
> > On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> >> So GitLab already works on automatically running builds from for PRs :).
> >>
> >> Kamil got involved and will be out advocate on it:
> >> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> >> J.
> >>
> >> Principal Software Engineer
> >> Phone: +48660796129
> >>
> >> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <Ja...@polidea.com>
> >> napisał:
> >>
> >>> 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 <ka...@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 <Ja...@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/>
> >>>
> >>>
> >
> > --
> >
> > 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/>
> 

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

FYI: Interesting article about the history behind GitLabCI (featuring
Kamil, my friend).
https://about.gitlab.com/2019/08/08/built-in-ci-cd-version-control-secret/?fbclid=IwAR2tEfqLaDXTCd1mD6XUZMX7hGYBfZcohPtI2BP3-oK_Yk_EHIXF4zLDixk

On Mon, Aug 5, 2019 at 7:14 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> Some update on my GitLab experiences so far:
>
> TL;DR; I think the POC has shown that we can fairly easily replicate the
> CI in GitLab + Kubernetes. I think i can say - it generally works, I can
> plug it in for master/v1-10-test builds in the main Airflow project for a
> few weeks to see how it is doing (while I am no holidays) and once we see
> it running and get the support for PRs from GitLab we can switch to it.
>
> What do you think ? Should i call a vote or just try to set it up ?
>
> Some details
>
>    - I manged to get full working builds in GitLabCI + kubernetes -
>    without the kubernetes-specific tests yet, but this should be rather easy
>    with kind (looking at it next):
>    - Working example here - you can take a look and compare the UI/how it
>    is to navigate, comparing to Travis etc:
>    https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
>    - Per-job it is a bit slower than Travis so far (still around 35
>    minutes in total), but I plan to optimise it further. I can play with
>    memory/cpu settings of individual workers (Got some reasonable values now),
>    I can use local SSD disk as Docker storage/logs/etc
>    - I got an approval for 72vCPU quota (up for initial 24) - that should
>    let us build 3 builds in parallel independently from each other.
>    - I managed to get Preemptible nodes working (we have built in retry
>    mechanism in GitLab to work in case of system failures like that
>    - Current spending with > 120 builds is 40 USD. We should be way below
>    500 USD/month according to my back-of-the-envelope calculations. Likely
>    well below
>    - The current setup does not use GCR as cache and Kaniko as I
>    originally planned. GCR would require custom authentication (and
>    easy-to-steal secrets) and Kaniko does not yet well handle multi-staging
>    builds (cache does not work
>    https://github.com/GoogleContainerTools/kaniko/issues/682). I updated
>    https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI to
>    reflect that.
>    - We only use GCR as mirroring of DockerHub - so that we can have
>    reliable downloads not depending on DockerHub's stability (it has problems
>    sometimes)
>    - All in-all, it's GCP-independent. It could be run in any Kubernetes
>    cluster (some optimisations like local volumes mounting for docker engine
>    might have GCP-specific assumptions, but should be generally replicable).
>    - You can take a look at the current source code in
>    https://github.com/potiuk/airflow/commits/test-gitlab-ci
>    - There will be some updates (I will get rid of custom builder Docker,
>    simplify it a bit and implement kubernetes tests) - it's mostly some
>    cleanups + removal of Travis-Specific variables + gitlab.ci yaml with
>    job definitions.
>
> J.
>
>
> On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
>> So GitLab already works on automatically running builds from for PRs :).
>>
>> Kamil got involved and will be out advocate on it:
>> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
>> J.
>>
>> Principal Software Engineer
>> Phone: +48660796129
>>
>> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <Ja...@polidea.com>
>> napisał:
>>
>>> 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 <ka...@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 <Ja...@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/>
>>>
>>>
>
> --
>
> 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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

Some update on my GitLab experiences so far:

TL;DR; I think the POC has shown that we can fairly easily replicate the CI
in GitLab + Kubernetes. I think i can say - it generally works, I can plug
it in for master/v1-10-test builds in the main Airflow project for a few
weeks to see how it is doing (while I am no holidays) and once we see it
running and get the support for PRs from GitLab we can switch to it.

What do you think ? Should i call a vote or just try to set it up ?

Some details

   - I manged to get full working builds in GitLabCI + kubernetes - without
   the kubernetes-specific tests yet, but this should be rather easy with kind
   (looking at it next):
   - Working example here - you can take a look and compare the UI/how it
   is to navigate, comparing to Travis etc:
   https://gitlab.com/Jarek.Potiuk/airflow/pipelines/74625817
   - Per-job it is a bit slower than Travis so far (still around 35 minutes
   in total), but I plan to optimise it further. I can play with memory/cpu
   settings of individual workers (Got some reasonable values now), I can use
   local SSD disk as Docker storage/logs/etc
   - I got an approval for 72vCPU quota (up for initial 24) - that should
   let us build 3 builds in parallel independently from each other.
   - I managed to get Preemptible nodes working (we have built in retry
   mechanism in GitLab to work in case of system failures like that
   - Current spending with > 120 builds is 40 USD. We should be way below
   500 USD/month according to my back-of-the-envelope calculations. Likely
   well below
   - The current setup does not use GCR as cache and Kaniko as I originally
   planned. GCR would require custom authentication (and easy-to-steal
   secrets) and Kaniko does not yet well handle multi-staging builds (cache
   does not work https://github.com/GoogleContainerTools/kaniko/issues/682).
   I updated
   https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-23+Migrate+out+of+Travis+CI
to
   reflect that.
   - We only use GCR as mirroring of DockerHub - so that we can have
   reliable downloads not depending on DockerHub's stability (it has problems
   sometimes)
   - All in-all, it's GCP-independent. It could be run in any Kubernetes
   cluster (some optimisations like local volumes mounting for docker engine
   might have GCP-specific assumptions, but should be generally replicable).
   - You can take a look at the current source code in
   https://github.com/potiuk/airflow/commits/test-gitlab-ci
   - There will be some updates (I will get rid of custom builder Docker,
   simplify it a bit and implement kubernetes tests) - it's mostly some
   cleanups + removal of Travis-Specific variables + gitlab.ci yaml with
   job definitions.

J.


On Wed, Jul 31, 2019 at 10:57 AM Jarek Potiuk <Ja...@polidea.com>
wrote:

> So GitLab already works on automatically running builds from for PRs :).
>
> Kamil got involved and will be out advocate on it:
> https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
> J.
>
> Principal Software Engineer
> Phone: +48660796129
>
> pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <Ja...@polidea.com>
> napisał:
>
>> 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 <ka...@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 <Ja...@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/>
>>
>>

-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

So GitLab already works on automatically running builds from for PRs :).

Kamil got involved and will be out advocate on it:
https://gitlab.com/gitlab-org/gitlab-ce/issues/65139
J.

Principal Software Engineer
Phone: +48660796129

pt., 26 lip 2019, 18:12 użytkownik Jarek Potiuk <Ja...@polidea.com>
napisał:

> 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 <ka...@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 <Ja...@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/>
>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

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 <ka...@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 <Ja...@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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kamil Breguła <ka...@polidea.com>]

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 <Ja...@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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Philippe Gagnon <ph...@gmail.com>]

I think that Jarek is proposing switching to Kaniko for security
considerations as GKE workloads run in OS containers (so they do not
benefit from hardware virtualization sandboxing) and docker build requires
root privileges.

In any case, Kaniko is not tied in any way to Google Cloud, so the build
infrastructure could be migrated to a new platform without problem.

On Tue, Jul 23, 2019 at 3:42 PM Shah Altaf <me...@gmail.com> wrote:

> Hi that's a nice writeup, easy to follow.  Also I like your diagram.
>
> Question - what is the purpose of introducing kaniko instead of using
> regular docker build?
> I'm asking in line with the consideration "The system should be
> self-maintainable - with as little special Development/Ops maintenance
> needed." ,
> Though kaniko is an open source project, if its purpose here can be done
> simply with the regular docker commands, that's fewer moving parts and a
> lower overhead for maintenance as well as the future.
>
> The reason for mentioning the future - considering how Travis has
> deteriorated and is pretty much forcing a move away, it's worth learning
> from, and any new build pipeline would benefit from being as agnostic as
> possible, with as few pieces as possible.
>
>
> Regards
> Shah
>
>
>
>
> On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <Ja...@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/>
> >
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

On Fri, Jul 26, 2019 at 11:35 AM Kamil Breguła <ka...@polidea.com>
wrote:

> Response inline.
>
> On Fri, Jul 26, 2019 at 10:58 AM Driesprong, Fokko <fo...@driesprong.frl>
> wrote:
> >
> > Nice document Jarek.
> >
> > We should look at the pro's and con's regarding moving away from Travis.
> > The process for Airflow, and also many other OSS projects, is to first
> > develop on your local fork. If everything looks good, open a PR to the
> main
> > repo. This reduces the noise we have on the project itself. Being more
> > strict on this will also reduce the load on the CI service of Apache.
> >
> We do not plan to delete Travis support. We will continue to support
> him. Working on forks will still look the same, but will allow you to
> perform tasks on apache/airflow. Travis behaves very unpredictably
> when it comes to resource allocation. Sometimes jobs wait in queue for
> 8 hours before they are performed. It is not promised that this
> problem will be solved in any way. Apache Infra is aware of Travis'
> limitations, but we are unable to find a solution to this problem
> together.
>

As Kamil mentioned - one of the important considerations was to keep Travis
CI integration. It's probably easiest that people use their own Travis
forks. We have little to no control over what happens when Travis has
problem (as evidenced clearly by last week's problems) and I personally
would prefer to be able to switch easily. One important thing - one of the
most important features of AIP-10 that I worked on so long, was to make all
the tests docker-native, which means that we do not have to rely on any
specific CI, but we can use either of them with literally few days of work
of switching the build configuration. It really makes us CI-provider
independent. Which is great because in case of problems like we have this
week we can do some workarounds - and generally react quickly to unblock
our community.

Unfortunately - the infrastructure we have on Travis CI is shared between
different projects and it's their problems affect us as well. And Apache
Infrastructure does not want to make any investments into making the
infrastructure of Travis CI better for us. They specifically ignored my
requests to do some kind of compromised approach that I proposed. I am
actually very upset by that, because I thought I was actually very polite
and constructive and proposed some reasonable compromise/ideas on
improvements and got a blunt *"NO"* and got further ignored by Apache
infrastructure when I proposed some compromises/workarounds for current
Travis CI infrastructure. Here is permalink to our discussion where i got
"no, we won't lift the current limits. period" as an answer:
https://lists.apache.org/thread.html/0e8c1ddd9384e6b8b77db7e7c1ff8ee95a53412bccf722f9c372195a@%3Cbuilds.apache.org%3E
.
My judgment from the answer of Greg Stein from Apache Infra is that we
cannot expect any reasonable solution from the Infra side to make Travis
better for us. Correct me please, If I am wrong, and maybe you have some
more influence at Apache Infra. I was actually for a few days trying to
think out a good answer to that - one that will show respect but will
clearly say that I do not like the approach of Apache infrastructure. But I
want to wait until my anger passes and I find the right words (and have
alternative for Airflow in case my answer causes - unintentionally -
escalation or conflict with the infra team on that ground).


>
> > A couple of thoughts so far:
> > - I'm not sure why we need to store the images on the GCS. We could just
> > discard the image after the build? In the case of caching, we could also
> > store them on the local VM's as well. Just a thought to simplify the
> setup.
>

In order to speed up the build, we want to only rebuild the part of images
that needs to be rebuild. For that we need to get the latest images. We do
not have VMs in GCP - we have a Kubernetes Cluster with auto-scaling
enabled and pre-emptible instances in order to be able to cut down the cost
(it's about 30% to 50% cheaper by just using pre-emptible instances). This
means that those VMs that run our Pods will not live very long - in most
cases we will have just one master machine running and when several new
builds will come, the cluster will auto-scale up to 5 instances and then
will scale down back to 1 once the builds are complete. This is all
possible (and it's just configurable - no coding needed!) by using the
modern infrastructure - where GitLab is connected to a GKE-managed
Kubernetes cluster. This also means (it is the same what is done in Travis
currently) that you should expect a "clean" machine when you start your
build. Using registry (which is in the same data-center and you pay nothing
for transfer and pennies for storage) is the best way to populate your
docker image cache (and it is natively supported by the Kaniko builder -
which is the de-facto standard for building images in Kubernetes). The
images are stored in GCR (Google Container Registry) - it indeed uses GCS
internally, but the GCR is just a standard Docker image registry (following
the same API as DockerHub) which means that we are not really using any -
GCP-specific way of doing it. We could move to another provide (Azure, AWS,
DigitalOcean etc) change the URLs and our Docker builds on Kubernetes will
run equally well there. This is huge benefit as we are only using Open APIs
and frameworks that are available wherever we want (and they are already
foundation of current modern infrastructure pretty much everywhere). BTW.
We are eventually going to use local cache as well on the VMs - but this is
pure optimisation that might speed up the builds if the same VM in
Kubernetes is re-used several times. There is a support for this in Kaniko
and for now I really want to have a working POC that we can optimise.


> > - Since the current setup is flaky, it feels counterintuitive to make it
> > more complex, for example by mirroring the repository to Gitlab. How does
> > this work for PR's from forks (these repo's are still on a fork on
> Github)?
> > For example, when I open a PR from my Github fork, this fork does not
> live
> > in Gitlab.
>
The forks will leave in GitHub - they will just be built in GitLab CI.
Actually no workflow will be changed for anyone after they submit PR - just
notification that the build is "OK" will come from GitLab not from Travis
and it is in public UI of GitLab where you will be able to see the logs.


> > - I think it is important to discuss this with Infra as well, we need to
> > get them on board as well.
>

They are already on board. Here is a bit of context:

First of all there was a huge discussion in the build list:
https://lists.apache.org/thread.html/86b7a698a7b5ea73410a576510eada3632cf36e4b1a38f505c17d898@%3Cbuilds.apache.org%3E
about
problems with Travis and potential solutions. It was actually me who
proposed as a solution that all the "whale" project do whatever they can to
decrease the pressure on Travis. I also linked together Gitlab CI folks
with the people from Infrastructure and the people in GitLab CI are
interested in supporting Apache in moving to GitLab for similar causes. Our
project is pretty much a "Guinea Pig" for this kind of move. I also managed
to secure the funds from Google OSS team, which (from back-of-the-envelope
calculation) will keep us running for half a year and with promise that it
will turn into regular donation.
There was a separate discussion between me, Greg Stain from the Apache
Infrastructure, Kamil Trzciński (GitLab CI maintainer and Technical Lead)
and Raymond Paik (GitLab Community Manager) about this and the lat response
from Greg whether I need more permission/approval or anything from the
infra was: "Jarek: just start working through it. If/when you need
something from Infra, then we can chat about it."


> > - Are there other OSS projects which use this setup as well?
>
> Not yet, but we maintain direct contact with Apache Beam commiters.
> They are also interested in moving to a similar infrasture.
>

As Kamil mentioned - we are also talking to Apache Beam commiters (they
have another host of problems with Jenkins instance they have) - we are
closely cooperating with them and they are looking into our experiences
with GitLab to try similar approach with GKE cluster and GitLab CI. They
have currently 16 VMS of 16-core CPU donated by Google for them which is
sitting idle sometimes, and moving to auto-scaling Kubernetes
infrastructure and GitLab configuration + Kubernetes integration which is
way better than Jenkins is something they are very much looking at. Again -
we are a Guinea Pig of that move.


>
> > My personal opinion, apart from the issues we're facing the last few
> days,
> > Travis works quite well for me.
>
> I am afraid that the current problems will be repeated because we have
> cut resources by the Apache Infra team  We have only 5 workers. This
> means that only one pR is performed simultaneously on apache/airflow
> repo.
>

Sorry, but I think your case is a bit different than ours (and a number of
other people). The current infrastructure with Travis and 5 workers is
totally not scalable and it already limits us heavily. It took me *a week
(!!!!!)*  to merge five simple small fixes to the CI infrastructure because
those changes depended on each-other. And it was purely because of queuing
delays and Travis's problems, no problem with reviews (they were really
small one-line changes). If you are submitting one or two PRs at a time and
you switch to Airflow occasionally, you probably do not feel it as a
problem. But in our case when we have 3 people team working pretty much
full time on Airflow (we are switching back to this mode after working on
Oozie-2-Airflow) and gearing up for some major improvements in GCP operator
area, this will be hugely limiting factor if we keep the CI slowing us to
pretty much one PR a day (per team). This is the current speed we can get
and it is not sustainable at all.

>
> > Cheers, Fokko
> >
> > Op wo 24 jul. 2019 om 10:05 schreef Jarek Potiuk <
> Jarek.Potiuk@polidea.com>:
> >
> > > Of course ! One of the considerations is to keep travis CI build
> intact -
> > > so that anyone will be able to have their own Travis Fork for the time
> > > being.
> > >
> > > I will also do it in the way that once you have your own GCP account
> and
> > > your own GKE cluster, you will be able to replicate it as well (there
> will
> > > be instructions on how to set it up).
> > > We can even (long term) make it in the way that you will not need a
> > > separate GKE cluster but it will run using just your personal GitLab
> > > (free). This should be possible - I am really trying to make it
> > > underlying-infrastructure-agnostic.
> > >
> > > The non-cluster personal GitLab is not a priority now (Travis forks
> will
> > > hopefully work ;) so it might not work initially, but there aren't
> > > fundamental reasons it should not work. We will have to just use
> GitLabCI
> > > registry instead of the GCP one and avoid assuming we are running in
> the
> > > GKE cluster and have some secrets/accounts distributed differently. All
> > > looks doable.
> > >
> > > J.
> > >
> > >
> > > J.
> > >
> > > On Wed, Jul 24, 2019 at 9:03 AM Chao-Han Tsai <mi...@gmail.com>
> > > wrote:
> > >
> > > > Thanks Jarek for putting this together. We really need a stable and
> fast
> > > > CI.
> > > >
> > > > Question: will we still be able to build our personal fork of
> Airflow on
> > > > our own Travis?
> > > >
> > > > Chao-Han
> > > >
> > > > On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > > > wrote:
> > > >
> > > > > >
> > > > > > Question - what is the purpose of introducing kaniko instead of
> using
> > > > > > regular docker build?
> > > > > >
> > > > >
> > > > > Indeed. We want to be as agnostic as possible. What I plan to do
> is to
> > > > use
> > > > > Kubernetes Runner in GitlabCI. This means that all the jobs will
> run as
> > > > > Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
> > > > > orchestrates the builds. This means that our test jobs will be run
> > > inside
> > > > > docker - they will not run in virtual machine, but they will run
> inside
> > > > the
> > > > > container. This is how modern CI systems work (for example Gitlab,
> > > > > CloudBuild, also Argo <https://argoproj.github.io/> - new kid in
> the
> > > > block
> > > > > which is Kubernetes-Native). Argo is a bit too fresh to consider
> it,
> > > but
> > > > > they all work similarly - all steps are run inside docker.
> > > > >
> > > > > As the first part of our build we have to build the images with
> latest
> > > > > sources (and dependencies if needed) that then will be used for
> > > > subsequent
> > > > > steps. This means that we need to build the images from within
> docker -
> > > > > which is not as trivial as running docker command. There are three
> ways
> > > > to
> > > > > approach it - docker-in-docker (requires priviledged docker
> > > containers),
> > > > > using same docker engine which is used by Kubernetes Cluster (not
> > > > > recommended as Kubernetes manages docker engine on their own and
> might
> > > > > delete/remove images at any time) or use Kaniko. Kaniko was created
> > > > exactly
> > > > > for this purpose - to be able to run docker build from within a POD
> > > that
> > > > > runs in Kubernetes cluster.
> > > > >
> > > > > I hope it explains :). Kaniko is pretty much standard way of doing
> it
> > > and
> > > > > it really Kubernetes-native way of doing it.
> > > > >
> > > > >
> > > > > >
> > > > > > Regards
> > > > > > Shah
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <
> > > Jarek.Potiuk@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/>
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Chao-Han Tsai
> > > >
> > >
> > >
> > > --
> > >
> > > 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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Kamil Breguła <ka...@polidea.com>]

Response inline.

On Fri, Jul 26, 2019 at 10:58 AM Driesprong, Fokko <fo...@driesprong.frl> wrote:
>
> Nice document Jarek.
>
> We should look at the pro's and con's regarding moving away from Travis.
> The process for Airflow, and also many other OSS projects, is to first
> develop on your local fork. If everything looks good, open a PR to the main
> repo. This reduces the noise we have on the project itself. Being more
> strict on this will also reduce the load on the CI service of Apache.
>
We do not plan to delete Travis support. We will continue to support
him. Working on forks will still look the same, but will allow you to
perform tasks on apache/airflow. Travis behaves very unpredictably
when it comes to resource allocation. Sometimes jobs wait in queue for
8 hours before they are performed. It is not promised that this
problem will be solved in any way. Apache Infra is aware of Travis'
limitations, but we are unable to find a solution to this problem
together.

> A couple of thoughts so far:
> - I'm not sure why we need to store the images on the GCS. We could just
> discard the image after the build? In the case of caching, we could also
> store them on the local VM's as well. Just a thought to simplify the setup.

It will be difficult to store the Docker image locally if we want to
share it between jobs. This is helpful because it allows us to create
configurations of specific test sets that will run independently of
the others.
Reference: https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-4+Support+for+System+Tests+for+external+systems
Currently, we already have a number of system tests. Unfortunately,
they are only performed on Polidea Infrastructure.  We received
resources from Google, which allow you to perform these tests also on
the master branch

> - Since the current setup is flaky, it feels counterintuitive to make it
> more complex, for example by mirroring the repository to Gitlab. How does
> this work for PR's from forks (these repo's are still on a fork on Github)?
> For example, when I open a PR from my Github fork, this fork does not live
> in Gitlab.

The forks will use Travis.

> - I think it is important to discuss this with Infra as well, we need to
> get them on board as well.

I agree.

> - Are there other OSS projects which use this setup as well?

Not yet, but we maintain direct contact with Apache Beam commiters.
They are also interested in moving to a similar infrasture.

> My personal opinion, apart from the issues we're facing the last few days,
> Travis works quite well for me.

I am afraid that the current problems will be repeated because we have
cut resources by the Apache Infra team  We have only 5 workers. This
means that only one pR is performed simultaneously on apache/airflow
repo.

> Cheers, Fokko
>
> Op wo 24 jul. 2019 om 10:05 schreef Jarek Potiuk <Ja...@polidea.com>:
>
> > Of course ! One of the considerations is to keep travis CI build intact -
> > so that anyone will be able to have their own Travis Fork for the time
> > being.
> >
> > I will also do it in the way that once you have your own GCP account and
> > your own GKE cluster, you will be able to replicate it as well (there will
> > be instructions on how to set it up).
> > We can even (long term) make it in the way that you will not need a
> > separate GKE cluster but it will run using just your personal GitLab
> > (free). This should be possible - I am really trying to make it
> > underlying-infrastructure-agnostic.
> >
> > The non-cluster personal GitLab is not a priority now (Travis forks will
> > hopefully work ;) so it might not work initially, but there aren't
> > fundamental reasons it should not work. We will have to just use GitLabCI
> > registry instead of the GCP one and avoid assuming we are running in the
> > GKE cluster and have some secrets/accounts distributed differently. All
> > looks doable.
> >
> > J.
> >
> >
> > J.
> >
> > On Wed, Jul 24, 2019 at 9:03 AM Chao-Han Tsai <mi...@gmail.com>
> > wrote:
> >
> > > Thanks Jarek for putting this together. We really need a stable and fast
> > > CI.
> > >
> > > Question: will we still be able to build our personal fork of Airflow on
> > > our own Travis?
> > >
> > > Chao-Han
> > >
> > > On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <Ja...@polidea.com>
> > > wrote:
> > >
> > > > >
> > > > > Question - what is the purpose of introducing kaniko instead of using
> > > > > regular docker build?
> > > > >
> > > >
> > > > Indeed. We want to be as agnostic as possible. What I plan to do is to
> > > use
> > > > Kubernetes Runner in GitlabCI. This means that all the jobs will run as
> > > > Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
> > > > orchestrates the builds. This means that our test jobs will be run
> > inside
> > > > docker - they will not run in virtual machine, but they will run inside
> > > the
> > > > container. This is how modern CI systems work (for example Gitlab,
> > > > CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the
> > > block
> > > > which is Kubernetes-Native). Argo is a bit too fresh to consider it,
> > but
> > > > they all work similarly - all steps are run inside docker.
> > > >
> > > > As the first part of our build we have to build the images with latest
> > > > sources (and dependencies if needed) that then will be used for
> > > subsequent
> > > > steps. This means that we need to build the images from within docker -
> > > > which is not as trivial as running docker command. There are three ways
> > > to
> > > > approach it - docker-in-docker (requires priviledged docker
> > containers),
> > > > using same docker engine which is used by Kubernetes Cluster (not
> > > > recommended as Kubernetes manages docker engine on their own and might
> > > > delete/remove images at any time) or use Kaniko. Kaniko was created
> > > exactly
> > > > for this purpose - to be able to run docker build from within a POD
> > that
> > > > runs in Kubernetes cluster.
> > > >
> > > > I hope it explains :). Kaniko is pretty much standard way of doing it
> > and
> > > > it really Kubernetes-native way of doing it.
> > > >
> > > >
> > > > >
> > > > > Regards
> > > > > Shah
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <
> > Jarek.Potiuk@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/>
> > > >
> > >
> > >
> > > --
> > >
> > > Chao-Han Tsai
> > >
> >
> >
> > --
> >
> > Jarek Potiuk
> > Polidea <https://www.polidea.com/> | Principal Software Engineer
> >
> > M: +48 660 796 129 <+48660796129>
> > [image: Polidea] <https://www.polidea.com/>
> >

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

> Do we _specifically_ have to use GCS for images? We use
> docker.io/apache/airflow <http://docker.io/apache/airflow> right now?
> Does that have to change?
>

We do not use GCS specifically. We use GCR (Google Container Registry)
which has the same APIs as docker.io to store/retrieve images (it does use
GCS as storage backend though). Basically you can do "docker pull
gcr.io/apache-airflow-testing/apache:master-ci-3.6" if you are authorised
with GCP and it will work. This is a private repository though (and there
is no intention to make it public). This is purely internal content
registry that is used to cache images for the builds. We do not plan to
change the  docker.io/apache/airflow (it will still be used by everyone).

Using the internal GCR registry in GCP is purely optimisation of time for
build and cost. The registry can be (if we use the right URLs - gcr.io.eu
for EU zone etc) located very close physically and network-wise to the GKE
Kubernetes Cluster - so pull/push will be super-fast backed by internal
network infrastructure of Google Data Centers. Plus we will not pay for the
cost of the push-es that are needed for caching. Normally you have to pay
for the outbound traffic from Google Data Center to outside, but if we use
GCR which is inside Google infrastructure, it is for free. Plus - in this
registry there will be a lot of "temporary" images stored (we will setup
auto-cleanup of old images - it is configurable). Basically each build will
have their own set of images (identified with commit SHA - something
like: *gcr.io/apache-airflow-testing/apache:master-ci-3.6_2adsdo2131212312
<http://gcr.io/apache-airflow-testing/apache:master-ci-3.6_2adsdo2131212312>
* -
each build will start with preparing the images and then subsequent steps
will use those images for this particular commit. This means that there
will be a lot of "garbage" in this registry (again as I mentioned we can
configure auto-cleanup by properly configuring the GCS storage backing it).
We definitely do not want those images in our public registry.

So simple answer - this is just temporary registry to store the images. No
plans to get rid of dockerhub registry. It's optimisation. We could just
change the URL of where to push the images to "docker.io" and it will
continue to work but much slower, more expensive and leaving a lot of
garbage (DockerHub does not have auto-cleaning AFIK).


> What process handles the mirroring between Github and Gitlab? What ways
> might it go wrong? Is there any way we can avoid needing to mirror the code
> to gitlab?


This is built-in GitLab integration with GitHub (
https://about.gitlab.com/solutions/github/)  it's built-in and fully
managed by GitLab. We are not going to touch those git repos in GitLab.
They are read-only (except for the mirroring part) and we will never give
access to anyone to modify it, never configure any access to it, never
perform single git operation on it. It is pretty much equivalent to you,
pulling the latest changes from GitHub to your repo without ever modifying
it. It's not something we have to do anything about, except just
authorising GitLab to "read" using Oauth.  I don't expect any problems
there. Many companies are using it - including a lot of Open Source
software. I can get some names if you want :).


> What happens about PRs against the main repo?
>

That's the only point where I need to have the POC to test as I am not 100%
sure how it's going to work.This is a highly requested feature for GitLab:
https://gitlab.com/gitlab-org/gitlab-ee/issues/5667  and while it does not
work natively, there are open-source implementations of bots that are
synchronising PRs and running the builds. We will have our own GKE Cluster
that we can run the bot on, so i am not too worried by that and I think we
can make it works with limited effort. Additionally I involved my friend
Kamil who is the GitLab CI maintainer to prioritise this feature. From
talking to Kamil - this is in the backlog of GitLab and they had very
recent discussions on implementing it. I will be in touch with Kamil and I
already told him that this will be a blocker for wider Apache rollout (for
example for Apache Beam) and if there will be agreement between Apache and
GitLab, then this must be solved quickly.


>
> Have we given thought to security of pull requests: If the jobs are
> running on our persistent infrastructure what happens if someone opens a PR
> with a malicious payload - it would run in our Kube cluster and could (for
> instance) start mining bitcoin or put other long running things in our kube
> cluster.
>

Yes. Very good point. I thought about it as well. We have already the same
potential vulnerability on Travis CI now. But then it is Travis
infrastructure that potentially suffers not ours (and Apache's overall
build time). So you can try to do the same even today. This should be
rather easy to contain by limiting maximum time of a job (this is exactly
what Travis does to mitigate it). Plus we can put limits for the Pods in
terms of CPU/memory it can use, so that you will not be able to abuse it
too much. I am also thinking about setting up alerting in GCP (we already
have Prometheus installed at our cluster - this is a "one-click" install in
GitLab once you connect the Cluster) and we can easily set-up alerting in
case of high CPU/auto-scaling running on high capacity for a long-ish time.
And we can enforce limits as reaction + we should be able to block certain
external repos. It will be a bit of trial-and-error to setup. Also I am
sure in order to exploit such an issue at scale you would have to automate
new account creation etc. in Github because you would not be able to run
such action on a massive scale - and I am sure GitHub has already a number
of security measures in place to prevent this.


>
> I am hugely in favour of moving to something that gives us a nicer
> experience than Travis, but right now with these limitations I am a little
> worried just how Complex (and thus possibly fragile) the pipeline becomes,
> not to mention the work needed to support it.
>

The pipeline is not complex at all. I already have the whole setup running
(it took about 4 hours to set it up from the scratch - including installing
everything that is needed and getting necessary access rights from Ajzhamal
- I was blocked by that first).
GitLab CI has fantastic nearly-native integration with Kubernetes -
including one-click install of all the software you need. The only
"difficult" part was to get the right access rights from Google OSS team
and setup authorisation where you had to exchange certificate and create
keys. But it was just 5 commands to run that worked out of the box as soon
as i had the access. Now I am working on the yaml file where all the steps
for our builds are configured - and they are rather simple as well (I will
share it soon). There are NO moving parts we have to maintain ourselves.
Everything is using ready-to-use cloud components that are just "there" -
we just glue them together with authorisation/configuration. I also plan to
have (following infrastructure-as-a-code) way to set everything up - so
that we can tear-down and setup everything from the scratch in less than
hour - fully automatically.


>
> -ash
>
> > On 26 Jul 2019, at 09:58, Driesprong, Fokko <fo...@driesprong.frl>
> wrote:
> >
> > Nice document Jarek.
> >
> > We should look at the pro's and con's regarding moving away from Travis.
> > The process for Airflow, and also many other OSS projects, is to first
> > develop on your local fork. If everything looks good, open a PR to the
> main
> > repo. This reduces the noise we have on the project itself. Being more
> > strict on this will also reduce the load on the CI service of Apache.
> >
> > A couple of thoughts so far:
> > - I'm not sure why we need to store the images on the GCS. We could just
> > discard the image after the build? In the case of caching, we could also
> > store them on the local VM's as well. Just a thought to simplify the
> setup.
> > - Since the current setup is flaky, it feels counterintuitive to make it
> > more complex, for example by mirroring the repository to Gitlab. How does
> > this work for PR's from forks (these repo's are still on a fork on
> Github)?
> > For example, when I open a PR from my Github fork, this fork does not
> live
> > in Gitlab.
> > - I think it is important to discuss this with Infra as well, we need to
> > get them on board as well.
> > - Are there other OSS projects which use this setup as well?
> >
> > My personal opinion, apart from the issues we're facing the last few
> days,
> > Travis works quite well for me.
> >
> > Cheers, Fokko
> >
> > Op wo 24 jul. 2019 om 10:05 schreef Jarek Potiuk <
> Jarek.Potiuk@polidea.com>:
> >
> >> Of course ! One of the considerations is to keep travis CI build intact
> -
> >> so that anyone will be able to have their own Travis Fork for the time
> >> being.
> >>
> >> I will also do it in the way that once you have your own GCP account and
> >> your own GKE cluster, you will be able to replicate it as well (there
> will
> >> be instructions on how to set it up).
> >> We can even (long term) make it in the way that you will not need a
> >> separate GKE cluster but it will run using just your personal GitLab
> >> (free). This should be possible - I am really trying to make it
> >> underlying-infrastructure-agnostic.
> >>
> >> The non-cluster personal GitLab is not a priority now (Travis forks will
> >> hopefully work ;) so it might not work initially, but there aren't
> >> fundamental reasons it should not work. We will have to just use
> GitLabCI
> >> registry instead of the GCP one and avoid assuming we are running in the
> >> GKE cluster and have some secrets/accounts distributed differently. All
> >> looks doable.
> >>
> >> J.
> >>
> >>
> >> J.
> >>
> >> On Wed, Jul 24, 2019 at 9:03 AM Chao-Han Tsai <mi...@gmail.com>
> >> wrote:
> >>
> >>> Thanks Jarek for putting this together. We really need a stable and
> fast
> >>> CI.
> >>>
> >>> Question: will we still be able to build our personal fork of Airflow
> on
> >>> our own Travis?
> >>>
> >>> Chao-Han
> >>>
> >>> On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> >>> wrote:
> >>>
> >>>>>
> >>>>> Question - what is the purpose of introducing kaniko instead of using
> >>>>> regular docker build?
> >>>>>
> >>>>
> >>>> Indeed. We want to be as agnostic as possible. What I plan to do is to
> >>> use
> >>>> Kubernetes Runner in GitlabCI. This means that all the jobs will run
> as
> >>>> Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
> >>>> orchestrates the builds. This means that our test jobs will be run
> >> inside
> >>>> docker - they will not run in virtual machine, but they will run
> inside
> >>> the
> >>>> container. This is how modern CI systems work (for example Gitlab,
> >>>> CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the
> >>> block
> >>>> which is Kubernetes-Native). Argo is a bit too fresh to consider it,
> >> but
> >>>> they all work similarly - all steps are run inside docker.
> >>>>
> >>>> As the first part of our build we have to build the images with latest
> >>>> sources (and dependencies if needed) that then will be used for
> >>> subsequent
> >>>> steps. This means that we need to build the images from within docker
> -
> >>>> which is not as trivial as running docker command. There are three
> ways
> >>> to
> >>>> approach it - docker-in-docker (requires priviledged docker
> >> containers),
> >>>> using same docker engine which is used by Kubernetes Cluster (not
> >>>> recommended as Kubernetes manages docker engine on their own and might
> >>>> delete/remove images at any time) or use Kaniko. Kaniko was created
> >>> exactly
> >>>> for this purpose - to be able to run docker build from within a POD
> >> that
> >>>> runs in Kubernetes cluster.
> >>>>
> >>>> I hope it explains :). Kaniko is pretty much standard way of doing it
> >> and
> >>>> it really Kubernetes-native way of doing it.
> >>>>
> >>>>
> >>>>>
> >>>>> Regards
> >>>>> Shah
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <
> >> Jarek.Potiuk@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/>
> >>>>
> >>>
> >>>
> >>> --
> >>>
> >>> Chao-Han Tsai
> >>>
> >>
> >>
> >> --
> >>
> >> 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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Ash Berlin-Taylor <as...@apache.org>]

Do we _specifically_ have to use GCS for images? We use docker.io/apache/airflow <http://docker.io/apache/airflow> right now? Does that have to change?

What process handles the mirroring between Github and Gitlab? What ways might it go wrong? Is there any way we can avoid needing to mirror the code to gitlab?

What happens about PRs against the main repo? 

Have we given thought to security of pull requests: If the jobs are running on our persistent infrastructure what happens if someone opens a PR with a malicious payload - it would run in our Kube cluster and could (for instance) start mining bitcoin or put other long running things in our kube cluster.

I am hugely in favour of moving to something that gives us a nicer experience than Travis, but right now with these limitations I am a little worried just how Complex (and thus possibly fragile) the pipeline becomes, not to mention the work needed to support it. 

-ash

> On 26 Jul 2019, at 09:58, Driesprong, Fokko <fo...@driesprong.frl> wrote:
> 
> Nice document Jarek.
> 
> We should look at the pro's and con's regarding moving away from Travis.
> The process for Airflow, and also many other OSS projects, is to first
> develop on your local fork. If everything looks good, open a PR to the main
> repo. This reduces the noise we have on the project itself. Being more
> strict on this will also reduce the load on the CI service of Apache.
> 
> A couple of thoughts so far:
> - I'm not sure why we need to store the images on the GCS. We could just
> discard the image after the build? In the case of caching, we could also
> store them on the local VM's as well. Just a thought to simplify the setup.
> - Since the current setup is flaky, it feels counterintuitive to make it
> more complex, for example by mirroring the repository to Gitlab. How does
> this work for PR's from forks (these repo's are still on a fork on Github)?
> For example, when I open a PR from my Github fork, this fork does not live
> in Gitlab.
> - I think it is important to discuss this with Infra as well, we need to
> get them on board as well.
> - Are there other OSS projects which use this setup as well?
> 
> My personal opinion, apart from the issues we're facing the last few days,
> Travis works quite well for me.
> 
> Cheers, Fokko
> 
> Op wo 24 jul. 2019 om 10:05 schreef Jarek Potiuk <Ja...@polidea.com>:
> 
>> Of course ! One of the considerations is to keep travis CI build intact -
>> so that anyone will be able to have their own Travis Fork for the time
>> being.
>> 
>> I will also do it in the way that once you have your own GCP account and
>> your own GKE cluster, you will be able to replicate it as well (there will
>> be instructions on how to set it up).
>> We can even (long term) make it in the way that you will not need a
>> separate GKE cluster but it will run using just your personal GitLab
>> (free). This should be possible - I am really trying to make it
>> underlying-infrastructure-agnostic.
>> 
>> The non-cluster personal GitLab is not a priority now (Travis forks will
>> hopefully work ;) so it might not work initially, but there aren't
>> fundamental reasons it should not work. We will have to just use GitLabCI
>> registry instead of the GCP one and avoid assuming we are running in the
>> GKE cluster and have some secrets/accounts distributed differently. All
>> looks doable.
>> 
>> J.
>> 
>> 
>> J.
>> 
>> On Wed, Jul 24, 2019 at 9:03 AM Chao-Han Tsai <mi...@gmail.com>
>> wrote:
>> 
>>> Thanks Jarek for putting this together. We really need a stable and fast
>>> CI.
>>> 
>>> Question: will we still be able to build our personal fork of Airflow on
>>> our own Travis?
>>> 
>>> Chao-Han
>>> 
>>> On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <Ja...@polidea.com>
>>> wrote:
>>> 
>>>>> 
>>>>> Question - what is the purpose of introducing kaniko instead of using
>>>>> regular docker build?
>>>>> 
>>>> 
>>>> Indeed. We want to be as agnostic as possible. What I plan to do is to
>>> use
>>>> Kubernetes Runner in GitlabCI. This means that all the jobs will run as
>>>> Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
>>>> orchestrates the builds. This means that our test jobs will be run
>> inside
>>>> docker - they will not run in virtual machine, but they will run inside
>>> the
>>>> container. This is how modern CI systems work (for example Gitlab,
>>>> CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the
>>> block
>>>> which is Kubernetes-Native). Argo is a bit too fresh to consider it,
>> but
>>>> they all work similarly - all steps are run inside docker.
>>>> 
>>>> As the first part of our build we have to build the images with latest
>>>> sources (and dependencies if needed) that then will be used for
>>> subsequent
>>>> steps. This means that we need to build the images from within docker -
>>>> which is not as trivial as running docker command. There are three ways
>>> to
>>>> approach it - docker-in-docker (requires priviledged docker
>> containers),
>>>> using same docker engine which is used by Kubernetes Cluster (not
>>>> recommended as Kubernetes manages docker engine on their own and might
>>>> delete/remove images at any time) or use Kaniko. Kaniko was created
>>> exactly
>>>> for this purpose - to be able to run docker build from within a POD
>> that
>>>> runs in Kubernetes cluster.
>>>> 
>>>> I hope it explains :). Kaniko is pretty much standard way of doing it
>> and
>>>> it really Kubernetes-native way of doing it.
>>>> 
>>>> 
>>>>> 
>>>>> Regards
>>>>> Shah
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <
>> Jarek.Potiuk@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/>
>>>> 
>>> 
>>> 
>>> --
>>> 
>>> Chao-Han Tsai
>>> 
>> 
>> 
>> --
>> 
>> Jarek Potiuk
>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>> 
>> M: +48 660 796 129 <+48660796129>
>> [image: Polidea] <https://www.polidea.com/>
>> 

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

["Driesprong, Fokko" <fo...@driesprong.frl>]

Nice document Jarek.

We should look at the pro's and con's regarding moving away from Travis.
The process for Airflow, and also many other OSS projects, is to first
develop on your local fork. If everything looks good, open a PR to the main
repo. This reduces the noise we have on the project itself. Being more
strict on this will also reduce the load on the CI service of Apache.

A couple of thoughts so far:
- I'm not sure why we need to store the images on the GCS. We could just
discard the image after the build? In the case of caching, we could also
store them on the local VM's as well. Just a thought to simplify the setup.
- Since the current setup is flaky, it feels counterintuitive to make it
more complex, for example by mirroring the repository to Gitlab. How does
this work for PR's from forks (these repo's are still on a fork on Github)?
For example, when I open a PR from my Github fork, this fork does not live
in Gitlab.
- I think it is important to discuss this with Infra as well, we need to
get them on board as well.
- Are there other OSS projects which use this setup as well?

My personal opinion, apart from the issues we're facing the last few days,
Travis works quite well for me.

Cheers, Fokko

Op wo 24 jul. 2019 om 10:05 schreef Jarek Potiuk <Ja...@polidea.com>:

> Of course ! One of the considerations is to keep travis CI build intact -
> so that anyone will be able to have their own Travis Fork for the time
> being.
>
> I will also do it in the way that once you have your own GCP account and
> your own GKE cluster, you will be able to replicate it as well (there will
> be instructions on how to set it up).
> We can even (long term) make it in the way that you will not need a
> separate GKE cluster but it will run using just your personal GitLab
> (free). This should be possible - I am really trying to make it
> underlying-infrastructure-agnostic.
>
> The non-cluster personal GitLab is not a priority now (Travis forks will
> hopefully work ;) so it might not work initially, but there aren't
> fundamental reasons it should not work. We will have to just use GitLabCI
> registry instead of the GCP one and avoid assuming we are running in the
> GKE cluster and have some secrets/accounts distributed differently. All
> looks doable.
>
> J.
>
>
> J.
>
> On Wed, Jul 24, 2019 at 9:03 AM Chao-Han Tsai <mi...@gmail.com>
> wrote:
>
> > Thanks Jarek for putting this together. We really need a stable and fast
> > CI.
> >
> > Question: will we still be able to build our personal fork of Airflow on
> > our own Travis?
> >
> > Chao-Han
> >
> > On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > >
> > > > Question - what is the purpose of introducing kaniko instead of using
> > > > regular docker build?
> > > >
> > >
> > > Indeed. We want to be as agnostic as possible. What I plan to do is to
> > use
> > > Kubernetes Runner in GitlabCI. This means that all the jobs will run as
> > > Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
> > > orchestrates the builds. This means that our test jobs will be run
> inside
> > > docker - they will not run in virtual machine, but they will run inside
> > the
> > > container. This is how modern CI systems work (for example Gitlab,
> > > CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the
> > block
> > > which is Kubernetes-Native). Argo is a bit too fresh to consider it,
> but
> > > they all work similarly - all steps are run inside docker.
> > >
> > > As the first part of our build we have to build the images with latest
> > > sources (and dependencies if needed) that then will be used for
> > subsequent
> > > steps. This means that we need to build the images from within docker -
> > > which is not as trivial as running docker command. There are three ways
> > to
> > > approach it - docker-in-docker (requires priviledged docker
> containers),
> > > using same docker engine which is used by Kubernetes Cluster (not
> > > recommended as Kubernetes manages docker engine on their own and might
> > > delete/remove images at any time) or use Kaniko. Kaniko was created
> > exactly
> > > for this purpose - to be able to run docker build from within a POD
> that
> > > runs in Kubernetes cluster.
> > >
> > > I hope it explains :). Kaniko is pretty much standard way of doing it
> and
> > > it really Kubernetes-native way of doing it.
> > >
> > >
> > > >
> > > > Regards
> > > > Shah
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <
> Jarek.Potiuk@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/>
> > >
> >
> >
> > --
> >
> > Chao-Han Tsai
> >
>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

Of course ! One of the considerations is to keep travis CI build intact -
so that anyone will be able to have their own Travis Fork for the time
being.

I will also do it in the way that once you have your own GCP account and
your own GKE cluster, you will be able to replicate it as well (there will
be instructions on how to set it up).
We can even (long term) make it in the way that you will not need a
separate GKE cluster but it will run using just your personal GitLab
(free). This should be possible - I am really trying to make it
underlying-infrastructure-agnostic.

The non-cluster personal GitLab is not a priority now (Travis forks will
hopefully work ;) so it might not work initially, but there aren't
fundamental reasons it should not work. We will have to just use GitLabCI
registry instead of the GCP one and avoid assuming we are running in the
GKE cluster and have some secrets/accounts distributed differently. All
looks doable.

J.


J.

On Wed, Jul 24, 2019 at 9:03 AM Chao-Han Tsai <mi...@gmail.com> wrote:

> Thanks Jarek for putting this together. We really need a stable and fast
> CI.
>
> Question: will we still be able to build our personal fork of Airflow on
> our own Travis?
>
> Chao-Han
>
> On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > >
> > > Question - what is the purpose of introducing kaniko instead of using
> > > regular docker build?
> > >
> >
> > Indeed. We want to be as agnostic as possible. What I plan to do is to
> use
> > Kubernetes Runner in GitlabCI. This means that all the jobs will run as
> > Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
> > orchestrates the builds. This means that our test jobs will be run inside
> > docker - they will not run in virtual machine, but they will run inside
> the
> > container. This is how modern CI systems work (for example Gitlab,
> > CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the
> block
> > which is Kubernetes-Native). Argo is a bit too fresh to consider it, but
> > they all work similarly - all steps are run inside docker.
> >
> > As the first part of our build we have to build the images with latest
> > sources (and dependencies if needed) that then will be used for
> subsequent
> > steps. This means that we need to build the images from within docker -
> > which is not as trivial as running docker command. There are three ways
> to
> > approach it - docker-in-docker (requires priviledged docker containers),
> > using same docker engine which is used by Kubernetes Cluster (not
> > recommended as Kubernetes manages docker engine on their own and might
> > delete/remove images at any time) or use Kaniko. Kaniko was created
> exactly
> > for this purpose - to be able to run docker build from within a POD that
> > runs in Kubernetes cluster.
> >
> > I hope it explains :). Kaniko is pretty much standard way of doing it and
> > it really Kubernetes-native way of doing it.
> >
> >
> > >
> > > Regards
> > > Shah
> > >
> > >
> > >
> > >
> > > On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <Jarek.Potiuk@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/>
> >
>
>
> --
>
> Chao-Han Tsai
>


-- 

Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer

M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Chao-Han Tsai <mi...@gmail.com>]

Thanks Jarek for putting this together. We really need a stable and fast CI.

Question: will we still be able to build our personal fork of Airflow on
our own Travis?

Chao-Han

On Tue, Jul 23, 2019 at 1:00 PM Jarek Potiuk <Ja...@polidea.com>
wrote:

> >
> > Question - what is the purpose of introducing kaniko instead of using
> > regular docker build?
> >
>
> Indeed. We want to be as agnostic as possible. What I plan to do is to use
> Kubernetes Runner in GitlabCI. This means that all the jobs will run as
> Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
> orchestrates the builds. This means that our test jobs will be run inside
> docker - they will not run in virtual machine, but they will run inside the
> container. This is how modern CI systems work (for example Gitlab,
> CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the block
> which is Kubernetes-Native). Argo is a bit too fresh to consider it, but
> they all work similarly - all steps are run inside docker.
>
> As the first part of our build we have to build the images with latest
> sources (and dependencies if needed) that then will be used for subsequent
> steps. This means that we need to build the images from within docker -
> which is not as trivial as running docker command. There are three ways to
> approach it - docker-in-docker (requires priviledged docker containers),
> using same docker engine which is used by Kubernetes Cluster (not
> recommended as Kubernetes manages docker engine on their own and might
> delete/remove images at any time) or use Kaniko. Kaniko was created exactly
> for this purpose - to be able to run docker build from within a POD that
> runs in Kubernetes cluster.
>
> I hope it explains :). Kaniko is pretty much standard way of doing it and
> it really Kubernetes-native way of doing it.
>
>
> >
> > Regards
> > Shah
> >
> >
> >
> >
> > On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <Ja...@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/>
>


-- 

Chao-Han Tsai

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Jarek Potiuk <Ja...@polidea.com>]

>
> Question - what is the purpose of introducing kaniko instead of using
> regular docker build?
>

Indeed. We want to be as agnostic as possible. What I plan to do is to use
Kubernetes Runner in GitlabCI. This means that all the jobs will run as
Kubernetes PODs in GKE - Gitlab CI will only be UI + runner that
orchestrates the builds. This means that our test jobs will be run inside
docker - they will not run in virtual machine, but they will run inside the
container. This is how modern CI systems work (for example Gitlab,
CloudBuild, also Argo <https://argoproj.github.io/> - new kid in the block
which is Kubernetes-Native). Argo is a bit too fresh to consider it, but
they all work similarly - all steps are run inside docker.

As the first part of our build we have to build the images with latest
sources (and dependencies if needed) that then will be used for subsequent
steps. This means that we need to build the images from within docker -
which is not as trivial as running docker command. There are three ways to
approach it - docker-in-docker (requires priviledged docker containers),
using same docker engine which is used by Kubernetes Cluster (not
recommended as Kubernetes manages docker engine on their own and might
delete/remove images at any time) or use Kaniko. Kaniko was created exactly
for this purpose - to be able to run docker build from within a POD that
runs in Kubernetes cluster.

I hope it explains :). Kaniko is pretty much standard way of doing it and
it really Kubernetes-native way of doing it.


>
> Regards
> Shah
>
>
>
>
> On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <Ja...@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/>

Re: [Discuss] AIP-23 Proposal "Migration out of Travis CI"

[Shah Altaf <me...@gmail.com>]

Hi that's a nice writeup, easy to follow.  Also I like your diagram.

Question - what is the purpose of introducing kaniko instead of using
regular docker build?
I'm asking in line with the consideration "The system should be
self-maintainable - with as little special Development/Ops maintenance
needed." ,
Though kaniko is an open source project, if its purpose here can be done
simply with the regular docker commands, that's fewer moving parts and a
lower overhead for maintenance as well as the future.

The reason for mentioning the future - considering how Travis has
deteriorated and is pretty much forcing a move away, it's worth learning
from, and any new build pipeline would benefit from being as agnostic as
possible, with as few pieces as possible.


Regards
Shah




On Tue, Jul 23, 2019 at 5:12 PM Jarek Potiuk <Ja...@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/>
>