Psa : perhaps time for maintainers to start migrating off Travis ci

newer
Teaching High-School one-semester...

Carter Schonwald

16 Nov 2020 16 Nov '20

1:02 p.m.

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile? 1) crazy long queue times/ latency for oss ci actions to run 2) very low concurrency on oss builds. 3) very low build build minute caps for oss that require high touch customer support contact to adjust. I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks. There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though. https://github.com/haskell-CI/haskell-ci/issues/411 Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

Attachments:

attachment.html (text/html — 1.5 KB)

Show replies by date

ulidtko＠gmail.com

16 Nov 16 Nov

1:15 p.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

Speaking of CI systems and OpenSource, I'd like to mention CircleCI as well: https://circleci.com/open-source/ (No affiliation, just a happy user.) Did have slightly negative experience with TravisCI recently, can confirm the sentiment. On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald wrote:

...

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

Mihai Maruseac

6:38 p.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

As a user of all of the following, GitHub Actions > Circle CI > Travis. You get much more control on Github Actions, you can cache stuff, you can control when it runs. On Mon, Nov 16, 2020 at 10:17 AM wrote:

...

Speaking of CI systems and OpenSource, I'd like to mention CircleCI as well: https://circleci.com/open-source/ (No affiliation, just a happy user.)

Did have slightly negative experience with TravisCI recently, can confirm the sentiment.

On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald wrote:

...
Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

Carter Schonwald

7:16 p.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

this mirrors my current understanding of all the choices myself, and it certainly helps that GH *explicitly* puts the OSS/free tier on equal or footing with paid customers. which absolutely makes sense given their various corporate structures (GH actions is a path to folks perhaps wanting to use azure services more organically? ) On Mon, Nov 16, 2020 at 5:39 PM Mihai Maruseac wrote:

...

As a user of all of the following, GitHub Actions > Circle CI > Travis.

You get much more control on Github Actions, you can cache stuff, you can control when it runs.

On Mon, Nov 16, 2020 at 10:17 AM wrote:

...
Speaking of CI systems and OpenSource, I'd like to mention CircleCI as well: https://circleci.com/open-source/ (No affiliation, just a happy user.)

Did have slightly negative experience with TravisCI recently, can confirm the sentiment.

On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald wrote:

...
Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

Joachim Durchholz

17 Nov 17 Nov

1:18 a.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

Careful about Github. It's currently OSS-friendly, but MS sometimes changes strategies abruptly, so they might move away from OSS, and much faster than Travis. Plus the more of Github's features you use, the harder it will be to migrate away from them when that happens (harder than with Travis). Maybe Gitlab is a viable alternative. At least the licensing is easier - the server code is MIT. They do dual licensing (Community and Enterprise Edition), so they could become "too commercial" over time, but if/when that happens, there's always the MIT-licensed Community Edition that can be taken over by volunteers for development. (Which in turn makes going full commercial less attractive for them, so it's a bit of a self-inhibiting prophecy.) (Disclaimer: I have no stake in the issue either way.) Am 17.11.20 um 01:16 schrieb Carter Schonwald:

...

this mirrors my current understanding of all the choices myself, and it certainly helps that GH *explicitly* puts the OSS/free tier on equal or footing with paid customers. which absolutely makes sense given their various corporate structures (GH actions is a path to folks perhaps wanting to use azure services more organically? )

On Mon, Nov 16, 2020 at 5:39 PM Mihai Maruseac mailto:mihai.maruseac@gmail.com> wrote:

As a user of all of the following, GitHub Actions > Circle CI > Travis.

You get much more control on Github Actions, you can cache stuff, you can control when it runs.

