You are viewing a plain text version of this content. The canonical link for it is here.
Posted to builds@apache.org by Daniel Gruno <hu...@apache.org> on 2019/07/02 21:50:51 UTC
External CI Service Limitations
Hi folks,
As this seems to be a hot topic as of late, I'll provide some
information about our usage of external CI services.
Travis CI: The foundation has an agreement with Travis CI to provide our
projects with external CI services through them. At current, we have
approximately 40 executors there, half of which are currently
(build-time-wise) being occupied by three projects; Flink (21%), Arrow
(18%) and Airflow (13%). The foundation is currently not looking at
increasing the number of executors there, as we are assessing long-term
costs and benefits, and we advise projects that have higher immediate
needs for CI to either use our Jenkins CI system or figure out a
budget/plan (whether that be internal or external to the foundation) for
other options, and to also assess whether the number of builds and their
duration fit with the overall goal of the CI need and the resources
available at our disposal. Currently, all projects have, as of this
week, been capped at 5 concurrent builds with Travis.
AppVeyor and CircleCI: The foundation makes use of the free tier of
these, as we have not received any requests for an increase, nor
assessed whether this is beneficial, and as there are, as things are
right now, permission issues that go against our standard policies for
repository access.
With regards, Daniel on behalf of ASF Infra.
Re: External CI Service Limitations
Posted by David Nalley <da...@gnsa.us>.
On Tue, Jul 16, 2019 at 5:37 PM Greg Stein <gs...@gmail.com> wrote:
>
> Ray,
>
> Thanks for the offer of 50k minutes/project. That will definitely work for
> most projects.
>
> While we don't have precise measurements, some projects used *way* more
> than that within Travis last month:
>
> flink: 350k minutes
> arrow: 260k minutes
> cloudstack: 190k minutes
> incubator-druid: 96k
> airflow: 77k
> ... others: less than 50k
>
> I don't know what would be needed from Infra, to enable the use of Gitlab
> CI for our projects. ??
>
> Thanks,
> Greg Stein
> Infrastructure Administrator, ASF
>
It's also worth noting that those numbers are likely constrained by
our capacity. IIRC Humbedooh said we'd need something close to double
our currently capacity to satiate the backlog of build requests that
we had.
Our current travis load should be something like 1.72MM minutes per month.
--David
Re: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
Fantastic! but the link does not work for me :(
On Fri, Jul 19, 2019 at 8:16 AM Myrle Krantz <my...@apache.org> wrote:
> Hey Jarek,
>
> Someone at Google was actually looking to get rid of about 11 GKE vouchers
> for $500 each; I don't think anyone has taken them up on that yet, if you
> need more.
>
>
> https://lists.apache.org/thread.html/d9cb36493744836edcd59eebba6aef16356a3d5fd5fa90af336a82e1@%3Cmentors.community.apache.org%3E
>
> Best,
> Myrle
>
> On Fri, Jul 19, 2019 at 8:00 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > OK. We got some credits from Google :) so I will soon be testing out
> > GitLabCI + GKE cluster combination and will let you know the results :)
> >
> > J.
> >
> > On Wed, Jul 17, 2019 at 7:38 AM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> > > From Apache Airflow side - I am going to try out GitLab CI setup for
> the
> > > project and I also reached out to Google OSS team to donate a GKE
> > > auto-scaling cluster for our workloads. If it works (highly probable),
> we
> > > might be able to use even less of the free minutes from GitLab because
> we
> > > will have the cluster available to run our builds on. Maybe that's also
> > > something that other projects could look at if the 50K minutes is not
> > > enough.
> > >
> > > Suggestion: maybe it would be a great idea for GitLab to treat the
> > Apache
> > > projects differently and have a special agreement at least for some of
> > the
> > > projects that cannot get regular donations from other parties easily. I
> > > think this is more of a strategic decision for GitLab to see if this
> > might
> > > be in line with their strategy?.
> > >
> > > For now I think I have everything to try it out for Airflow project and
> > > make POC working in this setup (while waiting for the GKE cluster
> > > donation). Once done I am happy to share our learnings and maybe
> provide
> > > some guidelines for other projects?
> > >
> > > J.
> > >
> > >
> > > On Wed, Jul 17, 2019 at 2:37 AM Greg Stein <gs...@gmail.com> wrote:
> > >
> > >> Ray,
> > >>
> > >> Thanks for the offer of 50k minutes/project. That will definitely work
> > >> for most projects.
> > >>
> > >> While we don't have precise measurements, some projects used *way*
> more
> > >> than that within Travis last month:
> > >>
> > >> flink: 350k minutes
> > >> arrow: 260k minutes
> > >> cloudstack: 190k minutes
> > >> incubator-druid: 96k
> > >> airflow: 77k
> > >> ... others: less than 50k
> > >>
> > >> I don't know what would be needed from Infra, to enable the use of
> > Gitlab
> > >> CI for our projects. ??
> > >>
> > >> Thanks,
> > >> Greg Stein
> > >> Infrastructure Administrator, ASF
> > >>
> > >>
> > >> On Tue, Jul 16, 2019 at 7:27 PM Raymond Paik <rpaik@gitlab.com.invalid
> >
> > >> wrote:
> > >>
> > >>> Joan,
> > >>>
> > >>> The 50,000 minutes would be for each project (assuming individual
> > >>> projects
> > >>> will apply for separate GitLab licenses).
> > >>>
> > >>> When you reach the limit, you'll have an option to purchase
> additional
> > >>> minutes. More info. available at
> > >>>
> > >>>
> >
> https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#what-happens-when-my-ci-minutes-quota-run-out
> > >>> and
> > >>> here's the relevant issue
> > >>> <https://gitlab.com/gitlab-org/gitlab-ee/issues/3314#note_176031720
> >.
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Ray
> > >>>
> > >>> On Tue, Jul 16, 2019 at 2:33 PM Joan Touzet <wo...@apache.org>
> wrote:
> > >>>
> > >>> > Hi Raymond,
> > >>> >
> > >>> > Would this 50,000 CI minutes per month be spread across the entire
> > ASF,
> > >>> > or just each project? With >300 projects here, that's potentially
> > >>> > 50,000 * 300 = 15 million minutes we're talking about.
> > >>> >
> > >>> > What happens when a project exceeds that amount of minutes? Busy
> > >>> > projects that build each PR, and the build/test cycle takes let's
> say
> > >>> 30
> > >>> > minutes * 3 configuration = ~100 minutes per PR, would consume
> these
> > >>> > minutes with just 100 PRs (or incremental pushes to each PR).
> That's
> > >>> not
> > >>> > much time.
> > >>> >
> > >>> > -Joan
> > >>> >
> > >>> > On 2019-07-16 16:20, Raymond Paik wrote:
> > >>> > > Jarek,
> > >>> > >
> > >>> > > You're not required to migrate your repo over to GitLab. We have
> > >>> other
> > >>> > > projects that keep their source code in GitHub, but are using
> > GitLab
> > >>> for
> > >>> > > CI. Hope this helps...
> > >>> > >
> > >>> > > Thanks,
> > >>> > >
> > >>> > > Ray
> > >>> > >
> > >>> > > On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <
> > >>> Jarek.Potiuk@polidea.com>
> > >>> > > wrote:
> > >>> > >
> > >>> > >> Yep we use Git indeed but we have Github repo (
> > >>> > >> https://github.com/apache/airflow) and I believe this is
> pretty
> > >>> much
> > >>> > >> standard for all Apache projects (adding Greg as well).
> > >>> > >>
> > >>> > >> I don't think (or am I wrong?) the open source program directly
> > >>> applies
> > >>> > in
> > >>> > >> this case because we would have to have GitLab Repo as well, but
> > in
> > >>> our
> > >>> > >> case we really need GitLab CI integration with GitHub
> repository.
> > >>> > >>
> > >>> > >> Would that be possible to get this case working ?
> > >>> > >>
> > >>> > >> J
> > >>> > >>
> > >>> > >> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik
> > >>> <rp...@gitlab.com.invalid>
> > >>> > >> wrote:
> > >>> > >>
> > >>> > >>> Thanks Jarek:
> > >>> > >>>
> > >>> > >>> We do have an open source program at GitLab (
> > >>> > >>> https://about.gitlab.com/solutions/open-source/) where open
> > >>> source
> > >>> > >>> projects get access to top tier features (either SaaS or
> > >>> self-hosted)
> > >>> > for
> > >>> > >>> free including up to 50,000 CI minutes/month.
> > >>> > >>>
> > >>> > >>> Are you currently using Git as your source code repository?
> > >>> > >>>
> > >>> > >>> Ray
> > >>> > >>>
> > >>> > >>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <
> > >>> Jarek.Potiuk@polidea.com
> > >>> > >
> > >>> > >>> wrote:
> > >>> > >>>
> > >>> > >>>> Adding Raymond Paik who is GitLab Community Manager and wants
> to
> > >>> > >>> chime-in
> > >>> > >>>> the thread!
> > >>> > >>>>
> > >>> > >>>> J.
> > >>> > >>>>
> > >>> > >>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
> > >>> > >>>> <aw...@effectivemachines.com.invalid> wrote:
> > >>> > >>>>
> > >>> > >>>>>
> > >>> > >>>>>
> > >>> > >>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org>
> > >>> wrote:
> > >>> > >>>>>>
> > >>> > >>>>>> I was asking if any of the service platforms provided this.
> So
> > >>> far,
> > >>> > >>> it
> > >>> > >>>>> looks like no.
> > >>> > >>>>>
> > >>> > >>>>> I was playing around bit with Drone today because we
> > >>> actually
> > >>> > >>>>> need ARM in $DAYJOB and this convo reminded me that I needed
> to
> > >>> check
> > >>> > >>> it
> > >>> > >>>>> out.
> > >>> > >>>>>
> > >>> > >>>>> So far, I’m a little underwhelmed with the feature
> set.
> > >>> (No
> > >>> > >>>>> built-in artifacting, no junit output processing,
> buggy/broken
> > >>> yaml
> > >>> > >>>>> parser, … to be fair, they are relatively new so likely
> still
> > >>> > building
> > >>> > >>>>> these things up) BUT! They do support gitlab and acting as a
> > >>> gitlab
> > >>> > ci
> > >>> > >>>>> runner. So theoretically one could do linux/x86, windows/x86,
> > >>> mac os
> > >>> > >>> x, and
> > >>> > >>>>> linux/arm off of a combo of gitlab ci + drone.
> > >>> > >>>>>
> > >>> > >>>>>
> > >>> > >>>>>
> > >>> > >>>>
> > >>> > >>>> --
> > >>> > >>>>
> > >>> > >>>> 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: External CI Service Limitations
Posted by Myrle Krantz <my...@apache.org>.
Hey Jarek,
Someone at Google was actually looking to get rid of about 11 GKE vouchers
for $500 each; I don't think anyone has taken them up on that yet, if you
need more.
https://lists.apache.org/thread.html/d9cb36493744836edcd59eebba6aef16356a3d5fd5fa90af336a82e1@%3Cmentors.community.apache.org%3E
Best,
Myrle
On Fri, Jul 19, 2019 at 8:00 AM Jarek Potiuk <Ja...@polidea.com>
wrote:
> OK. We got some credits from Google :) so I will soon be testing out
> GitLabCI + GKE cluster combination and will let you know the results :)
>
> J.
>
> On Wed, Jul 17, 2019 at 7:38 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > From Apache Airflow side - I am going to try out GitLab CI setup for the
> > project and I also reached out to Google OSS team to donate a GKE
> > auto-scaling cluster for our workloads. If it works (highly probable), we
> > might be able to use even less of the free minutes from GitLab because we
> > will have the cluster available to run our builds on. Maybe that's also
> > something that other projects could look at if the 50K minutes is not
> > enough.
> >
> > Suggestion: maybe it would be a great idea for GitLab to treat the
> Apache
> > projects differently and have a special agreement at least for some of
> the
> > projects that cannot get regular donations from other parties easily. I
> > think this is more of a strategic decision for GitLab to see if this
> might
> > be in line with their strategy?.
> >
> > For now I think I have everything to try it out for Airflow project and
> > make POC working in this setup (while waiting for the GKE cluster
> > donation). Once done I am happy to share our learnings and maybe provide
> > some guidelines for other projects?
> >
> > J.
> >
> >
> > On Wed, Jul 17, 2019 at 2:37 AM Greg Stein <gs...@gmail.com> wrote:
> >
> >> Ray,
> >>
> >> Thanks for the offer of 50k minutes/project. That will definitely work
> >> for most projects.
> >>
> >> While we don't have precise measurements, some projects used *way* more
> >> than that within Travis last month:
> >>
> >> flink: 350k minutes
> >> arrow: 260k minutes
> >> cloudstack: 190k minutes
> >> incubator-druid: 96k
> >> airflow: 77k
> >> ... others: less than 50k
> >>
> >> I don't know what would be needed from Infra, to enable the use of
> Gitlab
> >> CI for our projects. ??
> >>
> >> Thanks,
> >> Greg Stein
> >> Infrastructure Administrator, ASF
> >>
> >>
> >> On Tue, Jul 16, 2019 at 7:27 PM Raymond Paik <rp...@gitlab.com.invalid>
> >> wrote:
> >>
> >>> Joan,
> >>>
> >>> The 50,000 minutes would be for each project (assuming individual
> >>> projects
> >>> will apply for separate GitLab licenses).
> >>>
> >>> When you reach the limit, you'll have an option to purchase additional
> >>> minutes. More info. available at
> >>>
> >>>
> https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#what-happens-when-my-ci-minutes-quota-run-out
> >>> and
> >>> here's the relevant issue
> >>> <https://gitlab.com/gitlab-org/gitlab-ee/issues/3314#note_176031720>.
> >>>
> >>> Thanks,
> >>>
> >>> Ray
> >>>
> >>> On Tue, Jul 16, 2019 at 2:33 PM Joan Touzet <wo...@apache.org> wrote:
> >>>
> >>> > Hi Raymond,
> >>> >
> >>> > Would this 50,000 CI minutes per month be spread across the entire
> ASF,
> >>> > or just each project? With >300 projects here, that's potentially
> >>> > 50,000 * 300 = 15 million minutes we're talking about.
> >>> >
> >>> > What happens when a project exceeds that amount of minutes? Busy
> >>> > projects that build each PR, and the build/test cycle takes let's say
> >>> 30
> >>> > minutes * 3 configuration = ~100 minutes per PR, would consume these
> >>> > minutes with just 100 PRs (or incremental pushes to each PR). That's
> >>> not
> >>> > much time.
> >>> >
> >>> > -Joan
> >>> >
> >>> > On 2019-07-16 16:20, Raymond Paik wrote:
> >>> > > Jarek,
> >>> > >
> >>> > > You're not required to migrate your repo over to GitLab. We have
> >>> other
> >>> > > projects that keep their source code in GitHub, but are using
> GitLab
> >>> for
> >>> > > CI. Hope this helps...
> >>> > >
> >>> > > Thanks,
> >>> > >
> >>> > > Ray
> >>> > >
> >>> > > On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <
> >>> Jarek.Potiuk@polidea.com>
> >>> > > wrote:
> >>> > >
> >>> > >> Yep we use Git indeed but we have Github repo (
> >>> > >> https://github.com/apache/airflow) and I believe this is pretty
> >>> much
> >>> > >> standard for all Apache projects (adding Greg as well).
> >>> > >>
> >>> > >> I don't think (or am I wrong?) the open source program directly
> >>> applies
> >>> > in
> >>> > >> this case because we would have to have GitLab Repo as well, but
> in
> >>> our
> >>> > >> case we really need GitLab CI integration with GitHub repository.
> >>> > >>
> >>> > >> Would that be possible to get this case working ?
> >>> > >>
> >>> > >> J
> >>> > >>
> >>> > >> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik
> >>> <rp...@gitlab.com.invalid>
> >>> > >> wrote:
> >>> > >>
> >>> > >>> Thanks Jarek:
> >>> > >>>
> >>> > >>> We do have an open source program at GitLab (
> >>> > >>> https://about.gitlab.com/solutions/open-source/) where open
> >>> source
> >>> > >>> projects get access to top tier features (either SaaS or
> >>> self-hosted)
> >>> > for
> >>> > >>> free including up to 50,000 CI minutes/month.
> >>> > >>>
> >>> > >>> Are you currently using Git as your source code repository?
> >>> > >>>
> >>> > >>> Ray
> >>> > >>>
> >>> > >>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <
> >>> Jarek.Potiuk@polidea.com
> >>> > >
> >>> > >>> wrote:
> >>> > >>>
> >>> > >>>> Adding Raymond Paik who is GitLab Community Manager and wants to
> >>> > >>> chime-in
> >>> > >>>> the thread!
> >>> > >>>>
> >>> > >>>> J.
> >>> > >>>>
> >>> > >>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
> >>> > >>>> <aw...@effectivemachines.com.invalid> wrote:
> >>> > >>>>
> >>> > >>>>>
> >>> > >>>>>
> >>> > >>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org>
> >>> wrote:
> >>> > >>>>>>
> >>> > >>>>>> I was asking if any of the service platforms provided this. So
> >>> far,
> >>> > >>> it
> >>> > >>>>> looks like no.
> >>> > >>>>>
> >>> > >>>>> I was playing around bit with Drone today because we
> >>> actually
> >>> > >>>>> need ARM in $DAYJOB and this convo reminded me that I needed to
> >>> check
> >>> > >>> it
> >>> > >>>>> out.
> >>> > >>>>>
> >>> > >>>>> So far, I’m a little underwhelmed with the feature set.
> >>> (No
> >>> > >>>>> built-in artifacting, no junit output processing, buggy/broken
> >>> yaml
> >>> > >>>>> parser, … to be fair, they are relatively new so likely still
> >>> > building
> >>> > >>>>> these things up) BUT! They do support gitlab and acting as a
> >>> gitlab
> >>> > ci
> >>> > >>>>> runner. So theoretically one could do linux/x86, windows/x86,
> >>> mac os
> >>> > >>> x, and
> >>> > >>>>> linux/arm off of a combo of gitlab ci + drone.
> >>> > >>>>>
> >>> > >>>>>
> >>> > >>>>>
> >>> > >>>>
> >>> > >>>> --
> >>> > >>>>
> >>> > >>>> 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: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
OK. We got some credits from Google :) so I will soon be testing out
GitLabCI + GKE cluster combination and will let you know the results :)
J.
On Wed, Jul 17, 2019 at 7:38 AM Jarek Potiuk <Ja...@polidea.com>
wrote:
> From Apache Airflow side - I am going to try out GitLab CI setup for the
> project and I also reached out to Google OSS team to donate a GKE
> auto-scaling cluster for our workloads. If it works (highly probable), we
> might be able to use even less of the free minutes from GitLab because we
> will have the cluster available to run our builds on. Maybe that's also
> something that other projects could look at if the 50K minutes is not
> enough.
>
> Suggestion: maybe it would be a great idea for GitLab to treat the Apache
> projects differently and have a special agreement at least for some of the
> projects that cannot get regular donations from other parties easily. I
> think this is more of a strategic decision for GitLab to see if this might
> be in line with their strategy?.
>
> For now I think I have everything to try it out for Airflow project and
> make POC working in this setup (while waiting for the GKE cluster
> donation). Once done I am happy to share our learnings and maybe provide
> some guidelines for other projects?
>
> J.
>
>
> On Wed, Jul 17, 2019 at 2:37 AM Greg Stein <gs...@gmail.com> wrote:
>
>> Ray,
>>
>> Thanks for the offer of 50k minutes/project. That will definitely work
>> for most projects.
>>
>> While we don't have precise measurements, some projects used *way* more
>> than that within Travis last month:
>>
>> flink: 350k minutes
>> arrow: 260k minutes
>> cloudstack: 190k minutes
>> incubator-druid: 96k
>> airflow: 77k
>> ... others: less than 50k
>>
>> I don't know what would be needed from Infra, to enable the use of Gitlab
>> CI for our projects. ??
>>
>> Thanks,
>> Greg Stein
>> Infrastructure Administrator, ASF
>>
>>
>> On Tue, Jul 16, 2019 at 7:27 PM Raymond Paik <rp...@gitlab.com.invalid>
>> wrote:
>>
>>> Joan,
>>>
>>> The 50,000 minutes would be for each project (assuming individual
>>> projects
>>> will apply for separate GitLab licenses).
>>>
>>> When you reach the limit, you'll have an option to purchase additional
>>> minutes. More info. available at
>>>
>>> https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#what-happens-when-my-ci-minutes-quota-run-out
>>> and
>>> here's the relevant issue
>>> <https://gitlab.com/gitlab-org/gitlab-ee/issues/3314#note_176031720>.
>>>
>>> Thanks,
>>>
>>> Ray
>>>
>>> On Tue, Jul 16, 2019 at 2:33 PM Joan Touzet <wo...@apache.org> wrote:
>>>
>>> > Hi Raymond,
>>> >
>>> > Would this 50,000 CI minutes per month be spread across the entire ASF,
>>> > or just each project? With >300 projects here, that's potentially
>>> > 50,000 * 300 = 15 million minutes we're talking about.
>>> >
>>> > What happens when a project exceeds that amount of minutes? Busy
>>> > projects that build each PR, and the build/test cycle takes let's say
>>> 30
>>> > minutes * 3 configuration = ~100 minutes per PR, would consume these
>>> > minutes with just 100 PRs (or incremental pushes to each PR). That's
>>> not
>>> > much time.
>>> >
>>> > -Joan
>>> >
>>> > On 2019-07-16 16:20, Raymond Paik wrote:
>>> > > Jarek,
>>> > >
>>> > > You're not required to migrate your repo over to GitLab. We have
>>> other
>>> > > projects that keep their source code in GitHub, but are using GitLab
>>> for
>>> > > CI. Hope this helps...
>>> > >
>>> > > Thanks,
>>> > >
>>> > > Ray
>>> > >
>>> > > On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <
>>> Jarek.Potiuk@polidea.com>
>>> > > wrote:
>>> > >
>>> > >> Yep we use Git indeed but we have Github repo (
>>> > >> https://github.com/apache/airflow) and I believe this is pretty
>>> much
>>> > >> standard for all Apache projects (adding Greg as well).
>>> > >>
>>> > >> I don't think (or am I wrong?) the open source program directly
>>> applies
>>> > in
>>> > >> this case because we would have to have GitLab Repo as well, but in
>>> our
>>> > >> case we really need GitLab CI integration with GitHub repository.
>>> > >>
>>> > >> Would that be possible to get this case working ?
>>> > >>
>>> > >> J
>>> > >>
>>> > >> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik
>>> <rp...@gitlab.com.invalid>
>>> > >> wrote:
>>> > >>
>>> > >>> Thanks Jarek:
>>> > >>>
>>> > >>> We do have an open source program at GitLab (
>>> > >>> https://about.gitlab.com/solutions/open-source/) where open
>>> source
>>> > >>> projects get access to top tier features (either SaaS or
>>> self-hosted)
>>> > for
>>> > >>> free including up to 50,000 CI minutes/month.
>>> > >>>
>>> > >>> Are you currently using Git as your source code repository?
>>> > >>>
>>> > >>> Ray
>>> > >>>
>>> > >>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <
>>> Jarek.Potiuk@polidea.com
>>> > >
>>> > >>> wrote:
>>> > >>>
>>> > >>>> Adding Raymond Paik who is GitLab Community Manager and wants to
>>> > >>> chime-in
>>> > >>>> the thread!
>>> > >>>>
>>> > >>>> J.
>>> > >>>>
>>> > >>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
>>> > >>>> <aw...@effectivemachines.com.invalid> wrote:
>>> > >>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org>
>>> wrote:
>>> > >>>>>>
>>> > >>>>>> I was asking if any of the service platforms provided this. So
>>> far,
>>> > >>> it
>>> > >>>>> looks like no.
>>> > >>>>>
>>> > >>>>> I was playing around bit with Drone today because we
>>> actually
>>> > >>>>> need ARM in $DAYJOB and this convo reminded me that I needed to
>>> check
>>> > >>> it
>>> > >>>>> out.
>>> > >>>>>
>>> > >>>>> So far, I’m a little underwhelmed with the feature set.
>>> (No
>>> > >>>>> built-in artifacting, no junit output processing, buggy/broken
>>> yaml
>>> > >>>>> parser, … to be fair, they are relatively new so likely still
>>> > building
>>> > >>>>> these things up) BUT! They do support gitlab and acting as a
>>> gitlab
>>> > ci
>>> > >>>>> runner. So theoretically one could do linux/x86, windows/x86,
>>> mac os
>>> > >>> x, and
>>> > >>>>> linux/arm off of a combo of gitlab ci + drone.
>>> > >>>>>
>>> > >>>>>
>>> > >>>>>
>>> > >>>>
>>> > >>>> --
>>> > >>>>
>>> > >>>> 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: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
From Apache Airflow side - I am going to try out GitLab CI setup for the
project and I also reached out to Google OSS team to donate a GKE
auto-scaling cluster for our workloads. If it works (highly probable), we
might be able to use even less of the free minutes from GitLab because we
will have the cluster available to run our builds on. Maybe that's also
something that other projects could look at if the 50K minutes is not
enough.
Suggestion: maybe it would be a great idea for GitLab to treat the Apache
projects differently and have a special agreement at least for some of the
projects that cannot get regular donations from other parties easily. I
think this is more of a strategic decision for GitLab to see if this might
be in line with their strategy?.
For now I think I have everything to try it out for Airflow project and
make POC working in this setup (while waiting for the GKE cluster
donation). Once done I am happy to share our learnings and maybe provide
some guidelines for other projects?
J.
On Wed, Jul 17, 2019 at 2:37 AM Greg Stein <gs...@gmail.com> wrote:
> Ray,
>
> Thanks for the offer of 50k minutes/project. That will definitely work for
> most projects.
>
> While we don't have precise measurements, some projects used *way* more
> than that within Travis last month:
>
> flink: 350k minutes
> arrow: 260k minutes
> cloudstack: 190k minutes
> incubator-druid: 96k
> airflow: 77k
> ... others: less than 50k
>
> I don't know what would be needed from Infra, to enable the use of Gitlab
> CI for our projects. ??
>
> Thanks,
> Greg Stein
> Infrastructure Administrator, ASF
>
>
> On Tue, Jul 16, 2019 at 7:27 PM Raymond Paik <rp...@gitlab.com.invalid>
> wrote:
>
>> Joan,
>>
>> The 50,000 minutes would be for each project (assuming individual projects
>> will apply for separate GitLab licenses).
>>
>> When you reach the limit, you'll have an option to purchase additional
>> minutes. More info. available at
>>
>> https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#what-happens-when-my-ci-minutes-quota-run-out
>> and
>> here's the relevant issue
>> <https://gitlab.com/gitlab-org/gitlab-ee/issues/3314#note_176031720>.
>>
>> Thanks,
>>
>> Ray
>>
>> On Tue, Jul 16, 2019 at 2:33 PM Joan Touzet <wo...@apache.org> wrote:
>>
>> > Hi Raymond,
>> >
>> > Would this 50,000 CI minutes per month be spread across the entire ASF,
>> > or just each project? With >300 projects here, that's potentially
>> > 50,000 * 300 = 15 million minutes we're talking about.
>> >
>> > What happens when a project exceeds that amount of minutes? Busy
>> > projects that build each PR, and the build/test cycle takes let's say 30
>> > minutes * 3 configuration = ~100 minutes per PR, would consume these
>> > minutes with just 100 PRs (or incremental pushes to each PR). That's not
>> > much time.
>> >
>> > -Joan
>> >
>> > On 2019-07-16 16:20, Raymond Paik wrote:
>> > > Jarek,
>> > >
>> > > You're not required to migrate your repo over to GitLab. We have other
>> > > projects that keep their source code in GitHub, but are using GitLab
>> for
>> > > CI. Hope this helps...
>> > >
>> > > Thanks,
>> > >
>> > > Ray
>> > >
>> > > On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <
>> Jarek.Potiuk@polidea.com>
>> > > wrote:
>> > >
>> > >> Yep we use Git indeed but we have Github repo (
>> > >> https://github.com/apache/airflow) and I believe this is pretty
>> much
>> > >> standard for all Apache projects (adding Greg as well).
>> > >>
>> > >> I don't think (or am I wrong?) the open source program directly
>> applies
>> > in
>> > >> this case because we would have to have GitLab Repo as well, but in
>> our
>> > >> case we really need GitLab CI integration with GitHub repository.
>> > >>
>> > >> Would that be possible to get this case working ?
>> > >>
>> > >> J
>> > >>
>> > >> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik
>> <rp...@gitlab.com.invalid>
>> > >> wrote:
>> > >>
>> > >>> Thanks Jarek:
>> > >>>
>> > >>> We do have an open source program at GitLab (
>> > >>> https://about.gitlab.com/solutions/open-source/) where open source
>> > >>> projects get access to top tier features (either SaaS or
>> self-hosted)
>> > for
>> > >>> free including up to 50,000 CI minutes/month.
>> > >>>
>> > >>> Are you currently using Git as your source code repository?
>> > >>>
>> > >>> Ray
>> > >>>
>> > >>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <
>> Jarek.Potiuk@polidea.com
>> > >
>> > >>> wrote:
>> > >>>
>> > >>>> Adding Raymond Paik who is GitLab Community Manager and wants to
>> > >>> chime-in
>> > >>>> the thread!
>> > >>>>
>> > >>>> J.
>> > >>>>
>> > >>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
>> > >>>> <aw...@effectivemachines.com.invalid> wrote:
>> > >>>>
>> > >>>>>
>> > >>>>>
>> > >>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org>
>> wrote:
>> > >>>>>>
>> > >>>>>> I was asking if any of the service platforms provided this. So
>> far,
>> > >>> it
>> > >>>>> looks like no.
>> > >>>>>
>> > >>>>> I was playing around bit with Drone today because we
>> actually
>> > >>>>> need ARM in $DAYJOB and this convo reminded me that I needed to
>> check
>> > >>> it
>> > >>>>> out.
>> > >>>>>
>> > >>>>> So far, I’m a little underwhelmed with the feature set.
>> (No
>> > >>>>> built-in artifacting, no junit output processing, buggy/broken
>> yaml
>> > >>>>> parser, … to be fair, they are relatively new so likely still
>> > building
>> > >>>>> these things up) BUT! They do support gitlab and acting as a
>> gitlab
>> > ci
>> > >>>>> runner. So theoretically one could do linux/x86, windows/x86, mac
>> os
>> > >>> x, and
>> > >>>>> linux/arm off of a combo of gitlab ci + drone.
>> > >>>>>
>> > >>>>>
>> > >>>>>
>> > >>>>
>> > >>>> --
>> > >>>>
>> > >>>> 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: External CI Service Limitations
Posted by Greg Stein <gs...@gmail.com>.
Ray,
Thanks for the offer of 50k minutes/project. That will definitely work for
most projects.
While we don't have precise measurements, some projects used *way* more
than that within Travis last month:
flink: 350k minutes
arrow: 260k minutes
cloudstack: 190k minutes
incubator-druid: 96k
airflow: 77k
... others: less than 50k
I don't know what would be needed from Infra, to enable the use of Gitlab
CI for our projects. ??
Thanks,
Greg Stein
Infrastructure Administrator, ASF
On Tue, Jul 16, 2019 at 7:27 PM Raymond Paik <rp...@gitlab.com.invalid>
wrote:
> Joan,
>
> The 50,000 minutes would be for each project (assuming individual projects
> will apply for separate GitLab licenses).
>
> When you reach the limit, you'll have an option to purchase additional
> minutes. More info. available at
>
> https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#what-happens-when-my-ci-minutes-quota-run-out
> and
> here's the relevant issue
> <https://gitlab.com/gitlab-org/gitlab-ee/issues/3314#note_176031720>.
>
> Thanks,
>
> Ray
>
> On Tue, Jul 16, 2019 at 2:33 PM Joan Touzet <wo...@apache.org> wrote:
>
> > Hi Raymond,
> >
> > Would this 50,000 CI minutes per month be spread across the entire ASF,
> > or just each project? With >300 projects here, that's potentially
> > 50,000 * 300 = 15 million minutes we're talking about.
> >
> > What happens when a project exceeds that amount of minutes? Busy
> > projects that build each PR, and the build/test cycle takes let's say 30
> > minutes * 3 configuration = ~100 minutes per PR, would consume these
> > minutes with just 100 PRs (or incremental pushes to each PR). That's not
> > much time.
> >
> > -Joan
> >
> > On 2019-07-16 16:20, Raymond Paik wrote:
> > > Jarek,
> > >
> > > You're not required to migrate your repo over to GitLab. We have other
> > > projects that keep their source code in GitHub, but are using GitLab
> for
> > > CI. Hope this helps...
> > >
> > > Thanks,
> > >
> > > Ray
> > >
> > > On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <
> Jarek.Potiuk@polidea.com>
> > > wrote:
> > >
> > >> Yep we use Git indeed but we have Github repo (
> > >> https://github.com/apache/airflow) and I believe this is pretty much
> > >> standard for all Apache projects (adding Greg as well).
> > >>
> > >> I don't think (or am I wrong?) the open source program directly
> applies
> > in
> > >> this case because we would have to have GitLab Repo as well, but in
> our
> > >> case we really need GitLab CI integration with GitHub repository.
> > >>
> > >> Would that be possible to get this case working ?
> > >>
> > >> J
> > >>
> > >> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik <rpaik@gitlab.com.invalid
> >
> > >> wrote:
> > >>
> > >>> Thanks Jarek:
> > >>>
> > >>> We do have an open source program at GitLab (
> > >>> https://about.gitlab.com/solutions/open-source/) where open source
> > >>> projects get access to top tier features (either SaaS or self-hosted)
> > for
> > >>> free including up to 50,000 CI minutes/month.
> > >>>
> > >>> Are you currently using Git as your source code repository?
> > >>>
> > >>> Ray
> > >>>
> > >>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <
> Jarek.Potiuk@polidea.com
> > >
> > >>> wrote:
> > >>>
> > >>>> Adding Raymond Paik who is GitLab Community Manager and wants to
> > >>> chime-in
> > >>>> the thread!
> > >>>>
> > >>>> J.
> > >>>>
> > >>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
> > >>>> <aw...@effectivemachines.com.invalid> wrote:
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org>
> wrote:
> > >>>>>>
> > >>>>>> I was asking if any of the service platforms provided this. So
> far,
> > >>> it
> > >>>>> looks like no.
> > >>>>>
> > >>>>> I was playing around bit with Drone today because we
> actually
> > >>>>> need ARM in $DAYJOB and this convo reminded me that I needed to
> check
> > >>> it
> > >>>>> out.
> > >>>>>
> > >>>>> So far, I’m a little underwhelmed with the feature set. (No
> > >>>>> built-in artifacting, no junit output processing, buggy/broken yaml
> > >>>>> parser, … to be fair, they are relatively new so likely still
> > building
> > >>>>> these things up) BUT! They do support gitlab and acting as a gitlab
> > ci
> > >>>>> runner. So theoretically one could do linux/x86, windows/x86, mac
> os
> > >>> x, and
> > >>>>> linux/arm off of a combo of gitlab ci + drone.
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>> --
> > >>>>
> > >>>> 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: External CI Service Limitations
Posted by Raymond Paik <rp...@gitlab.com.INVALID>.
Joan,
The 50,000 minutes would be for each project (assuming individual projects
will apply for separate GitLab licenses).
When you reach the limit, you'll have an option to purchase additional
minutes. More info. available at
https://docs.gitlab.com/ee/user/admin_area/settings/continuous_integration.html#what-happens-when-my-ci-minutes-quota-run-out
and
here's the relevant issue
<https://gitlab.com/gitlab-org/gitlab-ee/issues/3314#note_176031720>.
Thanks,
Ray
On Tue, Jul 16, 2019 at 2:33 PM Joan Touzet <wo...@apache.org> wrote:
> Hi Raymond,
>
> Would this 50,000 CI minutes per month be spread across the entire ASF,
> or just each project? With >300 projects here, that's potentially
> 50,000 * 300 = 15 million minutes we're talking about.
>
> What happens when a project exceeds that amount of minutes? Busy
> projects that build each PR, and the build/test cycle takes let's say 30
> minutes * 3 configuration = ~100 minutes per PR, would consume these
> minutes with just 100 PRs (or incremental pushes to each PR). That's not
> much time.
>
> -Joan
>
> On 2019-07-16 16:20, Raymond Paik wrote:
> > Jarek,
> >
> > You're not required to migrate your repo over to GitLab. We have other
> > projects that keep their source code in GitHub, but are using GitLab for
> > CI. Hope this helps...
> >
> > Thanks,
> >
> > Ray
> >
> > On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <Ja...@polidea.com>
> > wrote:
> >
> >> Yep we use Git indeed but we have Github repo (
> >> https://github.com/apache/airflow) and I believe this is pretty much
> >> standard for all Apache projects (adding Greg as well).
> >>
> >> I don't think (or am I wrong?) the open source program directly applies
> in
> >> this case because we would have to have GitLab Repo as well, but in our
> >> case we really need GitLab CI integration with GitHub repository.
> >>
> >> Would that be possible to get this case working ?
> >>
> >> J
> >>
> >> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik <rp...@gitlab.com.invalid>
> >> wrote:
> >>
> >>> Thanks Jarek:
> >>>
> >>> We do have an open source program at GitLab (
> >>> https://about.gitlab.com/solutions/open-source/) where open source
> >>> projects get access to top tier features (either SaaS or self-hosted)
> for
> >>> free including up to 50,000 CI minutes/month.
> >>>
> >>> Are you currently using Git as your source code repository?
> >>>
> >>> Ray
> >>>
> >>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <Jarek.Potiuk@polidea.com
> >
> >>> wrote:
> >>>
> >>>> Adding Raymond Paik who is GitLab Community Manager and wants to
> >>> chime-in
> >>>> the thread!
> >>>>
> >>>> J.
> >>>>
> >>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
> >>>> <aw...@effectivemachines.com.invalid> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
> >>>>>>
> >>>>>> I was asking if any of the service platforms provided this. So far,
> >>> it
> >>>>> looks like no.
> >>>>>
> >>>>> I was playing around bit with Drone today because we actually
> >>>>> need ARM in $DAYJOB and this convo reminded me that I needed to check
> >>> it
> >>>>> out.
> >>>>>
> >>>>> So far, I’m a little underwhelmed with the feature set. (No
> >>>>> built-in artifacting, no junit output processing, buggy/broken yaml
> >>>>> parser, … to be fair, they are relatively new so likely still
> building
> >>>>> these things up) BUT! They do support gitlab and acting as a gitlab
> ci
> >>>>> runner. So theoretically one could do linux/x86, windows/x86, mac os
> >>> x, and
> >>>>> linux/arm off of a combo of gitlab ci + drone.
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> --
> >>>>
> >>>> 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: External CI Service Limitations
Posted by Joan Touzet <wo...@apache.org>.
Hi Raymond,
Would this 50,000 CI minutes per month be spread across the entire ASF,
or just each project? With >300 projects here, that's potentially
50,000 * 300 = 15 million minutes we're talking about.
What happens when a project exceeds that amount of minutes? Busy
projects that build each PR, and the build/test cycle takes let's say 30
minutes * 3 configuration = ~100 minutes per PR, would consume these
minutes with just 100 PRs (or incremental pushes to each PR). That's not
much time.
-Joan
On 2019-07-16 16:20, Raymond Paik wrote:
> Jarek,
>
> You're not required to migrate your repo over to GitLab. We have other
> projects that keep their source code in GitHub, but are using GitLab for
> CI. Hope this helps...
>
> Thanks,
>
> Ray
>
> On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
>> Yep we use Git indeed but we have Github repo (
>> https://github.com/apache/airflow) and I believe this is pretty much
>> standard for all Apache projects (adding Greg as well).
>>
>> I don't think (or am I wrong?) the open source program directly applies in
>> this case because we would have to have GitLab Repo as well, but in our
>> case we really need GitLab CI integration with GitHub repository.
>>
>> Would that be possible to get this case working ?
>>
>> J
>>
>> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik <rp...@gitlab.com.invalid>
>> wrote:
>>
>>> Thanks Jarek:
>>>
>>> We do have an open source program at GitLab (
>>> https://about.gitlab.com/solutions/open-source/) where open source
>>> projects get access to top tier features (either SaaS or self-hosted) for
>>> free including up to 50,000 CI minutes/month.
>>>
>>> Are you currently using Git as your source code repository?
>>>
>>> Ray
>>>
>>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <Ja...@polidea.com>
>>> wrote:
>>>
>>>> Adding Raymond Paik who is GitLab Community Manager and wants to
>>> chime-in
>>>> the thread!
>>>>
>>>> J.
>>>>
>>>> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
>>>> <aw...@effectivemachines.com.invalid> wrote:
>>>>
>>>>>
>>>>>
>>>>>> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
>>>>>>
>>>>>> I was asking if any of the service platforms provided this. So far,
>>> it
>>>>> looks like no.
>>>>>
>>>>> I was playing around bit with Drone today because we actually
>>>>> need ARM in $DAYJOB and this convo reminded me that I needed to check
>>> it
>>>>> out.
>>>>>
>>>>> So far, I’m a little underwhelmed with the feature set. (No
>>>>> built-in artifacting, no junit output processing, buggy/broken yaml
>>>>> parser, … to be fair, they are relatively new so likely still building
>>>>> these things up) BUT! They do support gitlab and acting as a gitlab ci
>>>>> runner. So theoretically one could do linux/x86, windows/x86, mac os
>>> x, and
>>>>> linux/arm off of a combo of gitlab ci + drone.
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> 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: External CI Service Limitations
Posted by Raymond Paik <rp...@gitlab.com.INVALID>.
Jarek,
You're not required to migrate your repo over to GitLab. We have other
projects that keep their source code in GitHub, but are using GitLab for
CI. Hope this helps...
Thanks,
Ray
On Tue, Jul 16, 2019 at 12:51 PM Jarek Potiuk <Ja...@polidea.com>
wrote:
> Yep we use Git indeed but we have Github repo (
> https://github.com/apache/airflow) and I believe this is pretty much
> standard for all Apache projects (adding Greg as well).
>
> I don't think (or am I wrong?) the open source program directly applies in
> this case because we would have to have GitLab Repo as well, but in our
> case we really need GitLab CI integration with GitHub repository.
>
> Would that be possible to get this case working ?
>
> J
>
> On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik <rp...@gitlab.com.invalid>
> wrote:
>
>> Thanks Jarek:
>>
>> We do have an open source program at GitLab (
>> https://about.gitlab.com/solutions/open-source/) where open source
>> projects get access to top tier features (either SaaS or self-hosted) for
>> free including up to 50,000 CI minutes/month.
>>
>> Are you currently using Git as your source code repository?
>>
>> Ray
>>
>> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <Ja...@polidea.com>
>> wrote:
>>
>> > Adding Raymond Paik who is GitLab Community Manager and wants to
>> chime-in
>> > the thread!
>> >
>> > J.
>> >
>> > On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
>> > <aw...@effectivemachines.com.invalid> wrote:
>> >
>> >>
>> >>
>> >> > On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
>> >> >
>> >> > I was asking if any of the service platforms provided this. So far,
>> it
>> >> looks like no.
>> >>
>> >> I was playing around bit with Drone today because we actually
>> >> need ARM in $DAYJOB and this convo reminded me that I needed to check
>> it
>> >> out.
>> >>
>> >> So far, I’m a little underwhelmed with the feature set. (No
>> >> built-in artifacting, no junit output processing, buggy/broken yaml
>> >> parser, … to be fair, they are relatively new so likely still building
>> >> these things up) BUT! They do support gitlab and acting as a gitlab ci
>> >> runner. So theoretically one could do linux/x86, windows/x86, mac os
>> x, and
>> >> linux/arm off of a combo of gitlab ci + drone.
>> >>
>> >>
>> >>
>> >
>> > --
>> >
>> > 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: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
Yep we use Git indeed but we have Github repo (
https://github.com/apache/airflow) and I believe this is pretty much
standard for all Apache projects (adding Greg as well).
I don't think (or am I wrong?) the open source program directly applies in
this case because we would have to have GitLab Repo as well, but in our
case we really need GitLab CI integration with GitHub repository.
Would that be possible to get this case working ?
J
On Tue, Jul 16, 2019 at 6:27 PM Raymond Paik <rp...@gitlab.com.invalid>
wrote:
> Thanks Jarek:
>
> We do have an open source program at GitLab (
> https://about.gitlab.com/solutions/open-source/) where open source
> projects get access to top tier features (either SaaS or self-hosted) for
> free including up to 50,000 CI minutes/month.
>
> Are you currently using Git as your source code repository?
>
> Ray
>
> On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Adding Raymond Paik who is GitLab Community Manager and wants to chime-in
> > the thread!
> >
> > J.
> >
> > On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
> > <aw...@effectivemachines.com.invalid> wrote:
> >
> >>
> >>
> >> > On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
> >> >
> >> > I was asking if any of the service platforms provided this. So far, it
> >> looks like no.
> >>
> >> I was playing around bit with Drone today because we actually
> >> need ARM in $DAYJOB and this convo reminded me that I needed to check it
> >> out.
> >>
> >> So far, I’m a little underwhelmed with the feature set. (No
> >> built-in artifacting, no junit output processing, buggy/broken yaml
> >> parser, … to be fair, they are relatively new so likely still building
> >> these things up) BUT! They do support gitlab and acting as a gitlab ci
> >> runner. So theoretically one could do linux/x86, windows/x86, mac os x,
> and
> >> linux/arm off of a combo of gitlab ci + drone.
> >>
> >>
> >>
> >
> > --
> >
> > 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: External CI Service Limitations
Posted by Raymond Paik <rp...@gitlab.com.INVALID>.
Thanks Jarek:
We do have an open source program at GitLab (
https://about.gitlab.com/solutions/open-source/) where open source
projects get access to top tier features (either SaaS or self-hosted) for
free including up to 50,000 CI minutes/month.
Are you currently using Git as your source code repository?
Ray
On Tue, Jul 16, 2019 at 8:49 AM Jarek Potiuk <Ja...@polidea.com>
wrote:
> Adding Raymond Paik who is GitLab Community Manager and wants to chime-in
> the thread!
>
> J.
>
> On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
> <aw...@effectivemachines.com.invalid> wrote:
>
>>
>>
>> > On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
>> >
>> > I was asking if any of the service platforms provided this. So far, it
>> looks like no.
>>
>> I was playing around bit with Drone today because we actually
>> need ARM in $DAYJOB and this convo reminded me that I needed to check it
>> out.
>>
>> So far, I’m a little underwhelmed with the feature set. (No
>> built-in artifacting, no junit output processing, buggy/broken yaml
>> parser, … to be fair, they are relatively new so likely still building
>> these things up) BUT! They do support gitlab and acting as a gitlab ci
>> runner. So theoretically one could do linux/x86, windows/x86, mac os x, and
>> linux/arm off of a combo of gitlab ci + drone.
>>
>>
>>
>
> --
>
> Jarek Potiuk
> Polidea <https://www.polidea.com/> | Principal Software Engineer
>
> M: +48 660 796 129 <+48660796129>
> [image: Polidea] <https://www.polidea.com/>
>
>
Re: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
Adding Raymond Paik who is GitLab Community Manager and wants to chime-in
the thread!
J.
On Thu, Jul 4, 2019 at 1:04 AM Allen Wittenauer
<aw...@effectivemachines.com.invalid> wrote:
>
>
> > On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
> >
> > I was asking if any of the service platforms provided this. So far, it
> looks like no.
>
> I was playing around bit with Drone today because we actually need
> ARM in $DAYJOB and this convo reminded me that I needed to check it out.
>
> So far, I’m a little underwhelmed with the feature set. (No
> built-in artifacting, no junit output processing, buggy/broken yaml
> parser, … to be fair, they are relatively new so likely still building
> these things up) BUT! They do support gitlab and acting as a gitlab ci
> runner. So theoretically one could do linux/x86, windows/x86, mac os x, and
> linux/arm off of a combo of gitlab ci + drone.
>
>
>
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: External CI Service Limitations
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
> On Jul 3, 2019, at 3:15 PM, Joan Touzet <wo...@apache.org> wrote:
>
> I was asking if any of the service platforms provided this. So far, it looks like no.
I was playing around bit with Drone today because we actually need ARM in $DAYJOB and this convo reminded me that I needed to check it out.
So far, I’m a little underwhelmed with the feature set. (No built-in artifacting, no junit output processing, buggy/broken yaml parser, … to be fair, they are relatively new so likely still building these things up) BUT! They do support gitlab and acting as a gitlab ci runner. So theoretically one could do linux/x86, windows/x86, mac os x, and linux/arm off of a combo of gitlab ci + drone.
Re: External CI Service Limitations
Posted by Joan Touzet <wo...@apache.org>.
On 2019-07-03 5:57 p.m., Greg Stein wrote:
> On Wed, Jul 3, 2019 at 11:36 AM Allen Wittenauer
> <aw...@effectivemachines.com.invalid> wrote:
>> ...
>
>>> CouchDB keeps receiving a lot of pressure to build on aarch64, ppc64le
>>> and s390x, which keeps pushing us back to Jenkins CI (ASF or
>>> independent). And if we have to do that, then not much else matters to
>> us.
>>
>> One of the nice things about using a system that supports external
>> runners is that it allows for contributions of CPU time from like minded
>> individuals. I wouldn’t trust them to do anything more than run tests
>> though.
>>
>
> Right. We have a number of external machines contributed to our buildbot
> network. An openbsd box, a Mac box, etc. They run a bunch of svn tests.
>
> We have some external machines using JNLP to hook into our Jenkins network.
>
> If somebody can find a $platform box they need, then it can be hooked in to
> our network for a single overview console of tests (assuming you're already
> using some of apache's systems already).
Yup, we're good here, though a lot of those donated boxes are single
points of failure :(
I was asking if any of the service platforms provided this. So far, it
looks like no.
>
> Cheers,
> -g
>
Re: External CI Service Limitations
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Jul 3, 2019 at 11:36 AM Allen Wittenauer
<aw...@effectivemachines.com.invalid> wrote:
>...
> > CouchDB keeps receiving a lot of pressure to build on aarch64, ppc64le
> > and s390x, which keeps pushing us back to Jenkins CI (ASF or
> > independent). And if we have to do that, then not much else matters to
> us.
>
> One of the nice things about using a system that supports external
> runners is that it allows for contributions of CPU time from like minded
> individuals. I wouldn’t trust them to do anything more than run tests
> though.
>
Right. We have a number of external machines contributed to our buildbot
network. An openbsd box, a Mac box, etc. They run a bunch of svn tests.
We have some external machines using JNLP to hook into our Jenkins network.
If somebody can find a $platform box they need, then it can be hooked in to
our network for a single overview console of tests (assuming you're already
using some of apache's systems already).
Cheers,
-g
Re: External CI Service Limitations
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
> On Jul 3, 2019, at 8:04 AM, Joan Touzet <wo...@apache.org> wrote:
>
> (With my CouchDB release engineer hat on only)
>
> Anyone know if any of these external services supports platforms other
> than amd64/x86_64?
AFAIK, all of the commercial SaaS companies who have an "open source can use for free” bit that I have experience with only do x86.[*] Most of them that have external runners do support ‘bring your own non-x86’ machine types.
There’s also things like OpenLab and the Linux Foundation machines too. (The latter provided PowerPC machine access to ASF Jenkins but I know when I tried to use them years ago they were incredibly unstable and the software install was extremely lacking to the point of being ultimately unusable for the project.)
I’ve never worked with pure pay companies in this area, so there are likely companies out there. It might be worthwhile for someone to do reach out to one since we might get free access for Exposure Bucks or something.
> CouchDB keeps receiving a lot of pressure to build on aarch64, ppc64le
> and s390x, which keeps pushing us back to Jenkins CI (ASF or
> independent). And if we have to do that, then not much else matters to us.
One of the nice things about using a system that supports external runners is that it allows for contributions of CPU time from like minded individuals. I wouldn’t trust them to do anything more than run tests though.
* - The big problem here is the lack of cost effective non-x86 machines from cloud providers. Drone, for example, does do ARM since it’s an extension of Packet’s cloud. But I don’t have experience with it so didn’t mention it earlier…. Maybe I’ll bang on it over the long weekend.
Re: External CI Service Limitations
Posted by Joan Touzet <wo...@apache.org>.
(With my CouchDB release engineer hat on only)
Anyone know if any of these external services supports platforms other
than amd64/x86_64?
CouchDB keeps receiving a lot of pressure to build on aarch64, ppc64le
and s390x, which keeps pushing us back to Jenkins CI (ASF or
independent). And if we have to do that, then not much else matters to us.
-Joan
On 2019-07-03 3:54, Jarek Potiuk wrote:
> I spoke to Kamil - Gitlab CI maintainer (in CC:) and he will speak to CEO
> of GitLab and Product Managers of GitLab CI whether GitLab will be willing
> to help with it.
>
> J.
>
> On Wed, Jul 3, 2019 at 9:33 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
>> Actually speaking of Gitlab CI. I realised my close friend is actually THE
>> maintainer and main person responsible for Gitlab CI. I will reach out to
>> him and see if they can help with this and provide free service. Shame I
>> have not thought about it before.
>>
>> J.
>>
>> On Wed, Jul 3, 2019 at 8:37 AM Allen Wittenauer
>> <aw...@effectivemachines.com.invalid> wrote:
>>
>>>
>>>
>>>> On Jul 2, 2019, at 11:12 PM, Jeff MAURY <je...@apache.org> wrote:
>>>>
>>>> Azure pipeline vas the big plus of supporting Linux Windows and macos
>>> nodes
>>>
>>> There’s a few that support various combinations of non-Linux.
>>> Gitlab CI has been there for a while. Circle CI has had OS X and is in
>>> beta with Windows. Cirrus CI has all those plus FreeBSD. etc, etc. It’s
>>> quickly becoming required that cloud-based CI systems do more than just
>>> throw up a Linux box.
>>>
>>>> And i think you can add you nodes to the pools
>>>
>>> I think they are limited to being on Azure tho, IIRC. But I’m
>>> probably not. I pretty much gave up on doing anything serious with it.
>>>
>>> I really wanted to like pipelines. The UI is nice. But in the
>>> end, Pipelines was one of the more frustrating ones to work with in my
>>> experience—and that was with some help from the MS folks. It suffers by a
>>> death of a thousand cuts (lack of complex, real-world examples, custom
>>> docker binary, pre-populated bits here and there, a ton of env vars,
>>> artifact system is a total disaster, etc, etc). Lots of small problems
>>> that add up to just not being worth the effort.
>>>
>>> Hopefully it’s improved since I last looked at it months and
>>> months ago though.
>>
>>
>>
>> --
>>
>> Jarek Potiuk
>> Polidea <https://www.polidea.com/> | Principal Software Engineer
>>
>> M: +48 660 796 129 <+48660796129>
>> [image: Polidea] <https://www.polidea.com/>
>>
>>
>
Re: External CI Service Limitations
Posted by Greg Stein <gs...@gmail.com>.
[builds@ to bcc: ; add vp-infra]
Jarek, Kamil ... that would be very interesting indeed. We've spoken to
Gitlab on possibilities in the past; it sounds like some of our projects
are interested in their services.
Please feel free to email myself/"us" at vp-infra@apache to discuss any
possible options here. Thanks!
Regards,
Greg Stein
Infrastructure Administrator, ASF
On Wed, Jul 3, 2019 at 2:55 AM Jarek Potiuk <Ja...@polidea.com>
wrote:
> I spoke to Kamil - Gitlab CI maintainer (in CC:) and he will speak to CEO
> of GitLab and Product Managers of GitLab CI whether GitLab will be willing
> to help with it.
>
> J.
>
> On Wed, Jul 3, 2019 at 9:33 AM Jarek Potiuk <Ja...@polidea.com>
> wrote:
>
> > Actually speaking of Gitlab CI. I realised my close friend is actually
> THE
> > maintainer and main person responsible for Gitlab CI. I will reach out to
> > him and see if they can help with this and provide free service. Shame I
> > have not thought about it before.
> >
> > J.
> >
> > On Wed, Jul 3, 2019 at 8:37 AM Allen Wittenauer
> > <aw...@effectivemachines.com.invalid> wrote:
> >
> >>
> >>
> >> > On Jul 2, 2019, at 11:12 PM, Jeff MAURY <je...@apache.org> wrote:
> >> >
> >> > Azure pipeline vas the big plus of supporting Linux Windows and macos
> >> nodes
> >>
> >> There’s a few that support various combinations of non-Linux.
> >> Gitlab CI has been there for a while. Circle CI has had OS X and is in
> >> beta with Windows. Cirrus CI has all those plus FreeBSD. etc, etc.
> It’s
> >> quickly becoming required that cloud-based CI systems do more than just
> >> throw up a Linux box.
> >>
> >> > And i think you can add you nodes to the pools
> >>
> >> I think they are limited to being on Azure tho, IIRC. But I’m
> >> probably not. I pretty much gave up on doing anything serious with it.
> >>
> >> I really wanted to like pipelines. The UI is nice. But in the
> >> end, Pipelines was one of the more frustrating ones to work with in my
> >> experience—and that was with some help from the MS folks. It suffers by
> a
> >> death of a thousand cuts (lack of complex, real-world examples, custom
> >> docker binary, pre-populated bits here and there, a ton of env vars,
> >> artifact system is a total disaster, etc, etc). Lots of small problems
> >> that add up to just not being worth the effort.
> >>
> >> Hopefully it’s improved since I last looked at it months and
> >> months ago though.
> >
> >
> >
> > --
> >
> > 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: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
I spoke to Kamil - Gitlab CI maintainer (in CC:) and he will speak to CEO
of GitLab and Product Managers of GitLab CI whether GitLab will be willing
to help with it.
J.
On Wed, Jul 3, 2019 at 9:33 AM Jarek Potiuk <Ja...@polidea.com>
wrote:
> Actually speaking of Gitlab CI. I realised my close friend is actually THE
> maintainer and main person responsible for Gitlab CI. I will reach out to
> him and see if they can help with this and provide free service. Shame I
> have not thought about it before.
>
> J.
>
> On Wed, Jul 3, 2019 at 8:37 AM Allen Wittenauer
> <aw...@effectivemachines.com.invalid> wrote:
>
>>
>>
>> > On Jul 2, 2019, at 11:12 PM, Jeff MAURY <je...@apache.org> wrote:
>> >
>> > Azure pipeline vas the big plus of supporting Linux Windows and macos
>> nodes
>>
>> There’s a few that support various combinations of non-Linux.
>> Gitlab CI has been there for a while. Circle CI has had OS X and is in
>> beta with Windows. Cirrus CI has all those plus FreeBSD. etc, etc. It’s
>> quickly becoming required that cloud-based CI systems do more than just
>> throw up a Linux box.
>>
>> > And i think you can add you nodes to the pools
>>
>> I think they are limited to being on Azure tho, IIRC. But I’m
>> probably not. I pretty much gave up on doing anything serious with it.
>>
>> I really wanted to like pipelines. The UI is nice. But in the
>> end, Pipelines was one of the more frustrating ones to work with in my
>> experience—and that was with some help from the MS folks. It suffers by a
>> death of a thousand cuts (lack of complex, real-world examples, custom
>> docker binary, pre-populated bits here and there, a ton of env vars,
>> artifact system is a total disaster, etc, etc). Lots of small problems
>> that add up to just not being worth the effort.
>>
>> Hopefully it’s improved since I last looked at it months and
>> months ago though.
>
>
>
> --
>
> 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: External CI Service Limitations
Posted by Jarek Potiuk <Ja...@polidea.com>.
Actually speaking of Gitlab CI. I realised my close friend is actually THE
maintainer and main person responsible for Gitlab CI. I will reach out to
him and see if they can help with this and provide free service. Shame I
have not thought about it before.
J.
On Wed, Jul 3, 2019 at 8:37 AM Allen Wittenauer
<aw...@effectivemachines.com.invalid> wrote:
>
>
> > On Jul 2, 2019, at 11:12 PM, Jeff MAURY <je...@apache.org> wrote:
> >
> > Azure pipeline vas the big plus of supporting Linux Windows and macos
> nodes
>
> There’s a few that support various combinations of non-Linux.
> Gitlab CI has been there for a while. Circle CI has had OS X and is in
> beta with Windows. Cirrus CI has all those plus FreeBSD. etc, etc. It’s
> quickly becoming required that cloud-based CI systems do more than just
> throw up a Linux box.
>
> > And i think you can add you nodes to the pools
>
> I think they are limited to being on Azure tho, IIRC. But I’m
> probably not. I pretty much gave up on doing anything serious with it.
>
> I really wanted to like pipelines. The UI is nice. But in the
> end, Pipelines was one of the more frustrating ones to work with in my
> experience—and that was with some help from the MS folks. It suffers by a
> death of a thousand cuts (lack of complex, real-world examples, custom
> docker binary, pre-populated bits here and there, a ton of env vars,
> artifact system is a total disaster, etc, etc). Lots of small problems
> that add up to just not being worth the effort.
>
> Hopefully it’s improved since I last looked at it months and
> months ago though.
--
Jarek Potiuk
Polidea <https://www.polidea.com/> | Principal Software Engineer
M: +48 660 796 129 <+48660796129>
[image: Polidea] <https://www.polidea.com/>
Re: External CI Service Limitations
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
> On Jul 2, 2019, at 11:12 PM, Jeff MAURY <je...@apache.org> wrote:
>
> Azure pipeline vas the big plus of supporting Linux Windows and macos nodes
There’s a few that support various combinations of non-Linux. Gitlab CI has been there for a while. Circle CI has had OS X and is in beta with Windows. Cirrus CI has all those plus FreeBSD. etc, etc. It’s quickly becoming required that cloud-based CI systems do more than just throw up a Linux box.
> And i think you can add you nodes to the pools
I think they are limited to being on Azure tho, IIRC. But I’m probably not. I pretty much gave up on doing anything serious with it.
I really wanted to like pipelines. The UI is nice. But in the end, Pipelines was one of the more frustrating ones to work with in my experience—and that was with some help from the MS folks. It suffers by a death of a thousand cuts (lack of complex, real-world examples, custom docker binary, pre-populated bits here and there, a ton of env vars, artifact system is a total disaster, etc, etc). Lots of small problems that add up to just not being worth the effort.
Hopefully it’s improved since I last looked at it months and months ago though.
Re: External CI Service Limitations
Posted by Jeff MAURY <je...@apache.org>.
Azure pipeline vas the big plus of supporting Linux Windows and macos nodes
And i think you can add you nodes to the pools
Jeff
Le mer. 3 juil. 2019 à 08:04, Allen Wittenauer
<aw...@effectivemachines.com.invalid> a écrit :
>
> > On Jul 2, 2019, at 10:21 PM, Greg Stein <gs...@gmail.com> wrote:
> >
> > We'll keep this list apprised of anything we find. If anybody knows of,
> > and/or can recommend a similar type of outsourced build service ... we
> > *absolutely* would welcome pointers.
>
> FWIW, we’ve been collecting them bit by bit into Apache Yetus (
> http://yetus.apache.org/documentation/in-progress/precommit-robots/ ):
>
> * Azure Pipelines
> * Circle CI
> * Cirrus CI
> * Gitlab CI
> * Semaphore CI
> * Travis CI
>
> They all have some pros and cons. I’m not going to rank them or
> anything.
>
> I will say, however, it really feels like Gitlab CI is the best
> bet to pursue since one can add their own runners to the Gitlab CI
> infrastructure dedicated to their own projects. That ultimately means that
> replacing Jenkins slaves is a very real possibility.
>
> (Also, I’ve requested access to the Github Actions beta, but
> haven’t received anything yet. I have a hunch that the reworking of the
> OAuth permission model is related, which may make some of these more viable
> for the ASF.)
Re: External CI Service Limitations
Posted by Allen Wittenauer <aw...@effectivemachines.com.INVALID>.
> On Jul 2, 2019, at 10:21 PM, Greg Stein <gs...@gmail.com> wrote:
>
> We'll keep this list apprised of anything we find. If anybody knows of,
> and/or can recommend a similar type of outsourced build service ... we
> *absolutely* would welcome pointers.
FWIW, we’ve been collecting them bit by bit into Apache Yetus ( http://yetus.apache.org/documentation/in-progress/precommit-robots/ ):
* Azure Pipelines
* Circle CI
* Cirrus CI
* Gitlab CI
* Semaphore CI
* Travis CI
They all have some pros and cons. I’m not going to rank them or anything.
I will say, however, it really feels like Gitlab CI is the best bet to pursue since one can add their own runners to the Gitlab CI infrastructure dedicated to their own projects. That ultimately means that replacing Jenkins slaves is a very real possibility.
(Also, I’ve requested access to the Github Actions beta, but haven’t received anything yet. I have a hunch that the reworking of the OAuth permission model is related, which may make some of these more viable for the ASF.)
Re: External CI Service Limitations
Posted by Greg Stein <gs...@gmail.com>.
On Tue, Jul 2, 2019 at 11:56 PM Jarek Potiuk <po...@apache.org> wrote:
>...
> In the meantime maybe INFRA can help to coordinate some effort between
> Flink/Arrow/Airflow to decrease pressure on Travis? We considered few
> options (and are going to implement some of them shortly I think). Some of
> them are not direct changes in Travis CI builds but some other
> workflow/infrastructure changes that will decrease pressure on Travis:
>
>...
> Maybe the committers from Flink and Arrow can also take a look at
> non-obvious ways how their projects can decrease pressure on Travis (at
> least for the time being). Maybe there are some quick wins we can apply in
> short time in coordinated way and buy more time for switching the
> infrastructure ?
>
The above is fabulous. Please continue trading thoughts and working to
reduce your Travis loads, for your own benefit and for your fellow projects
at the Foundation.
This list is the best space to trade such ideas. I'm not sure what Infra
can do, as our skillset is quite a bit different from what your projects
need, for reducing load.
We'll keep this list apprised of anything we find. If anybody knows of,
and/or can recommend a similar type of outsourced build service ... we
*absolutely* would welcome pointers.
We're gonna keep Jenkins and buildbot around for the foreseeable future,
and are interested in outsourced solutions.
Cheers,
Greg Stein
Infrastructure Administrator, ASF
Re: External CI Service Limitations
Posted by Jarek Potiuk <po...@apache.org>.
We also experience huge delays for Airflow (seems that we are the third "whale" according to https://lists.apache.org/thread.html/af52e2a3e865c01596d46374e8b294f2740587dbd59d85e132429b6c@%3Cbuilds.apache.org%3E)
We are evaluating other options for funding as well (including getting some credits from Google for Google Cloud Build / GCP) but it will take time to get resources and to switch.
In the meantime maybe INFRA can help to coordinate some effort between Flink/Arrow/Airflow to decrease pressure on Travis? We considered few options (and are going to implement some of them shortly I think). Some of them are not direct changes in Travis CI builds but some other workflow/infrastructure changes that will decrease pressure on Travis:
* We are going to decrease the matrix of builds we run - currently we have several combinations of Airflow builds (postgres/mysql/sqlite) x (python3.5/ python 3.6) - but we will only run subset of those rather than full matrix
* we are going to combine several of our jobs into one using parallel processing. This is mainly for static code analysis - currently we have one job for each analysis which makes them run in parallel. After the change - when you include machine boot times and use all processors, the overall build time might be even faster than today - AND there will be far less vms to start for the builds.
* we have separate kubernetes-related job. It currently runs only one suite of tests specific to Kubernetes as it requires special setup of the environment, but we are looking into possibility of merging Kubernetes tests into main tests (and faster environment setup with docker-compose) and save 1 job (25% of our test jobs). The main jobs will run a bit longer, but the whole overhead for starting extra job will be gone.
* We introduce (PR is in the final stages of review) an easy way for contributors to run static code analysis on their own environment. A lot of our builds are PR failing because of static code analysis that is run on Travis. Currently it was a bit convoluted and not easily reproducible to run full analysis locally , but we are moving to a fully dockerised setup for builds that will allow contributors to easily run such checks on their machines and we will encourage people to run it locally, rather than submit PRs just to check if the code is right.
* Even more - we are introducing and encouraging easy-to-use "pre-commit" framework in our developer workflow where the analysis will be run at commit time for only the changes being committed - this might further decrease the number of builds submitted by the contributors.
* Lastly - we are introducing an easy to use "simplified development environment" where developers will be able to run all or subset of test suites easily on their machine. Currently our setup is fairly convoluted as well but we have a PR in progress to address it and have a very easy way (again - fully dockerised) to reproduce the test environment.
Maybe the committers from Flink and Arrow can also take a look at non-obvious ways how their projects can decrease pressure on Travis (at least for the time being). Maybe there are some quick wins we can apply in short time in coordinated way and buy more time for switching the infrastructure ?
Fwd: External CI Service Limitations
Posted by Joan Touzet <wo...@apache.org>.
Hi everyone,
I'm in receipt of Ilya's email on build challenges, and do want to
reply, but have been preoccupied with things at a Foundation level since
I was elected as a Director of the ASF. (Sorry about that.)
Here's a quick brain dump.
While I was making my rounds through lists, the forwarded email below
came up on the builds@apache.org list today. Please read it. Perhaps
this will shed some light on the current slowness in the Travis CI
situation. The original thread is at [4].
Moving entirely to Jenkins CI - whether the build master is run by the
ASF as it is today, or we take on the effort to run our own build master
- will improve things, but we need to take into consideration more
challenges.
For instance, Jenkins has no integration with docker-compose[1]. And
various contributors continue to insist on pushing forward with
ppc64le[2] and aarch64[3] and think donating a single build box will
solve the problem. I don't want us to reintroducing new single points of
failure into the CI chain. Finally, the test suite is still fragile, and
while I see efforts to convert to ExUnit and Elixir, the fragility is
not being resolved at the same time, near as I can tell - nor is it
eliminating our dependence on test timeouts. (Removing those timeouts
entirely would make cross-platform building an easy way out of requiring
multiple CI build agents per target processor architecture.)
These challenges *are* solveable, but they deserve more than just "quick
fixes."
-Joan "so much work, so little time" Touzet
[1]:
https://lists.apache.org/thread.html/528962b6b1fe0e96277f5ebeb0e75ea5460061cf33bf9c2c796200a0@%3Cbuilds.apache.org%3E
[2]: https://github.com/apache/couchdb-docker/issues/68
[3]: https://github.com/apache/couchdb-docker/issues/85
[4]:
https://lists.apache.org/thread.html/af52e2a3e865c01596d46374e8b294f2740587dbd59d85e132429b6c@%3Cbuilds.apache.org%3E
-------- Forwarded Message --------
Subject: External CI Service Limitations
Date: Tue, 02 Jul 2019 21:50:51 -0000
From: Daniel Gruno <hu...@apache.org>
Reply-To: builds@apache.org
To: builds@apache.org
Hi folks,
As this seems to be a hot topic as of late, I'll provide some
information about our usage of external CI services.
Travis CI: The foundation has an agreement with Travis CI to provide our
projects with external CI services through them. At current, we have
approximately 40 executors there, half of which are currently
(build-time-wise) being occupied by three projects; Flink (21%), Arrow
(18%) and Airflow (13%). The foundation is currently not looking at
increasing the number of executors there, as we are assessing long-term
costs and benefits, and we advise projects that have higher immediate
needs for CI to either use our Jenkins CI system or figure out a
budget/plan (whether that be internal or external to the foundation) for
other options, and to also assess whether the number of builds and their
duration fit with the overall goal of the CI need and the resources
available at our disposal. Currently, all projects have, as of this
week, been capped at 5 concurrent builds with Travis.
AppVeyor and CircleCI: The foundation makes use of the free tier of
these, as we have not received any requests for an increase, nor
assessed whether this is beneficial, and as there are, as things are
right now, permission issues that go against our standard policies for
repository access.
With regards, Daniel on behalf of ASF Infra.