91–100 of 148 posts
Have spent several days over the past few months working on a reimplementation of Nix support to make it possible to wind down "community" support without forcing projects to find a new CI.
Feels like a lot of wasted effort. :/
Travis has an FAQ whose URL says "open source repository migration", but whose on-page title says "Migrating repositories to travis-ci.com" Travis Staff accounts in the travis "community forum" were linking to this FAQ as recently as 9 days ago, which still at this moment contains a question: > Q. Will Travis CI be getting rid of free users? # > A. Travis CI will continue to offer a free tier for public or open-sourc…
Was the "free plan" added after you commented?
> Free Plan
> Free
> - 10000 Credits
> - Unlimited unique users
> - Private & Open-Source Repos
> - Windows, Linux, MacOS
Earlier quoted context omitted.
Or use a CI/CD tool that natively supports Docker, like Concourse. Added bonus is that pipelines are defined in YAML rather than web GUI so you can version control the pipelines themselves and not just any build or test suites.
Jenkins pipelines are written in Groovy and you do not need to use the web ui, everything is exposed via its API (i.e: new job creation). I have heard good things about Concourse, want to give it a try in the future!
There's several ways you can codify Jenkins pipelines, Groovy being just one of them. But ultimately it's secondary to the main design of Jenkins. I'm not taking anything away from Jenkins as a solution - it has been invaluable over the years. But the way we write, test and deploy software has changed since Jenkins rose in popularity and as such we need to rely on different workflows that utilise different tooling. While Jenkins can be used in that way, I'd sooner use something which was primarily designed to be configured via code and used docker by default rather than something that requires enforcement to follow those best practices. That doesn't necessarily mean Concourse, there's Travis, Circle CI, AWS CodeBuild and a bunch of others that all default to that kind of workflow too, but it does mean I'm unlikely to ever advocate Jenkins again in future jobs.
I am rooting for the SourceHut CI[1][2][3]. Along with other services it has proven useful even at the current (alpha stage). Also it's the only one that supports both FreeBSD and OpenBSD (NetBSD support is unfinished [4]) [1] https://builds.sr.ht/ [2] https://man.sr.ht/tutorials/getting-started-with-builds.md [3] https://man.sr.ht/builds.sr.ht/compatibility.md [4] https://git.sr.ht/~sircmpwn/builds.sr.ht/tree/master…
As someone pointed out here the other day. With build minutes as a concept they're inherently incentivized to keep old slow gear running as well.
I reckon self-hosted gitlab is a good bet, but admittedly tricky for big FOSS projects that need to be public
Earlier quoted context omitted.
Sounds like your describing what I like to call a fancy build system Something like Bazel[0], Buck[1] Pants[2], etc. One of their main features is robust caching of build artifacts, which is helpful for larger projects. But they require some major investment compared to your typical `scripts/build.sh`. [0]: https://bazel.build [1]: https://buck.build [2]: https://www.pantsbuild.org
Gradle can also do everything imaginable, we've managed to get rid of basically all our horrible bash scripts and wrote most build stuff using Gradle API and using a proper programming language (put actual code in Gradle's buildSrc/, only configure it in build.gradle, and you've got a extremely powerful build).
I've been using Travis on a bunch of my opensource projects and was wondering why builds were getting queued for ~a day before they'd run, I guess I got my answer. :/ I don't really want to lock myself into GH actions (ideally, I wouldn't be on GH at all), does anyone have any suggestions for alternatives? I don't mind paying some money, but the almost $1K/year for Travis' lowest tier is about an order of magnitude m…
Github Actions really is a freakin awesome product. Yeah, there's lock-in, but their free plan (and cheap Pro plan for individuals) offers a great value. And, really, CI is CI; if you ever need to migrate, even for this guy with hundreds of projects it should only take a couple days. Once you've seen one CI yaml file, you get the gist of what all of them do. Other options: * Gitlab CI. Good value, great integration w…
Yep. Now I'm thinking on migrating my AppImage build scripts (Travis CI + Transfer.sh used for my projects on GitHub) from Travis CI to Gitlab CI. Hope, that there is simple "3-step switch" option.
Really appreciate those FLOSS projects which already use "Gitlab repo + Gitlab CI" to build & provide builds/artifacts, e.g. GrafX2[0], Inkscape[1], etc.
I know from experience that CI takes a lot of time, but even the very worse one that I have worked so far (dozens of parallel runs on different machines and a thousand lines of yaml) only took me 3 days to migrate.
One thing I will say - I like the way that you've done your migration. I'm very wary of using defined actions written by GitHub or otherwise, because it seems to me that it leads to vendor lock in for CI.