On Mon, Nov 16, 2020 at 10:17 AM mailto:ulidtko@gmail.com> wrote: > > Speaking of CI systems and OpenSource, I'd like to mention CircleCI as > well: https://circleci.com/open-source/ > (No affiliation, just a happy user.) > > Did have slightly negative experience with TravisCI recently, can > confirm the sentiment. > > On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald > mailto:carter.schonwald@gmail.com> wrote: > > Hey everyone: it looks like, from my perspective and experiences, > > that Travis ci should perhaps now be viewed as not open source > > friendly. Or even converging on hostile? > > > > 1) crazy long queue times/ latency for oss ci actions to run > > > > 2) very low concurrency on oss builds. > > > > 3) very low build build minute caps for oss that require high touch > > customer support contact to adjust. > > > > I’ve started moving my own projects slowly to gh actions for now, > > though there’s also gitlab ci , src hut and other options that may > > suit different folks. > > > > There’s definitely some ways to keep on having the clever cabal > > caching we know and love that folks like the Haskell-ci folks and > > others have hacked out for Travis be available on other platforms, > > though I don’t think there’s consolidated docs for those yet ? > > Def seen it discussed though. > > > > https://github.com/haskell-CI/haskell-ci/issues/411 > > > > Heres a url to my dupe ticket where I share an example naive use of > > the setup Haskell gh actions Config, definitely not perfect. But > > kinda amazing to have Mac and Linux and windows ci all in one ! :) > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

-- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Bryan Richter

1:54 a.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

I have to agree with Joachim. Everybody is good to OSS until it comes time to tighten the belt. That time has just come earlier to TravisCI than it has to Microsoft. None of these organizations are beholden to the people who use their services for free. Inversely, all of them ARE lawfully beholden to their owners and their paying customers. The viable long term strategies are (1) do it yourself [the blessing and curse of OSS], or (2) become a paying customer! On Tue, Nov 17, 2020 at 8:19 AM Joachim Durchholz wrote:

...

Careful about Github. It's currently OSS-friendly, but MS sometimes changes strategies abruptly, so they might move away from OSS, and much faster than Travis. Plus the more of Github's features you use, the harder it will be to migrate away from them when that happens (harder than with Travis).

Maybe Gitlab is a viable alternative. At least the licensing is easier - the server code is MIT. They do dual licensing (Community and Enterprise Edition), so they could become "too commercial" over time, but if/when that happens, there's always the MIT-licensed Community Edition that can be taken over by volunteers for development. (Which in turn makes going full commercial less attractive for them, so it's a bit of a self-inhibiting prophecy.)

(Disclaimer: I have no stake in the issue either way.)

Am 17.11.20 um 01:16 schrieb Carter Schonwald:

...
this mirrors my current understanding of all the choices myself, and it certainly helps that GH *explicitly* puts the OSS/free tier on equal or footing with paid customers. which absolutely makes sense given their various corporate structures (GH actions is a path to folks perhaps wanting to use azure services more organically? )

On Mon, Nov 16, 2020 at 5:39 PM Mihai Maruseac mailto:mihai.maruseac@gmail.com> wrote:

As a user of all of the following, GitHub Actions > Circle CI > Travis.

You get much more control on Github Actions, you can cache stuff, you can control when it runs.

On Mon, Nov 16, 2020 at 10:17 AM mailto:ulidtko@gmail.com> wrote: > > Speaking of CI systems and OpenSource, I'd like to mention CircleCI as > well: https://circleci.com/open-source/ > (No affiliation, just a happy user.) > > Did have slightly negative experience with TravisCI recently, can > confirm the sentiment. > > On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald > mailto:carter.schonwald@gmail.com> wrote: > > Hey everyone: it looks like, from my perspective and experiences, > > that Travis ci should perhaps now be viewed as not open source > > friendly. Or even converging on hostile? > > > > 1) crazy long queue times/ latency for oss ci actions to run > > > > 2) very low concurrency on oss builds. > > > > 3) very low build build minute caps for oss that require high touch > > customer support contact to adjust. > > > > I’ve started moving my own projects slowly to gh actions for now, > > though there’s also gitlab ci , src hut and other options that may > > suit different folks. > > > > There’s definitely some ways to keep on having the clever cabal > > caching we know and love that folks like the Haskell-ci folks and > > others have hacked out for Travis be available on other platforms, > > though I don’t think there’s consolidated docs for those yet ? > > Def seen it discussed though. > > > > https://github.com/haskell-CI/haskell-ci/issues/411 > > > > Heres a url to my dupe ticket where I share an example naive use of > > the setup Haskell gh actions Config, definitely not perfect. But > > kinda amazing to have Mac and Linux and windows ci all in one ! :) > > > > > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post.

-- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Christopher Allen

6:26 a.m.

