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