131–140 of 301 posts
Earlier quoted context omitted.
You can self-host Gitlab CI runners and use them even in the free community version.
I know, this is what I’ve been doing for years. ( edit on GitHub, not GitLab, didn’t know GitLab allowed community CI now)
Innovation isn't just about speed; it's about understanding the nuances of user needs and market dynamics. Even the fastest CI can face hurdles if it doesn't align with the broader ecosystem's expectations and requirements.
This right here. I have found some of the greatest products I have used came from: "I'm working on this project, the tools I currently have are just different forms of a hammer...I need a screwdriver. I built a screwdriver. This screwdriver is the only tool I'll consider when I face this situation." The tools sell because the people doing the work and feeling the pain react strongly while pointing at the incompetent…
For instance:
- Slack emerged because teams needed a more efficient way to communicate than traditional email chains. It was built as a communication tool for a gaming company and then pivoted to become the go-to messaging app for businesses.
- Docker was developed out of the frustration of "it works on my machine" syndrome. It provided a consistent environment, making software deployment more predictable and efficient.
- Trello was born out of the need for a visual project management tool that was intuitive and easy to use, unlike complex project management software.
These tools became popular not just because they were innovative, but because they addressed real pain points felt by those on the ground. When decision-makers overlook these grassroots solutions, they risk alienating their most valuable assets: the people doing the work.
Earlier quoted context omitted.
It's not a solved problem, very few builds in the wild are deterministic and reproducible. You have to build up the universe from scratch (like guix and nix) for the caching to be sound enough to be reliable. Just because an algorithm exists that can help doesn't mean that the universe of software can fit cleanly into a model where that algorithm is perfect. The other fundamental problem with this model is that it ca…
> very few builds in the wild are deterministic and reproducible There's a difference between 'deterministic and reproducible' and 'predictable'. Sure I can (probably) build curl ten times and get ten technically different binaries, but the differences aren't relevant to the functioning of the actual result. Assuming my build environment isn't changing out from underneath me (i.e. if I'm using the same versions of th…
Take your curl example. Its inputs are its dependencies. Now say you depend on libcurl and a more recent version of glibc than curl was compiled against. If you only track the hashes of inputs to determine if something needs to be rebuilt, then in this scenario you will have to rebuild libcurl.
What you're talking about (determining if your dependencies are "valid" and don't need to be rebuilt) involves tracking compatibility metadata out-of-band of the actual content of the build artifacts, which is not a solved problem.
The point about reproducible builds is that they're required for any kind of build system that depends on content hashing to determine if something needs to be rebuilt, because it's actually impossible to track that based on the content alone.
It gets hairier when you start abstracting what a build artifact that depends on another build artifact is, because there's more to builds than object files, dlls, and executables.
Earlier quoted context omitted.
I must admit I'm a bigger fan of the wireit[0] approach, the only pause I have is its a Google project, my temptation is to fork it. The code isn't terribly complex My biggest complaint with NX is: lack of a sane API for plugins, and it has more overhead than I'd care for. For the amount of complexity that NX has, I'd rather use Rush[1] which gives you everything NX does. My only complaint with Rush is that its devel…
Curious about your thoughts on turbo?
It worked relatively well for somethings, namely builds and focused watch mode (like running watch only on apps via the build tool, e.g. vite or webpack). I don't like that they punted their remote cache to basically be "Sign up for this vercel service or read our API contract, which BTW can change without notice".
It also lacks a smart workspace watch mode, which is frustrating. This is something that wireit in particular does really well. If you look at the GitHub discussions / issues for turbo, they stated that they're effectively only going to implement a watch mode when `turbopack` is ready, because they want to integrate it into turbo in some way.
I don't think I had issues with the cache otherwise. You can, for instance, just keep an artifact in your CI of the turbo cache (its a `.turbo` directory in the root of your repo) and while not shared with your local, it works fine enough.
It didn't have any smart masking of logged output either, so you have to be consciously aware of what gets logged to the console. Not usually an issue, but works well enough.
To be honest though, developing against apps was okay, but if you needed distributed watch mode across apps and libraries (say, a design system or something) it was awful, because turbo doesn't have its own smart dependency graph based watch mode startup, you just end up starting watch mode across all your dependencies with mixed results. For instances, it would trigger builds that could easily go stale or have issues if not built in the correct order, which you completely forgo because you have to use `--parallel`[0] to use watch mode. I also had dependency chain issues with HMR due to out of band builds happening etc.
You can hack around this with things like nodemon, but its really a terrible experience.
It also lacked proper support for phased commands, you had to hack it via pipelines which meant you didn't get 100% unique distributed tasks, which could become an issue with caching if you aren't aware of this. (using && in a script entry is not a substitute here, and declaring dependent pipelines felt like you were doing it wrong, not to mention, added overhead in some scenarios)
All in all, it was fine, but I like the wireit model a bit better.
Turbo also does nothing around module boundary enforcements. This is one thing NX and Rush do well if you use tags. wireit doesn't have this concept on a allow / deny level, but it does have it on a explicit dependency declaration level. Turbo has neither.
I'm a bit wary of Vercel. They way they treat their open source projects and community feedback sometimes give me pause. I'm sure they're great people doing their best, I have concerns the same as I do with Google here.
[0]: https://turbo.build/repo/docs/reference/command-line-referen...
Earlier quoted context omitted.
I know, this is what I’ve been doing for years. ( edit on GitHub, not GitLab, didn’t know GitLab allowed community CI now)
I thought using your own runners for free in Gitlab was already an option before Github Actions even existed
Earlier quoted context omitted.
> Azure DevOps is the devil. Amen to that!
Is there an actual technical point beyond ”MS bad” for this sentiment? Honestly asking, as I’ve been mostly hearing positive things about AzDO, and from developers of all people.
(One of the most recent signs of this crazy zombie state that a recent feature for AzDO was given the absurd only Microsoft could do brand name "GitHub Advanced Secure for Azure DevOps", and it is indeed a bundle of GitHub features several years old at this point finally provided to AzDO users. Other signs include all sorts of AzDO libraries and roadmaps and related repos openly hosted on GitHub with last updated dates in 2019 and 2020.)
From an outsider perspective, Microsoft probably has a lot of sentimental and internal engineering reasons it doesn't want to truly wrap up so much of its operations in North Carolina (AzDO's ancestral home going back to early days of TFS), but the writing seems to be on the wall that what's left is a skeleton crew mostly working for GitHub full time and then sort of applying things part time back to AzDO. It doesn't seem to me to be sustainable long term, and every day it feels more like an Old Yeller situation where Microsoft is just prolonging the inevitable and making the pain worse for everyone involved.
Earlier quoted context omitted.
ADO makes me yearn for Jira. The boards are terrible, the UI is hard, the permissions are incomprehensible, it doesn't even integrate that nicely with Azure. On paper it does everything, it practice it can be made to do everything, but it's like getting citrus drenched sandpaper papercuts every day.
Hah, thanks for that mental image. As I said the positivive sentiments I heard came from developers, and TFA is about CI (rather than boards etc. that JIRA handles, so is there maybe anything remotely positive in how AzDO implements CI, git integration, testing, etc? Or is it just rotten to the core? Hard to imagine someone would hate it more than Bitbucket Pipelines or, god forbid, Bamboo. Buuut I’m more than open-m…
That sounds similar to https://concourse-ci.org/
I quite like it, but it never seemed to gain traction outside of Cloud Foundry.
Earlier quoted context omitted.
It's one thing to know a build failed, it's another thing to know why and how a build failed, where it failed, and what the cause was. If I have to swim through or context shift to a separate build system's output to get that, what is this actually doing for me?
From the post: > Earthly gives you write once, run anywhere build consistency, making it super easy to reproduce CI failures on your local computer.