GitLab CI has been really nice in my work and personal projects. Easy to add your own worker to the free site too. Sent from my iPhone

...

On Nov 17, 2020, at 00:56, Bryan Richter wrote:

I have to agree with Joachim. Everybody is good to OSS until it comes time to tighten the belt. That time has just come earlier to TravisCI than it has to Microsoft.

None of these organizations are beholden to the people who use their services for free. Inversely, all of them ARE lawfully beholden to their owners and their paying customers.

The viable long term strategies are (1) do it yourself [the blessing and curse of OSS], or (2) become a paying customer!

...
On Tue, Nov 17, 2020 at 8:19 AM Joachim Durchholz wrote:

Careful about Github. It's currently OSS-friendly, but MS sometimes changes strategies abruptly, so they might move away from OSS, and much faster than Travis. Plus the more of Github's features you use, the harder it will be to migrate away from them when that happens (harder than with Travis).

Maybe Gitlab is a viable alternative. At least the licensing is easier - the server code is MIT. They do dual licensing (Community and Enterprise Edition), so they could become "too commercial" over time, but if/when that happens, there's always the MIT-licensed Community Edition that can be taken over by volunteers for development. (Which in turn makes going full commercial less attractive for them, so it's a bit of a self-inhibiting prophecy.)

(Disclaimer: I have no stake in the issue either way.)

...
Am 17.11.20 um 01:16 schrieb Carter Schonwald: this mirrors my current understanding of all the choices myself, and it certainly helps that GH *explicitly* puts the OSS/free tier on equal or footing with paid customers. which absolutely makes sense given their various corporate structures (GH actions is a path to folks perhaps wanting to use azure services more organically? )

On Mon, Nov 16, 2020 at 5:39 PM Mihai Maruseac mailto:mihai.maruseac@gmail.com> wrote:

As a user of all of the following, GitHub Actions > Circle CI > Travis.

You get much more control on Github Actions, you can cache stuff, you can control when it runs.

On Mon, Nov 16, 2020 at 10:17 AM mailto:ulidtko@gmail.com> wrote:

...
Speaking of CI systems and OpenSource, I'd like to mention

CircleCI as

...
well: https://circleci.com/open-source/ (No affiliation, just a happy user.)

Did have slightly negative experience with TravisCI recently, can confirm the sentiment.

On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

...
Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Arian van Putten

18 Nov 18 Nov

1:23 p.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

Thanks for the example Carter. I've been struggling with Servant's CI since the recent Travis changes as CI now somtimes takes up to multiple hours to complete. It would be awesome if somebody would volunteer adding a Github or Gitlab backend to haskell-ci; such that I do not have to re-invent the entire CI systems that is in place currently from scratch though. Killer feature for us is the parsing of `Tested-With` in cabal files to adjust the build matrix; as e.g. not all our packages for on GHCJS for example. However your example doesn't look that complicated. I'm going to play around with it. On Mon, Nov 16, 2020 at 7:04 PM Carter Schonwald wrote:

...

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Groetjes, Arian

Joachim Durchholz

19 Nov 19 Nov

2:12 a.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

Am 18.11.20 um 19:23 schrieb Arian van Putten:

...

It would be awesome if somebody would volunteer adding a Github or Gitlab backend to haskell-ci;

What would be needed?

...

such that I do not have to re-invent the entire CI systems that is in place currently from scratch though Killer feature for us is the parsing of `Tested-With` in cabal files to adjust the build matrix; as e.g. not all our packages for on GHCJS for example. I.e. volunteers would need to know (or learn) what's there currently.

Other question: What kind of hardware would be needed? I.e. how much CPU/RAM to get the queues emptied quickly enough. Regards, Jo (Disclaimer: I cannot volunteer due to lack of time, just trying to contribute whatever tooling ops knowledge I happen to have.)

Carter Schonwald

3:40 p.m.

New subject: Psa : perhaps time for maintainers to start migrating off Travis ci

I've gotten things to be even nice and working on windows finally! (including having the steps shared on on platforms in a single buildway :) ! ) plus figuring out how to sidestep a fun / terrible issue on windows , but now fixed for me :) https://github.com/cartazio/ralist/actions/runs/373071421/workflow is the current one i have and attached is a copy that should be easy to adapt enjoy! On Wed, Nov 18, 2020 at 12:23 PM Arian van Putten wrote:

...

Thanks for the example Carter.

I've been struggling with Servant's CI since the recent Travis changes as CI now somtimes takes up to multiple hours to complete.

It would be awesome if somebody would volunteer adding a Github or Gitlab backend to haskell-ci; such that I do not have to re-invent the entire CI systems that is in place currently from scratch though. Killer feature for us is the parsing of `Tested-With` in cabal files to adjust the build matrix; as e.g. not all our packages for on GHCJS for example.

However your example doesn't look that complicated. I'm going to play around with it.

On Mon, Nov 16, 2020 at 7:04 PM Carter Schonwald < carter.schonwald@gmail.com> wrote:

...
Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Groetjes,

Arian

Carter Schonwald

13 Dec 13 Dec

2:59 p.m.

New subject: heres a replacement CI template using gh actions: Psa : perhaps time for maintainers to start migrating off Travis ci

https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549a... is my current iteration On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald wrote:

...

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

Joachim Durchholz

5:52 p.m.

New subject: heres a replacement CI template using gh actions: Psa : perhaps time for maintainers to start migrating off Travis ci

Not wanting to dishearten you, but Github *was* acquired by Microsoft, and that company has changed policy more often than I have appendages to count. Which means that replacing a Travis workflow with a Github workflow isn't improving anything, it's merely another station on the CI caravan's route. Gitlab *is* publishing large parts of their server-side code. Set up a local test installation, make sure that CI automation runs there, then migrate to Gitlab - that's the strategy I'd choose, YMMV. Gitlab may become FOSS-unfriendly over time just like any other commercial entity, but their barrier is significantly higher: The will loser more users and faster if they try anything funny with their policy, because then people will just run their own servers. Their current policy is a bit of a "we promise to remain FOSS-friendly, because, see? - we're locking ourselves in your corner" plot, and of course me advertising this is exactly what they want to achieve :-) DISCLAIMER: I am NOT affiliated with Gitlab in any way. Or with any other commercial entity offering services to the open-source community. Regards, Jo Am 13.12.20 um 20:59 schrieb Carter Schonwald:

...

https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549a... is my current iteration

On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Carter Schonwald

6 p.m.

New subject: heres a replacement CI template using gh actions: Psa : perhaps time for maintainers to start migrating off Travis ci

If you’re volunteering to do the legwork to have easy peasy ci setup for me, I graciously accept! Otherwise I don’t see how this critique is advancing a constructive dialogue. Your suggestions aren’t concretely actionable for me given finite time. If you choose to do some community organizing to advance this approach you’re advocating, I look forward to using it. Else it’s just putting down something I’m sharing in the open in hopes it has use for other folks. Happy holidays! -Carter On Sun, Dec 13, 2020 at 5:53 PM Joachim Durchholz wrote:

...

Not wanting to dishearten you, but Github *was* acquired by Microsoft, and that company has changed policy more often than I have appendages to count. Which means that replacing a Travis workflow with a Github workflow isn't improving anything, it's merely another station on the CI caravan's route.

Gitlab *is* publishing large parts of their server-side code. Set up a local test installation, make sure that CI automation runs there, then migrate to Gitlab - that's the strategy I'd choose, YMMV.

Gitlab may become FOSS-unfriendly over time just like any other commercial entity, but their barrier is significantly higher: The will loser more users and faster if they try anything funny with their policy, because then people will just run their own servers. Their current policy is a bit of a "we promise to remain FOSS-friendly, because, see? - we're locking ourselves in your corner" plot, and of course me advertising this is exactly what they want to achieve :-)

DISCLAIMER: I am NOT affiliated with Gitlab in any way. Or with any other commercial entity offering services to the open-source community.

Regards, Jo

Am 13.12.20 um 20:59 schrieb Carter Schonwald:

...
https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549a...

...
is my current iteration

On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Joachim Durchholz

15 Dec 15 Dec

5:29 p.m.

New subject: heres a replacement CI template using gh actions: Psa : perhaps time for maintainers to start migrating off Travis ci

Am 14.12.20 um 00:00 schrieb Carter Schonwald:

...

If you’re volunteering to do the legwork to have easy peasy ci setup for me, I graciously accept!

I have to politely decline.

...

Otherwise I don’t see how this critique is advancing a constructive dialogue.

Somebody with enough time may decide to give Gitlab a spin that might have been unaware. So yes it is constructive. Just not in a direction that helps you - but now you do have to accept hat people may pursue different strategies than yours, do you?

...

Your suggestions aren’t concretely actionable for me given finite time.

Neither is your suggestion that I do the legwork.

...

If you choose to do some community organizing to advance this approach you’re advocating, I look forward to using it. Else it’s just putting down something I’m sharing in the open in hopes it has use for other folks.

Temporary solution or not, your work is certainly going to be better than nothing at all! So feel free to go ahead. (Well, you are free to do whatever you like anyway, I have no say at all in what you do or what you consider best ;-) ) Regards, Jo

Christopher Allen

5:34 p.m.

New subject: heres a replacement CI template using gh actions: Psa : perhaps time for maintainers to start migrating off Travis ci

I use GitLab CI when I have the option. The Docker integration is pretty helpful. If you're willing to deploy your own GitLab CI instance, you can use Docker-in-Docker to build and deploy Docker images into production. I wrote a blog post explaining why I use and prefer GitLab CI: https://bitemyapp.com/blog/why-i-use-gitlab-ci/ I typically use the hosted CI (on Gitlab.com) and then when I need to speed up builds, I run CI workers on my own machines. Very pleasant. It has a few minor limitations to do with how much control you have things in the YAML but it can be worked around if you need to. I've used GitLab CI on several production projects, some of them belonging to an employer. I also use it for my personal projects. Hope this helps. Cheers, Chris Allen On Sun, Dec 13, 2020 at 4:53 PM Joachim Durchholz wrote:

...

Not wanting to dishearten you, but Github *was* acquired by Microsoft, and that company has changed policy more often than I have appendages to count. Which means that replacing a Travis workflow with a Github workflow isn't improving anything, it's merely another station on the CI caravan's route.

Gitlab *is* publishing large parts of their server-side code. Set up a local test installation, make sure that CI automation runs there, then migrate to Gitlab - that's the strategy I'd choose, YMMV.

Gitlab may become FOSS-unfriendly over time just like any other commercial entity, but their barrier is significantly higher: The will loser more users and faster if they try anything funny with their policy, because then people will just run their own servers. Their current policy is a bit of a "we promise to remain FOSS-friendly, because, see? - we're locking ourselves in your corner" plot, and of course me advertising this is exactly what they want to achieve :-)

DISCLAIMER: I am NOT affiliated with Gitlab in any way. Or with any other commercial entity offering services to the open-source community.

Regards, Jo

Am 13.12.20 um 20:59 schrieb Carter Schonwald:

...
https://github.com/cartazio/ralist/blob/495c3dcb3a8e16a693a97a415f731907549a...

...
is my current iteration

On Mon, Nov 16, 2020 at 1:02 PM Carter Schonwald mailto:carter.schonwald@gmail.com> wrote:

Hey everyone: it looks like, from my perspective and experiences, that Travis ci should perhaps now be viewed as not open source friendly. Or even converging on hostile?

1) crazy long queue times/ latency for oss ci actions to run

2) very low concurrency on oss builds.

3) very low build build minute caps for oss that require high touch customer support contact to adjust.

I’ve started moving my own projects slowly to gh actions for now, though there’s also gitlab ci , src hut and other options that may suit different folks.

There’s definitely some ways to keep on having the clever cabal caching we know and love that folks like the Haskell-ci folks and others have hacked out for Travis be available on other platforms, though I don’t think there’s consolidated docs for those yet ? Def seen it discussed though.

https://github.com/haskell-CI/haskell-ci/issues/411

Heres a url to my dupe ticket where I share an example naive use of the setup Haskell gh actions Config, definitely not perfect. But kinda amazing to have Mac and Linux and windows ci all in one ! :)

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Chris Allen Currently working on http://haskellbook.com

1617

Age (days ago)

1646

Last active (days ago)

List overview

Download

14 comments

7 participants

participants (7)

Arian van Putten
Bryan Richter
Carter Schonwald
Christopher Allen
Joachim Durchholz
Mihai Maruseac
ulidtko＠gmail.com