[HN Gopher] We built the fastest CI and it failed
___________________________________________________________________
We built the fastest CI and it failed
Author : adamgordonbell
Score : 358 points
Date : 2023-09-12 14:07 UTC (8 hours ago)
(HTM) web link (earthly.dev)
(TXT) w3m dump (earthly.dev)
| consoomer wrote:
| We work in an industry where senior developers don't know the
| difference between git and Github. The same seniors don't know
| the difference between Github actions, Travis CI and have never
| heard of Jenkins. Hardly anyone cares.
|
| Are you going to sell this to a startup? I doubt it. Are you
| going to sell it to a smb or enterprise company? Maybe.
|
| Is there a market to make cash there? Sure. Is it what I would
| want to make and try selling? Hell no.
| bluGill wrote:
| Why should senior devs know that? Someone needs to know those
| differences, but on a large enterprise project you have a team
| that keeps the CI system working. The rest need to know how to
| checkin a file and how to check the CI output. They shouldn't
| care about those details.
|
| I expect any senior developer CAN learn the above things.
| However that doesn't mean they are worth knowing.
| cyberpunk wrote:
| Just to be clear, your question is: why should a senior
| developer -- whose job ultimately involves managing a complex
| set of text files -- understand basic concepts behind the
| industry standard tooling for managing ... text files?
|
| Complete waste of time, they should be out playing golf with
| a board member instead, right..
| bluGill wrote:
| They need as much as a junior to get the job done. Then
| they should focus on the hard problems many of which are
| not tooling related.
|
| However if a different team has made a good ci system they
| don't need to know how it works, just enough to diagnose a
| build error they didn't see locally. Likewise, someone
| needs to know the details of git, but there is no need for
| everyone to know the details of that mess (git is a
| particularly bad version control, I wish the world had
| settled on something else - there are several better
| choices) so long as you can do the basic commits, merges
| and checkouts. Most senior developers need to know how to
| add a text file to cmake (or whatever your build system
| is), but there is a lot more you can do with a build system
| that only a few need to know.
|
| Senior devs need to be great at the problem domain they are
| in. That is normally the subsystem they write code in, and
| good architecture therein. They need to be able to figure
| out all the tools you list and more, but becoming experts
| in them all is a waste of time if enough others already
| are.
| prpl wrote:
| Enterprise is moving to bazel or similar, often with build
| caches, and using partial builds on checkin based on what's
| changed.
| no_wizard wrote:
| really depends on the enterprise.
|
| I know of quite a few that have buyers remorse over Bazel
| because they ended up having to have dedicated engineers to
| keep it working.
|
| There's alot of room for easier to manage Bazel alternatives
| and I believe enterprises are willing to pay for them.
| hotnfresh wrote:
| Enterprises with strong, opinionated, tech org leadership,
| maybe.
|
| The rest are shuffling around between solutions that haven't
| been state-of-the-art in 15 years or more, and usually
| purchased or bundled from some giant vendor or another, as
| usual.
|
| They're ahead of the curve if they have any standard widely-
| implemented CI solution that's fully in use and not one of
| three (or more) in various stages of being adopted,
| maintained, and phased out, in fact.
| fukpaywalls2 wrote:
| Another big "channel" is getting someone to proof "ready" the
| article.
| _whiteCaps_ wrote:
| > Imagine you live in a world where no part of the build has to
| repeat unless the changes actually impacted it. A world in which
| all builds happened with automatic parallelism. A world in which
| you could reproduce very reliably any part of the build on your
| laptop.
|
| That sounds similar to https://concourse-ci.org/
|
| I quite like it, but it never seemed to gain traction outside of
| Cloud Foundry.
| AlphaWeaver wrote:
| We spent some time evaluating this on my team, and we're still
| experimenting with it.
|
| I like it a lot, but the project appears to be mostly
| unmaintained since mid-2021, when the creator left it to work
| on a lispy CI/CD tool [0] that feels very complicated... not
| sure what's going on there.
|
| [0]: https://github.com/vito/bass
| mcnichol wrote:
| Not to rain on the parade here but this is literally a copy-pasta
| product.
|
| Jenkins, Google Borg, Cloud Foundry, Concourse Pipelines...and
| surprise surprise when you look at where he came from...Ex-
| Google, Ex-VMW, RabbitMQ...
|
| If OP wasn't in and around the source of all these tools above
| then they were at the very least first cousins to the story.
|
| The sales cycle is long, integrations require multiple dimensions
| of executive buy-in, especially security and networking.
|
| I think they made something nice but it felt like a nothing-
| burger story about something that is constantliy oscillating
| between bespoke and commoditized due to upstream problems that
| are such a mix of issues. Lack of oversight to micromanagement,
| inexperience to too much experience that they cannot let go of
| "the way it's always done".
|
| It may be just my unpopular opinion but you are boiling an ocean
| of problems selling toolchains. Business and Tech are like water
| often finding the holes that lead to a path of least resistance,
| even when these erode the foundation of "core business".
| Toolchains that behave like guidelines and "parenting strategies"
| with removable guardrails have always offered the greatest
| rewards in my experience.
| rewmie wrote:
| > Not to rain on the parade here but this is literally a copy-
| pasta product.
|
| More to the point, the product offered no compelling reason to
| use it, let alone pay for it.
|
| Being "fast" is not a selling point. Developers don't want slow
| pipelines, but that does not mean they want fast pipelines. The
| speed that the pipeline works is more depending on how the
| pipeline is setup than the overhead of the pipeline service,
| and other CICD services are already blazing fast. Take for
| instance CircleCI, which is already a tough sell over GitHub
| actions and GitLab CICD: how did the service stood out? Did it
| added tangible value over GitHub/Gitlab/CircleCI/etc? Shaving
| milliseconds off a minutes-long build ain't it.
| pixl97 wrote:
| Reliable, configurable, and compatible. That's what, at least
| from the work I do, seems to be what the market is looking
| for.
|
| Most CI/CD for sizeable companies have integrations into
| other systems, such as static analysis and things lime SBOM.
| Those tools tend to take a bunch of time outside the CI. They
| also need to ensure the results from those tools can break
| builds along with other alerting. Eventually the CI itself
| becomes a small fraction of total execution time.
| mcnichol wrote:
| Absolutely.
|
| If you told me:
|
| "This pipeline will automatically perform all of your [insert
| line of business] testing, batteries included.
|
| XYZ has signed off that if you get to the end of this
| pipeline you do not need to jump through any hoops to get to
| production." I would be screaming on a soapbox
|
| There is too much process to know about a company to make any
| claim with any certainty and these companies will not tell
| you their process because you are a salesman, not their
| friend. Technology Sales is "Frenemys" at best and "Inherited
| Cancer" at worst.
|
| Here's a pitch for OOP. If you do this you will have a line
| around the door: "You can run this on your own internal
| cloud, public cloud, or mix of both. Hit the eject button and
| it will give you a [Docker, CircleCI, Jenkins, Travis]
| playbook to lift and shift your pipeline. Every app that goes
| through alerts each C?O that cares how it meets their KPI,
| Security Whatever, etc.
|
| Set the bar as high as you want to get through the pipeline.
| Mission Critical? Core Business? Skunkwerks? This can be in
| the DMZ, this can't...you make the rules, we are the engine
| that enforces them."
|
| I can tell you right now, your success will be predicated on
| Networking and Security teams that work together effectively
| and selling high enough to start the ball rolling.
|
| We have this absurd "Throw paint at a wall and see what
| sticks" approach to doing business and then "People don't
| really want what I made" response when it fails. Look inward.
| internet101010 wrote:
| Yeah unless I have something that requires really low latency
| or something I am taking ease of configuration every time.
| bluepuma77 wrote:
| Why have examples with JavaScript, when no build process is
| needed?
|
| Why not use TypeScript or even something like SvelteKit, which
| has a raving fan-base which is obviously working with bleeding
| edge tech that is still rough around the edges?
| huijzer wrote:
| I have no personal experience with selling a SaaS, but read that
| AWS mostly sold to startups at first because there were no
| migration costs yet. Out of curiosity, has the same been
| attempted with Eathly and, if yes, did that work?
| linuxdude314 wrote:
| Anyone else find it strange how the author uses CI as a noun?
|
| I've never heard anyone refer to a CI platform/system this way
| before and it sort of strikes me as a red flag.
|
| Also the idea of running CI on your laptop seems questionable at
| best, downright irresponsible and insecure at worst.
|
| Sure faster builds are nice, but by the time you're running your
| code through CI/CD its not usually after adding a few lines of
| for a feature, it's when the completed feature ready to merge or
| some sort of integration test is needed.
| xwowsersx wrote:
| > Anyone else find it strange how the author uses CI as a noun?
|
| Do you mean using the term "CI" with no other
| modifiers/qualifiers?
|
| > Also the idea of running CI on your laptop seems questionable
| at best, downright irresponsible and insecure at worst.
|
| Didn't you also use CI as a noun here? And isn't it a noun?
|
| > Sure faster builds are nice, but by the time you're running
| your code through CI/CD its not usually after adding a few
| lines of for a feature, it's when the completed feature ready
| to merge or some sort of integration test is needed.
|
| I hear you, but not necessarily. You might have a test suite
| that runs in CI and after you open your PR, you continuing
| pushing to it and it's nice to have a fast pipeline.
| ahtihn wrote:
| I'm confused why you think fast CI/CD doesn't matter. In an
| ideal world, every commit you make goes through the full
| pipeline and ideally it's so fast that you get immediate
| feedback.
|
| The only reason that you're delaying code going through the
| pipeline is that it's slow.
| aftbit wrote:
| I think the idea is to run the CI on your laptop for debugging
| and building the CI process itself. This dramatically shortens
| the build-test cycle (for the CI, not your product). Instead of
| "edit, git push, wait for runners, download logs, stare
| confusedly, repeat", you have "edit, run locally, watch logs,
| stare confusedly, repeat". Plus you can get real access to the
| actual runners, so maybe you can do things like strace, gdb,
| etc to see what is going wrong.
| augustk wrote:
| CI = Continuous Integration
|
| https://en.wikipedia.org/wiki/Continuous_integration
| gwbas1c wrote:
| Now is a good time to read "Crossing the Chasm:"
| https://en.wikipedia.org/wiki/Crossing_the_Chasm
|
| The book talks about the state of the business Earthly CI was in:
| They tried to go from enthusiasts to generalists... But with a
| completely new product!
|
| I don't think it was wrong to build a new CI; instead, I think
| the thing they did "wrong" was build a super-complicated CI; or
| that when they tried to cross the chasm, they tried to sell a
| (cough) completely different product than what their early users
| were using.
| Tao3300 wrote:
| Slow CI is a perk.
|
| https://xkcd.com/303
| nbittich wrote:
| A quick look at the documentation and I knew I'll bother using
| it. We have Jenkins, Drone, woodpecker, GitHub action. Targeting
| devs feels like it's the worst market to get in, specially after
| years of VC baked web3/GPT/ terminal/ ide / programming language
| 300000x faster than python with no tradeoffs offers.
| Anon_Forever wrote:
| Sometimes the best technology fails and the space is overtaken by
| lesser technologies. It can be something as silly and out of your
| control as timing. Maybe the competition came out a bit after you
| and grew faster as interest in the space rose astronomically in
| parallel.
| verdverm wrote:
| There are a bunch of these next-gen CI / container building
| systems. They all pretty much build on BuildKit like Docker, but
| unlock way more of the potential, namely DAG layers (think multi-
| stage docker on steroids), and better / more granular caching.
| These next-gen CI tools are fighting to be the UX on top of
| BuildKit.
|
| Dagger is where it is at, and it's built by the creators of
| Docker, based on their lessons learned. If you're looking to try
| something out, try Dagger. You write in the same languages you do
| every day, no need for some weird syntax like Earthly or the
| flatness of a Dockerfile. Their CLI/TUI is pretty sweet too, but
| you don't even need it.
| jameshart wrote:
| Tl;dr they made the mistake of assuming that since 95% of the
| time CI jobs spend is 'running builds' that a build system is 95%
| of a CI platform.
|
| This turns out not to be true.
| dpeckett wrote:
| Part of the issue is that the Earthly is pretty much a CI system
| in itself. Given that the value proposition of a hosted CI
| product based on it is pretty minimal. It really is a radical
| mindset shift and I can see why converting legacy organizations
| is such an uphill battle.
| px1999 wrote:
| > it didn't make sense for them to jump head-first into an
| expensive and time-consuming migration effort just because some
| startup they had never heard of promised to deliver the sun and
| the moon
|
| > we need to shut down Earthly CI
|
| Is it possible that it all boils down to these two points? The
| technical benefits don't matter if there's even a hint that your
| (fundamental to my business') service could fail and be removed.
|
| When I read this it sounds like a technically great idea which
| solved a problem in a way that missed some fundamental
| prerequisite for their target user group (and hence success).
| pshirshov wrote:
| Judging by the description, that project seems to be another DAG-
| planning meta-program with input-based memoization. This is the
| superior approach to fight complexity but, unfortunately, most
| engineers just don't understand the problem and the solution.
| Guvante wrote:
| It can be superior and not valuable to customers.
|
| People who don't have an existing build system don't have
| money.
|
| People who have an existing build system would need to migrate
| which can be super painful.
|
| And nothing in the article points to making it easier.
| alexvitkov wrote:
| What does fast CI even mean?
|
| CI is an overgrown shell script running your build and telling
| you when it fails. In general build tooling has gotten so slow
| that the cost of whatever CI runner relative to it should be nil.
|
| If you want fast CI you need fast tsc, clang, rustc, etc... not a
| faster program that calls exec on them.
|
| A bit more on topic, if you're selling CI and your business fails
| it's because people you're providing no value - people can run
| their build scripts fine without you.
| crabbone wrote:
| > CI is an overgrown shell script running your build and
| telling you when it fails.
|
| Oh, I wish it were that simple...
|
| But, I also don't know what they measured. But, I'll give you
| just one example. Jenkins default landing page is a disaster in
| terms of speed. It tries to display data on recent builds
| everywhere across your cluster. For even not so big clusters
| this can be hundreds to thousands of items to pull from
| individual nodes running those builds. I've managed to crash
| Jenkins more times than I could count by simply loading the
| landing page w/o a particular configuration added that prevents
| it from its default behavior.
|
| CI server will have its own database, typically, managing all
| sorts of CI entities: jobs, artifacts, users, secretes... It
| could be quite big and you'd do well taking care of proper
| indexing etc.
|
| CI will have its assortment of runners, which are often
| provisioned dynamically (think VM or Docker images that need to
| be deployed to runner nodes), distributing them across the
| cluster is also not an easy task, if you want that to work
| fast. Of course you also want to be able to distribute the
| artifacts across the cluster -- this also takes time and
| resources.
|
| CI will have its own bookkeeping necessary to, essentially, do
| garbage collection, reporting and self-diagnostic.
|
| In big enough clusters this stuff can have a very high latency,
| if you don't specifically work towards reducing that latency.
|
| > If you want fast CI you need fast tsc, clang, rustc, etc...
| not a faster program that calls exec on them.
|
| Ever heard of ccache?
|
| But, really, this is also super-naive. To make builds fast in a
| distributed system that CI is you would also need to figure out
| how to distribute this cache, how to modularize the builds...
| You might have heard about how one of the most difficult things
| in programming is cache invalidation? -- That's only partly a
| joke.
| jrockway wrote:
| The tricky part of CI is figuring out what work doesn't need to
| be done. That is how you save time.
| jve wrote:
| > If you want fast CI you need fast tsc, clang, rustc, etc...
| not a faster program that calls exec on them
|
| Yes and no. Caching stuff and knowing when to run
| tsc/clang/rustc also improves performance.
| bluGill wrote:
| Sure, but you have to be 100% perfect in guessing when the
| cache file must be rebuilt. If there is any situation at all
| where you use the cached file when you should have rebuilt
| your tool is not useful.
|
| Note that you can go too far. If you rebuild a file on linux
| even though the only changes were in a "#ifdef freebsd"
| (windows, mac...) section that is a waste of time, but not
| harmful. However we already have tools that do that.
| esafak wrote:
| This is a solved problem; modern build tools and workflow
| orchestrators face the same challenge. You declare your
| inputs for a given task and cache the output as long as the
| inputs are unchanged, as determined by their hash. So there
| is no wrong guessing, only an incomplete specification of
| inputs. It's an elegant solution, if I do say so, and has
| worked well at companies I've seen it used.
| zelos wrote:
| From my experience with Gradle, it's fairly tricky at the
| build tool level, trying to do it at the CI level must
| surely be harder.
|
| If (for example) I change a value in gradle.properties at
| the top level, do I need to rerun every test in every sub
| project? You need detailed knowledge of how the build is
| structured to decide that.
| duped wrote:
| 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
| cannot model cyclical dependencies (a degenerate case:
| glibc needs python which needs glibc). Since you can't
| hash the output until you've hashed the input, and the
| input hash depends on the output hash you need a way to
| break the dependency cycle. Tools have varying ways of
| mitigating this but it's not exactly "solved" in an
| elegant sense.
|
| And finally, a lot of build steps are faster than hashing
| their input and outputs. So if you want the utmost
| performance you need heuristics or a model that allows
| for some things to be hashed and others to always be
| considered fresh.
| danudey wrote:
| > 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 the
| same dependencies on the same platform with the same
| compiler toolchain, and I'm not passing in different
| arguments or environment variables) then the end result
| should be _functionally_ identical.
|
| > You have to build up the universe from scratch (like
| guix and nix) for the caching to be sound enough to be
| reliable.
|
| This is a false assertion. If I'm building (again, as an
| example) curl, then I don't need to be rebuilding the
| kernel, glibc, kerberos, libssh, gnutls, brotli, etc. all
| in order to get a working curl build; I just need to make
| sure the libraries and toolchains I have installed are
| valid. If I create a docker image with all of the
| dependencies and toolchains preinstalled, and then I
| build the exact same curl code inside of that docker
| container on two separate occasions, then the end result
| is going to be indistinguishable without hashing the
| build artifacts.
|
| > 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.
|
| It doesn't need to be perfect, it just needs to be
| correct for the vast majority of cases (which are not
| somehow inherently broken already and just haven't failed
| yet).
|
| > a degenerate case: glibc needs python which needs glibc
|
| Because you're not rebuilding the entire world (in 99% of
| cases), this doesn't actually matter. If you're building
| glibc use the existing build of python that you already
| have installed, which is the same identical version to
| the one you used last time you built glibc.
|
| If I'm rebuilding glibc, do I also need to rebuild
| python? If the glibc code hasn't changed, but maybe
| python has so I get a different result? Well okay, has
| the python source changed? No? Okay, have the
| dependencies for python or glibc changed? No? Okay, well
| problem solved then.
|
| I'm not sure why people have this philosophy of "this
| problem isn't solved because of some imaginary,
| unrealistic corner case that either shouldn't exist in
| the first place, isn't actually a real problem, or that
| no one will run into". In 99% of cases it works, and if
| it's not right for a particular circumstance then just
| _don 't use it in that circumstance_. Sometimes makefiles
| aren't the right tool. Sometimes a GUI isn't the right
| tool. Let's not argue that we shouldn't have GUIs because
| sometimes running a command on the CLI is easier, and
| let's not argue that an extremely basic caching system
| that makes sane assumptions that are almost always valid
| isn't a good idea.
|
| And the parent is right: if you correctly define your
| inputs and outputs, then the system works. What those
| inputs and outputs are is up to you to determine. Maybe
| for you, the outputs are a working build of glibc, and
| maybe the inputs are all of the tarballs necessary to
| build Linux from scratch and a working bootstrap
| environment, but if all of those inputs and that whole
| environment are identical to last time, what's the point
| of rebuilding any of them? Maybe there is one, but that's
| up to you to determine and model.
| Karellen wrote:
| > Sure I can (probably) build curl ten times and get ten
| technically different binaries
|
| I think assuming the same build environment, then
| building curl is actually deterministic and reproducible:
|
| https://tests.reproducible-builds.org/debian/rb-
| pkg/unstable...
|
| (It says reproducibility fails if CFLAGS is different,
| but I'd count that as a change in build environment?)
| duped wrote:
| I agree with you, but my point is ultimately that content
| hashing inputs like GP is arguing "solves" the problem
| doesn't actually solve the problem.
|
| 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.
| IshKebab wrote:
| It is a solved problem - you need to use a build system
| with sandboxing like Bazel, and also vendor all your
| tools.
|
| Almost nobody does that because very few people realise
| it is the solution and even fewer realise they're going
| to need that _before_ they set up their build system.
| danudey wrote:
| > you have to be 100% perfect in guessing when the cache
| file must be rebuilt
|
| Or, you make reasonable assumptions that are correct in
| most cases, and rely on the user to provide hints as to
| when the cache should be invalidated.
|
| Assuming your code, environment variables, and `args` are
| all factored into invalidating the cache, there are few
| situations _in typical builds_ where using the cache is a
| bad idea. The biggest ones I can think of are if your build
| system is going out and fetching data itself to decide what
| to do, e.g. if you 're downloading source code (e.g. a
| shared library) from an external source which may have
| updated it.
|
| That said, if you're just arbitrarily pulling down whatever
| the latest build of libcurl is or something, you're going
| to have a bad time eventually anyway, so you should either
| put a static version into an arg or just put the download
| into a separate step; at which point the cache will
| correctly invalidate when it's changed.
|
| Maybe if a build is only valid for 90 days from the build
| date or something (e.g. a preview build) and that's built
| into the binary at compile time, but in that case you can
| pass that in as an arg anyway and then your cache is going
| to be invalid every morning regardless.
|
| I'm not going to say it's never an issue, but the same code
| with the same environment and the same arguments, built on
| the same platform with the same versions of the same
| dependencies, using the same versions of the same tooling
| to run the same commands and copy the same artifacts to the
| same locations should _very nearly never_ produce a valid
| output now which is not an equally valid output in the
| future unless it is fetching and acting on external
| information (which can be easily parameterized).
| [deleted]
| jnwatson wrote:
| The only part of the Earthly pitch that resonated with me was
| the ability to run the CI locally. When debugging your CI, it
| is just faster to find problems when you can run on your own
| box.
|
| I have a gnarly GitHub Actions script that took forever to get
| right because the debug cycle was 10 minutes long.
| fireflash38 wrote:
| That's one of my biggest complaints about gitlab-ci. Theres
| basically no way to debug complex rules without just running
| it. They've got a way now to simulate for default branch, but
| that's like bare minimum necessary. No way to simulate based
| on vars or anything else. And no way to try locally, just
| gotta fucking send it live.
| ianwalter wrote:
| I feel you on that one. There is also Act
| (https://github.com/nektos/act) and Dagger.io.
| jcranmer wrote:
| Perusing this article quickly, it means a CI that is
| automatically handling things like caching build artifacts so
| that you don't need to recompile your entire repository every
| single commit. It's not about a faster program to call exec;
| it's about a program that knows it need not even call exec.
| dgb23 wrote:
| Isn't this a complex solution for a problem that shouldn't
| exist?
| aidos wrote:
| I looked at Earthly just a couple of weeks back. It's a tool
| that makes perfect sense - especially when I was deep in a
| makefile wishing the caching was as automated as docker.
|
| In the end I decided that I couldn't face the complexity of
| dealing with someone else's hosted tooling. Luckily in this
| case.
| alexvitkov wrote:
| Incremental builds are something even enterprise build
| systems fail at.
|
| I've had Visual Studio and MSBuild fail on me multiple times
| by deciding not to recompile a certain .cpp file, because
| they got the dependency graph wrong. This results in a
| running but inconsistent executable that's a bitch to debug.
|
| If you're selling me another tool that duplicates this work,
| but that has even less context on my project than the build
| system, I'll pass.
| no_wizard wrote:
| One thing these tools should do automatically is at the end
| log to the console (or whatever system) what was compiled
| and what wasn't.
|
| This made debugging so much easier for these issues.
| They're bound to happen, because we're all human and bugs
| are a thing. Automatically being able to audit the build as
| step 1 makes this easy to spot
| pharmakom wrote:
| Bazel does this.
|
| I have to be honest - MS Build does not scale well.
| Companies use it because it's the default.
| howinteresting wrote:
| Yes, but Bazel requires an all-in commitment and also
| tons of work to fit the rest of the world into it.
| CobsterLock wrote:
| I don't have a ton of experience in Bazel, but from what
| I have experienced with Bazel I think it would be more
| accurate to say that you configure the dependency graph
| yourself in Bazel. Then Bazel can determine what to build
| from scratch and what to take from cache
| no_wizard wrote:
| Seems they came up with a way to scale up build
| toolchains with BuildXL[0]
|
| Doesn't seem fully baked yet though
|
| [0]: https://github.com/microsoft/BuildXL
| theamk wrote:
| except not really.. their tutorial [0] includes no-compile
| languages like python and JS, with only non-trivial
| compilation being and Java... and how do they do it?
| RUN gradle build
|
| At least in this case, Earthly has no insight into how
| repository is organized, and it _will_ recompile the entire
| repository with every single commit.
|
| So what's the real value of it? this basically seems like a
| better "docker build" alternative, giving nicer inter-layer
| caching. Maybe will save some time on dependencies if they
| take some time to install and devs were too lazy to set up
| own workers and used ephemeral runners instead.
|
| [0] https://docs.earthly.dev/basics/part-1-a-simple-earthfile
| danudey wrote:
| That's step one, 'how to write a basic Earthfile that just
| does the thing', so they don't delve into the details of
| caching and how it works, but look at the whole block and
| not just that one line; it operates like a Dockerfile:
| build: COPY build.gradle ./ COPY
| src src RUN gradle build RUN gradle
| install SAVE ARTIFACT build/install/java-
| example/bin /bin SAVE ARTIFACT
| build/install/java-example/lib /lib
|
| The COPY phases copy files into the build context. If the
| files haven't changed, then the commands don't need to be
| run. In other words, if `build.gradle` and `src` are
| unchanged, it won't run `gradle build` or `gradle install`,
| and it'll just give you the artifacts from the previous
| build.
|
| They have a golang example in part three[0], which they
| redesign to use caching effectively:
| build: # Download deps before copying code.
| COPY go.mod go.sum . RUN go mod download
| # Copy and build code. COPY main.go .
| RUN go build -o output/example main.go SAVE
| ARTIFACT output/example AS LOCAL local-output/go-example
|
| They copy in go.mod and go.sum and then run `go mod
| download`. If the mod and sum files haven't changed, then
| `go mod download` doesn't need to be run.
|
| Then they copy `main.go` in, and run `go build`. If the
| `main.go` file hasn't changed, `go build` doesn't need to
| be run.
|
| [0] https://docs.earthly.dev/basics/part-3-adding-
| dependencies-w...
| theamk wrote:
| sure, but in a java project, how likely you are to have a
| commit with no changes to src/? or for a go project, how
| likely is it that you want to duplicate you entire
| dependency tree in a clunky, non-parallel dependency
| description language, vs just doing "COPY * .; RUN go
| build" and letting golang figure it all out and build in
| parallel using all the cores?
|
| Don't get me wrong, there is definitely value in caching
| dependencies, and I can see Earthly approach help if you
| have, say, a Python app, with 10 minutes of dependency
| install time, 0 build time, and 10 seconds of tests -
| you'll see huge improvement. But you'll also see almost
| the same improvement if you use Dockerfile on a
| persistent host instead, and as a bonus you won't have to
| learn new system.
|
| One place Earthly might shine are monorepos with multiple
| independent projects that even use multiple build
| systems... but I am not sure how many of those exist
| _and_ don't have some other caching solution already.
| brabel wrote:
| Gradle can do the caching of tasks itself in a level of
| granularity no CI can. If you keep your build cache
| "live" in the CI, Gradle knows to only recompile what has
| changed, and to only run tests which changed (or tests
| something which changed). I am not sure if many other
| build systems do that, but this is something I would
| absolutely expect from the build system, not CI. Do you
| not expect caching when building locally??
|
| The whole idea with CI doing this is wrong IMO. All I
| want CI to do is call a couple of commands after setting
| up the environment (which would include the Gradle cache
| or whatever to speed up things - no need for your
| revolutionary CI build system).
| nvm0n2 wrote:
| A CI system like TeamCity will give you that sort of
| thing for free though, without needing an Earthfile. It
| just dedupes builds at the same commit, and keeps
| checkout directories between builds on the agents, so if
| the build tool has a cache then it's automatically
| reused. Works great.
|
| Given that it's hard to understand what exactly this is
| for? Build systems normally try to avoid redundant work
| for local purposes anyway. Is it some hack for companies
| that insist on resetting build environments to zero on
| every single build, and then decide they want caching
| back? If so, why not just ... let the builds take place
| in directories containing previous builds, and fix the
| problems? That's what we do at my company and it works
| great (using gradle), there are only rarely problems with
| unclean builds and it's easy to rerun with a clean
| checkout if that's suspected to be an issue (the bugs are
| mostly in our own code which does a layer of caching
| above the build system anyway).
| adamgordonbell wrote:
| Yes, exactly.
|
| Earthly is explicit about inputs ( using COPY) and outputs of
| each build step. This let's it be 100% certain about whether
| it can cache parts of the build.
|
| If you are familiar with docker layer-based caching and
| Bazel, you can imagine how Earthly works to eliminate rework
| in builds.
|
| Here is a small monorepo example:
| https://github.com/earthly/earthly-solutions
| [deleted]
| shuntress wrote:
| > Why pay both the CI vendor and us
|
| Exactly.
|
| _Complexity_ , not speed, is the problem with builds. It makes
| perfect sense that "another layer of complexity that wraps up all
| the other layers" was tough to sell.
| pshirshov wrote:
| In this particular domain, performance problems are tightly
| coupled with complexity.
| shepherdjerred wrote:
| I've used Earthly for a year and absolutely love it.
|
| It allows you to have two dependencies on the host system for any
| project -- just Docker and Earthly.
|
| I've used it to build cross-compilers, system software, web apps,
| my resume, school projects.
|
| The speed up is real. You can definitely get caching and
| parallelization and containizeration with other build systems,
| but Earthly's value is that it comes for free with a familiar
| syntax.
| 12_throw_away wrote:
| Ditto, it's been a huge success where I work. Keeping my
| fingers crossed that they find a way to stay in business :)
| dpeckett wrote:
| I feel like it's just a patience game of staying alive long
| enough that organic traction takes off. Earthly is bloody
| fantastic, the flexibility and expressiveness IMO is hard to
| beat.
| ilyt wrote:
| > Why not just simplify the stack? Why pay both the CI vendor and
| us, when you can just pay us?
|
| Coz the CI they "pay" for comes with rest of the stack, and is
| not just CI product. Both Gitlab and Github have far more than
| just CI
|
| >These weren't the raving fans we were used to talking with. New
| people would look at Earthly CI with a skeptical eye. They were
| mostly thinking that "all CIs are the same - they just have
| different syntax," and then they would not really look any
| further as to why we might actually be different.
|
| _we don 't care about CI_, we just need it and we need it to
| work.
|
| If we have working CI manifest for our app, the new app will have
| same manifest with few find-replace in it. The pain might be
| there to create it. And the example ones don't _really_ look any
| easier than doing same thing in Gitlab.
|
| Frankly, putting some transpiler that takes Gitlab or Github CI
| config and just makes Earthfile on the fly would probably
| convince some people to at least try.
| wesleyyue wrote:
| For anyone looking for fast ci, I'd highly recommend webapp.io.
| it automatically caches layers if it detects it doesn't need to
| be run, and you can split a VM to shard test execution. Runs way
| faster than GitHub actions, you can ssh into any layer to debug,
| and it's just like a Linux machine/dockerfiles so no crazy
| syntax/mental model to learn. Support is great and we've been
| super happy with the experience. Best CI platform I've used by
| far.
| shepherdjerred wrote:
| That's literally what Earthly does
| unbalancedevh wrote:
| It really bugs me when authors use acronyms or abbreviations
| without expanding what they mean. It tells the reader, "I didn't
| write this article for you, so don't bother trying to understand
| it."
| fydorm wrote:
| Which terms are you referring to? If you aren't familiar with
| "CI/CD", then this article really isn't for you, as you haven't
| run into the problems this startup is trying to solve.
| unbalancedevh wrote:
| Yes, CI/CD. It would be nice to know in the first paragraph
| that the article isn't for me, instead of having to read 1/3
| of the article and then infer it, or even keep guessing what
| it's about. Sometimes that's fine, but I seem to be seeing it
| more often, and it discourages people new to the field or who
| are still exploring.
| bastardoperator wrote:
| It failed because the marketing is outright bunk and overly
| dishonest.
|
| If I compile with Jenkins, Actions or Earthly, that compile time
| is going to be the same under each build system assuming the same
| build node. Claiming you're 20x faster when CI is firing within
| seconds is kind of meaningless. Caching and parallel execution
| are age old concepts when it comes to CI and every modern build
| system can do it.
|
| CI is all about feedback, I didn't see much here in terms of
| collaboration and bubbling data up, I didn't look very hard, but
| this should be frontline and center. Lastly, I'm not interested
| in adopting a DSL for my builds ever again, sorry.
| shepherdjerred wrote:
| > Caching and parallel execution are age old concepts when it
| comes to CI and every modern build system can do it.
|
| It is much harder to set up caching/parallelization with GitHub
| Actions, Jenkins, Docker, and Make than it is with just Earthly
| Klugistiono wrote:
| Most paralization is a junit configuration or parallel jobs.
| Which is super easy in Github Actions.
| bastardoperator wrote:
| In your opinion, regardless I have to set those systems up
| anyways to use the Earthly system. Jenkins caches by default
| and has parallel(), actions uses actions/cache, actions is
| also async so it's parallel by default. Both can use docker
| and take advantage of dockers caching management and make is
| a great tool, but again, any build system can use make.
|
| I don't think it's harder at all, in fact in my mind Earthly
| is more money, more steps, more time and energy, and more
| vendor lock in for the same output you can get in just about
| any modern build system.
| rewmie wrote:
| > It is much harder to set up caching/parallelization with
| GitHub Actions, Jenkins, Docker, and Make than it is with
| just Earthly
|
| I never used Earthly but I have to call nonsense on this
| take.
|
| Caching and parallelization is a solved problem in GitLab,
| GitHub, CircleCI, etc. It's so trivial that it's pipelines
| 101.
|
| Caching and parallelization might be easier in Earthly but
| any improvement over "trivial" is something not worth wasting
| time over.
| shepherdjerred wrote:
| How do you usually do caching for complex, multi-language
| projects in this case? How do you guarantee _only_ changed
| targets are rebuilt when dependencies, like a language
| version or external library, change?
|
| With Earthly you just... write your Earthfile. You get
| everything for free. Caching and parallelization _also_
| works locally, so I see that speedup in development.
| howinteresting wrote:
| I think there is certainly some value to that (the other
| posts don't appear to be fully grasping the complexity of
| the problem), but Earthly feels closer to an open source
| consultancy project than venture capital funded startup.
| code_biologist wrote:
| This unanswered Github Actions community request for
| parallel steps support drives me up the wall: https://githu
| b.com/orgs/community/discussions/14484?sort=top
|
| It can be papered over, but intelligibility by more junior
| engineers is one of the reasons I'd opt for GHA over
| something like Jenkins.
| verdverm wrote:
| That caching is not earthly, it's buildkit
|
| Earthly is just a skin and a hosted service as I understand
| it
| shepherdjerred wrote:
| Yes, you're right.
| ravivyas wrote:
| Can you expand on the word "feedback"? What kind of feedback
| are you looking from CI?
| bastardoperator wrote:
| 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?
| MatthiasPortzel wrote:
| From the post:
|
| > Earthly gives you write once, run anywhere build
| consistency, making it super easy to reproduce CI failures
| on your local computer.
| marcinzm wrote:
| That doesn't help with non-deterministic failures and
| I've also yet to see a true "write once, run anywhere"
| system ever. It may be 99% "write once, run anywhere" but
| there's always that 1% edge case.
| bastardoperator wrote:
| Exactly. This just reminds me of "works on my computer".
| Building locally is more advantageous for developing CI
| workflow, but I want to be as close to prod as possible
| and doing that on snowflake developer workstations is an
| exercise in futility.
| hedora wrote:
| Also, which of my 1,000 test suites are flaky, and when did
| they start being flaky?
|
| Flamebox almost got this right, but groups by wall-clock
| instead of git sha:
|
| https://flamebox.sourceforge.net
|
| The screenshot is most of what there is to see. Clicking a
| test run opens the test log.
|
| Does anyone know of a currently-maintained alternative with
| a less-bad dashboard?
| Phelinofist wrote:
| That looks really cool, thanks for the link. Something
| like this well integrated into Jenkins would be super
| useful.
|
| Our DevOps team build something custom: they check all
| test logs of all builds of all branches and aggregate all
| that into a Grafana dashboard. We use it to monitor tests
| that are failing, to get a better grip on flakiness.
| Works okay but could be better.
| trumbitta2 wrote:
| Stopped at "Imagine you live in a world where no part of the
| build has to repeat unless the changes actually impacted it."
| because I'm already in that world by using Nx and Nx Cloud.
| falcor84 wrote:
| I've never heard of Nx before, but what you describe sounds
| like nix, and I'm confused by the name similarity, as based on
| their site there appears to be no relation.
| habitue wrote:
| Nx came from the angular ecosystem, where "ng" is short for
| "angular". So there's no relation to nix, it's just
| coincidence
|
| (I use Nx at work and nix at home, and both are great in
| their respective domains.)
| marcosdumay wrote:
| I am still convinced the author was trying to describe Make.
| shepherdjerred wrote:
| It's similar to Make, in that you're explicitly defining
| dependencies and that allows caching/parallelization, but
| much simpler to use, and each target can define its own
| dependencies (e.g. some target might need Go or NodeJS)
| no_wizard wrote:
| 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 development is really slow going, they really need to
| focus up on Rush plugins (they're good, but still experimental,
| and I'd love to see them clean up how `autoinstalls` work to be
| more intutive)
|
| I'm on the fence about turbo from Vercel
|
| [0]: https://github.com/google/wireit
|
| [1]: https://rushjs.io/
| jangoforhire wrote:
| Curious about your thoughts on turbo?
| no_wizard wrote:
| From my usages with it:
|
| 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...
| kunalgupta wrote:
| Swapping single words in my pitches has taught me a lot about
| what people want
| 0xbadcafebee wrote:
| There is no real business advantage or value add to switching
| CI/CD systems. The only people that do it no longer have anyone
| working for them that knows how the existing CI/CD system works,
| so the new person just replaces it with something else. They're
| all basically the same crap. Run a job, evaluate its output,
| maybe run another job, send a notification.
|
| Whenever you run into a problem with a CI/CD system, it's because
| the system is "opinionated" and "tightly integrated", but of
| course lacks some obscure and subtle capability that you need to
| solve a problem. The fact that you are using _a specific CI /CD
| system_ is what dooms you to eventually need another one to solve
| the problem that you current one _cannot_ solve.
|
| It's ridiculous that here we are in 2023 and nobody has completed
| an open source project that replaces general use CI & CD (for
| modern best practices & use cases; Jenkins is a curse from the
| pit of hell). Both CI & CD are just loops of jobs and logic that
| then decides what next job to run. What those jobs do are all
| different, but so what? Make an open source library of jobs and
| logic.
|
| (for what it's worth, Drone.io is the best system I've ever used,
| and WoodpeckerCI is the open source equivalent, but it doesn't
| have a large community so work is very slow)
| oooyay wrote:
| Is the concept that requiring a demo for developer tools is a
| negative signal that strange?
|
| CI is also notoriously expensive to migrate, which the author
| alluded to. The pumpkin spice latte of software engineering is
| disdain for things like Jira and Jenkins but what keeps them in
| their seat is all the custom integration work that has to be
| done.
| a1o wrote:
| The thing with Jenkins is you can also make it custom enough so
| you have different teams handling different parts (say the
| building and the deployment, or the releases). In most CIs this
| is a bit harder to do - I think the Azure Classic pipeline also
| had interesting ways to delegate responsibilities. In the end
| the good thing of the different CIs is they apply to different
| problems and one can use them all at different parts of a
| company - teams that work in more innovative developments vs
| teams that maintain products that have to be trusted and adhere
| to many regulations.
| chubot wrote:
| It was honestly a bit hard for me to understand what happened
| from this write-up. I read it a few times, and the terms are
| still bit confusing. Seems like there are at least two separate
| issues
|
| - migration of the CI configuration -- from existing CI YAML
| (github/gitlab) to Earthly (Makefile/Dockerfile hybrid)
|
| - migration of the job runners -- from existing CI to a service
| hosted by Earthly
|
| I would have thought the first thing is the hard thing. Changing
| the language could take months or even years.
|
| But I don't understand what the blog post was saying. I thought
| they validated that part? People were able to switch?
|
| But then it wasn't validated at the end? The customers were faced
| with 2 migrations, not 1?
|
| But now what's happening? You're still keeping the Earthly syntax
| but abandoning the CI? Isn't that the hard part to migrate to?
| I'm still confused.
| wpietri wrote:
| I'm glad it wasn't just me. I'm interested in both sides of
| this, the product development side and the dev tools side. But
| with all that somewhat confusing prose, I ended up in the
| neighborhood of: "I'm happy for u tho. Or sorry that happened."
|
| Was the heart of this that they assumed that radically faster
| builds was the killer feature, but they hadn't actually
| validated that assumption before building it? Or was it more
| they hadn't really segmented their users, so they hadn't
| realized that the high-dollar customers had different needs? Or
| that they just gave away the thing that was the real-problem
| solver for paying customers?
|
| And given that the somewhat chaotic article was written by the
| CEO, I have to wonder to what extent the chaos was just a lack
| of editing versus there being a lot of actual chaos in the
| company throughout the process. Long ago Steve Blank wrote an
| article called "Founders and dysfunctional families" [1] where
| he talked about how a lot of founders are really good at
| managing chaos because they grew up in it, something that
| certainly describes me. He added that something that can make
| the difference between success and failure is the extent to
| which founders can also handle non-chaos. Because the ones who
| can't tend to "throw organizational hand grenades into their
| own companies" to get things back to the level of chaos that
| they're good at. That observation has given me pause for
| thought many times in the years since.
|
| [1] https://steveblank.com/2009/05/18/founders-and-
| dysfunctional...
| Terretta wrote:
| It's not about migrating the syntax.
|
| It's that people's CI over time become some kind of amalgamated
| model encapsulating how a firm makes every individual piece of
| software it makes and lands it places, think (ab)using a CI as
| Airflow (arbitrary automation job runner), and that the
| migration is first reverse engineering what people used to
| know, before even starting untangling all of that to express it
| some different way.
|
| Nobody really wants to stop the world and sort that.
| danudey wrote:
| I started work in December at an awesome company as a
| build/release engineer. Our current release workflow for our
| open-source components:
|
| 1. Run the CI build/test pipeline 2. If it passes, run the
| 'Publish' promotion (manually, on any pipeline you want) 3.
| The pipeline runs a make target 4. The make target starts up
| a VM (from the VM it's running on) 5. The make target SSH'es
| to the VM to run a make target 4. The make target builds a
| binary 5. The binary runs more make targets 6. The make
| targets run various scripts in docker containers on the VM
| the other VM started 7. The scripts in the docker containers
| build the components 8. The binary from step five runs more
| make targets to publish the releases 9. We test everything
| with another promotion which runs make targets which build
| docker containers to run python scripts (pytest)
|
| This is also built by a complicated web of wildcarded
| makefile targets, which need to be interoperable and support
| a few if/else cases for specific components.
|
| My plan is to migrate all of this to something simpler and
| more straightforward, or at least more maintainable, which is
| honestly probably going to turn into taskfile[0] instead of
| makefiles, and then simple python scripts for the glue that
| ties everything together or does more complex logic.
|
| My hope is that it can be more straightforward and easier to
| maintain, with more component-ized logic, but realistically
| every step in that labyrinthine build process (and that's
| just the open-source version!) came from a decision made by a
| very talented team of engineers who know far more about the
| process and the product than I do. At this point I'm
| wondering if it would make 'more sense' to replace it with a
| giant python script of some kind and get access to all the
| logic we need all at once (it would not).
|
| [0] https://taskfile.dev/
| hedora wrote:
| Taskfile looks worse than make to me in every possible
| dimension (except maybe windows compatibility, but I don't
| believe that it meaningfully supports that).
|
| You should at least read and understand the paper
| "Recursive Make Considered Harmful" before attempting to
| replace make with something "better":
|
| https://aegis.sourceforge.net/auug97.pdf
|
| Most people use make incorrectly (and it sounds like the
| system you describe makes most of the classic mistakes).
| The paper I linked explains how to use Make's templating
| language to help it scale to complicated setups.
|
| Here are a few critiques of taskfile (from skimming their
| documentation):
|
| - The syntax is incredibly verbose and weird. For instance,
| you have to write a tree of yaml nodes to loop over a set
| of files. Make's syntax is weird, but at least it is not
| verbose.
|
| - The documentation makes no mention that I could find of
| deriving a set of tasks from a list of files (Make's
| $(wildcard) macro, or stemming rules like "%.o : %.c"). So,
| I guess the taskfile will end up being huge (like the size
| of autogenerated makefiles from autoconf or cmake), or
| you'll end up using additional ad-hoc build systems that
| are invoked by your taskfile.
|
| - From the documentation, they haven't thought through
| having more than one project per unix account "When running
| your global Taskfile with -g, tasks will run on $HOME by
| default, and not on your working directory!"
|
| - They seem to have partially reimplemented the bad ideas
| from recursive make: https://taskfile.dev/usage/#including-
| other-taskfiles
|
| - I suggest taking an idiomatic but non-trivial bash script
| (which is 99% of what make is invoking, and that taskfiles
| support), and then trying to port it to python directly.
| There's usually a 10-100x line of code blowup from doing
| that, and the python thing usually bitrots every year or so
| (vs. every few decades for shell).
| 392 wrote:
| Try buck2
| pimlottc wrote:
| HN collapses lists, you might want to add some newlines
| between the steps for better readability.
| aftbit wrote:
| I think the key is that nobody "wants" to spend any time at
| all on CI or their build system. It is one of those necessary
| evils that you have to do to have functioning software. Once
| you do it, even if it's a slow buggy pile of hacks, you will
| just ignore it until the pain gets very very bad.
|
| This was the same problem that caused our team to abandon
| CircleCI. They kept wanting us to rewrite our CI configs,
| touting various benefits that we just didn't care about. All
| we wanted was for our janky broken builds to keep working 90%
| of the time, like they did before Circle tried migrating this
| or that.
| larusso wrote:
| I had a talk with a circle CI rep at a conference and I
| tried to explain to him that yes I'm not happy with our
| custom Jenkins setup (agents, CasC, pipeline library), but
| that I also want to spend time and money on a migration
| project to end up at the status co again. If I would go to
| my boss and say we can either spend some time and fix our
| setup or spend time plus running costs for this external
| solution then the answer will be clear. I think convincing
| teams with huge stacks of CI setup to just switch because
| of marketing promises isn't working. I would think of using
| a new setup when I start from scratch. At the moment at
| least.
| wpietri wrote:
| Some people do want to spend time on that! It depends
| whether you see fast feedback as a competitive advantage.
|
| I once worked on a system where we had excellent test
| coverage and all our unit tests ran in under a minute. We
| worked hard to keep it that way, because it was a huge boon
| to productivity, especially when improving design issues.
| It also enabled frequent commits and merges, which made
| collaboration easier. It was a great experience.
|
| But yes, from the business perspective, the leading edge is
| a pretty small audience. (Circa 15%, per Moore.) And the
| bottom half of the audience by competence, which Moore
| called the Late Majority and the Laggards, can be well more
| than half your revenue in a SaaS context because they will
| create problems for themselves (like slow/buggy builds)
| that mean higher per-user revenue. And they may also have
| special feature needs where they'll pay more rather than
| clean up their messes.
|
| In that context, doing the right thing for your business
| can be very different than doing the right thing for users.
| Sort of like a physical therapist who makes most of their
| money from renting crutches and in-home meal delivery, and
| so doesn't push people to actually get better.
| notatoad wrote:
| >I think the key is that nobody "wants" to spend any time
| at all on CI or their build system.
|
| or if they do, they're hosting their own.
|
| if you're selling a hosted CI platform, your sales pitch is
| "pay us $$ instead of paying your staff $$$ to do devops".
| if your pitch is "pay us $$ and then also spend $$$ on
| staff hours to manage our service", it's very unlikely the
| CI is doing anything useful enough that the staff couldn't
| just run their own thing in-house.
|
| it doesn't take much configuration to be more difficult
| than an EC2 instance running a script on a webhook from
| your version control.
| aeyes wrote:
| What did they make you change?
|
| I have been using CircleCI since the beginning and the only
| breaking change I saw was when they introduced workflows.
| This didn't need any changes to the difficult parts of my
| own code and was mostly copy-paste.
|
| I believe that my configs are fairly complex using almost
| all existing features across many different projects and
| build targets.
| chubot wrote:
| OK but my point is that should have been apparent at the step
| 1 validation.
|
| Seems like they are onto step 2 or 3, and figured out that
| step 1 wasn't actually validated -- people didn't want to
| migrate to Earthly files ???
|
| The blog post is not clear about what happened
| Spivak wrote:
| The space was destined to collapse these two products not
| because it makes sense conceptually but because their
| implementations are almost identical and maintaining fewer
| systems is great. One was always going to eat the other and
| CI systems are turnkey, hosted, and live close to the code
| that it will be running.
|
| I wish they had either remained separate or gone the other
| way but it's not worth swimming upstream for it.
| adamgordonbell wrote:
| "People will buy a developer tool, but you can't sell it."
| nathanfig wrote:
| I think HN will eat this up because few of us enjoy being sold
| to but like most absolute statements it's probably only
| applicable in specific circumstances. Enterprises sell tons of
| developer tools and move millions because of demos done well.
| AWS and Azure are definitely getting on planes and doing demos.
| wrs wrote:
| For me the killer quote was "if the prospect requires a demo,
| then they're not worth going after" -- because as a prospect,
| if your product requires a demo, I'm already halfway to no. I
| am so tired of "enterprise" products that have to be purchased
| as a pig in a poke because they can't stand on their own during
| a trial period.
| deepspace wrote:
| That line caught my attention too, and it looked superficially
| true. I have certainly never purchased a tool based on a phone
| call from a vendor. However, that only pertains to cold-
| calling, which is the absolute worst way to sell _anything_.
|
| Advertising is a trillion dollar market for a reason - it
| works. The trick is to find the correct message and media for
| the audience.
|
| Effective advertising takes a lot of skill, a lot of money, or
| both. A large portion of HN posts (including this one) are
| contain "hidden" advertising, and they absolutely work.
|
| I have purchased more than one developer tool based on reddit
| and HN reviews, which originated as posts by the seller. On the
| "lot of money" side, a poster in the arrivals tunnel at SFO is
| an excellent way of raising brand awareness; even for developer
| tools.
| hardwaregeek wrote:
| At least for me, whenever I have to set up CI or touch CI, it's
| incredibly painful. I usually end up having to push a bunch of
| commits to debug stuff, and there's a lot of configuration hell.
| I don't know if Earthly solves this, perhaps it does. But if I
| were considering moving onto a new CI, I'd immediately think
| about having to redo this painful process. And that's at the team
| level. At the org level, switching CI would be even worse.
|
| That does make me wonder, how much of CI adoption is actually
| moving from one provider to another versus new projects adopting
| CI for the first time? I'd guess that barring a really extreme
| reason, most projects pick a CI provider and stick with it.
| mrweasel wrote:
| CI systems are important to me, but my requirement is pretty
| much: Can it run a bash script. Every CI I've ever used has
| degraded into a bash script runner. It starts out well enough,
| you try to use all the build in features but at some point you
| fallback to running a shells script and then slowly more and
| more move to the script, because it's easier.
|
| Someone should just build a bash CI, something that can manage
| secrets and then run one or more shells scripts.
| kerblang wrote:
| Once you have hooks into source control for commit-based
| callbacks into CI, everything else need only be shell. Like,
| if you build a triggers-shell-scripts-off-source-repo-hooks
| web service, does putting the results in a pretty web server
| really matter for anyone besides executives who want
| dashboards dashboards dashboards? I'm already sending script
| output to text files and our chat system via curl to boring
| web service APIs.
| [deleted]
| dpeckett wrote:
| In a lot of ways that's pretty much what Earthly is, except
| those bash scripts run inside containers (that you can
| configure inside Earthly itself) and you pass files/artifacts
| between steps/containers.
| angio wrote:
| Buildkite encourages that, even plugins are just a bunch of
| bash scripts that are sourced at specific steps of the build.
| davinci123 wrote:
| I think the biggest moral of the story - don't build a product
| without considering the switching/adoption cost. Higher the
| switching/adoption cost, lower the product/market fit.
|
| I have heard this story again and again from so many startups who
| have built products which provide incremental benefits (1.3x
| cheaper or 1.5x faster) and not getting enough traction.
| jatins wrote:
| > We ended up with the most ridiculous negative qualification
| criteria I have ever heard of: if the prospect requires a demo,
| then they're not worth going after
|
| Based on my experience at enterprise companies, this is _all_
| enterprise sales. So sounds very counter intuitive to me.
| plg wrote:
| Dumb question I guess, what is a CI???
| gabereiser wrote:
| This is a good write up of why you shouldn't give away the house
| when you open source things. The issue was really this: _Earthly
| being open-source, Earthy Satellite users were already seeing the
| benefit from 95% of Earthly CI_.
|
| I'm a huge fan of open source, however, if your business model
| includes an open source model - you need a differentiator. Beyond
| blazingly fast(tm). You need a reason for people to offer up
| their credit cards, or better, their accounting PO process. You
| need a feature you withhold or a service you provide from the
| open source offering to make it appealing.
|
| GitLab restricts CI/CD to paying customers. Travis/CircleCI limit
| on build time/credits unless also open source. Azure DevOps is
| the devil. ArgoCD is complicated. GitHub actions are nice if you
| have hardware to run the runners. Swarm's of Jenkins is what most
| are used to in the enterprise.
|
| As a former Director of DevOps, my immediate question will be
| what features make me want to buy vs host myself. I'm technically
| capable. Why should I buy with you when I can run my cloud and my
| DevOps pipelines for my workforce the way that makes the most
| sense for my business? Help me make the most sense.
|
| *EDIT* I'm not suggesting withholding features that are critical
| for the software to operate, but withholding business features
| that provide support or enterprise-level integration. Even making
| it tiered so the power users pay less because they support it
| more themselves?
| ilyt wrote:
| From my experience hosting our own instance of Gitlab + few
| CI/CD workers was few weeks of initial work (integrating with
| company's LDAP etc.) then around one ops-week per year worth of
| maintenance over last few years (50+ developers, dozens and
| dozens of projects).
|
| Before that we had just "a git server + jenkins + some slaves"
| that took even less maintenance (althought I'd imagine more
| fumbling on dev side with job config)
|
| Earthly isn't cheaper than any of those options and none of our
| clients use it (and we occasionally have to work on client's
| gitlab instances).
| gabereiser wrote:
| You just described a great starting point for a small shop, I
| would recommend this route 100%.
|
| Initially your CI/CD needs to be close to the code. It needs
| to be close to developers. Not a DevOps department. It needs
| to be almost forgettable. Include a config in your repo, bam,
| welcome to the pipeline.
|
| Where this breaks down is when you don't have LDAP, you have
| Azure IDP + Amazon's Cognito + Keycloak 3rd Parties + SAML
| (barf) + Form Login for contractors + JWT/OAuth for services.
|
| This is the inflection point where you need DevSecOps +
| Architecture + Cloud Engineers to ensure everyone's playing
| nicely. Enjoy your pods. Let us know when you need that VPN
| tunnel to your customers backend because they don't trust
| SSL.
| maccard wrote:
| We use buildkite but if I was starting fresh now I would just
| use github with github actions.
| isoprophlex wrote:
| > Azure DevOps is the devil.
|
| Amen to that!
| shandor wrote:
| 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.
| datadrivenangel wrote:
| 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.
| shandor wrote:
| 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-minded if need be.
| WorldMaker wrote:
| AzDO Pipelines was directly the first draft of what
| became GitHub Actions, so technically it does have a lot
| to recommend it, especially if you learn the Multi-Stage
| YAML approach which does sort of directly feed into
| GitHub Actions for the eventual day you decide to
| migrate.
| datadrivenangel wrote:
| Yeah, the Pipelines are okay all things considered.
| WorldMaker wrote:
| AzDO is "decent", depending on your needs, but it's in an
| unfortunate zombie state where Microsoft is supporting it
| _just enough_ to keep it stable and keep certain
| enterprises happy and consistently insisting that AzDO has
| a roadmap and is still beloved, but it is _very clear_ that
| all of the actual resources are going to the GitHub side of
| the house in 2023.
|
| (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.
| hotnfresh wrote:
| Ugh, they're busy bringing bad project management to
| GitHub, in a quest to make it suck as much as all the
| others.
|
| The old issues + tags + milestones was perfect. Now it's
| the same needlessly-heavy thing as all the rest, with
| their reimagined "projects" thingy.
|
| But then again I've not once seen a PM embrace any
| version of GitHub's project management, with the only
| explanation forthcoming being "it's confusing for non-
| technical users" (fucking how? More confusing than Jira
| or Asana? No friggin' way) so maybe they have to shit it
| up and make it hard to use and easy to get lost in or
| miss info in, to get any traction with PMs.
| WorldMaker wrote:
| It does seem a case where Microsoft dogfooding GitHub may
| be actively making it worse. They've done several BUILD
| and GitHub Universe videos "How Microsoft Uses GitHub to
| Build [X]" and their PMs certainly need all those complex
| features to track stuff and those videos are the closest
| to training materials on how to use some of it, and it is
| definitely _a lot_ going on.
|
| It definitely seems one of those sorts of "every system
| PMs touch is doomed to become unmanageable complexity"
| laws and GitHub "Projects" does seem to be exponentially
| closer to being "Jira 2: Electric Boogaloo" every day.
| gabereiser wrote:
| This. AzDO will die. It will be replaced entirely by
| Github. It originally was only designed as a way to get
| people onto Azure using their already-existing MS
| partnership to give it away for free. The only purpose,
| drive adoption of Azure Cloud. In runners, resources,
| stickiness, and preventing abandoning ship.
| rhaway84773 wrote:
| Azure Devops existed well before GitHub was owned by MS
| under Visual Studio Online moniker.
|
| It was intended to be a SAAS version of the on Prem
| offerings MS has provided since before GitHub even
| existed.
| sanderjd wrote:
| I know this is controversial, but I wish commercial "source
| available" were the more mainstream / not-shat-upon approach to
| services, rather than "open core".
|
| I find it very frustrating to not be able to read the code or
| contribute bug fixes or self-host anything outside the "open
| core", and I have no need for any of the things that
| distinguish "open source" licenses from "source available"
| ones.
| dpeckett wrote:
| Stallman was right. I think it's inevitable we'll see the
| next generation of developer focused tooling go in the
| direction of AGPL or source available (eg. BSL). Ironically
| enough Earthly started off as BSL.
| sanderjd wrote:
| What did Stallman say about this?
| maratc wrote:
| > Swarm's of Jenkins is what most are used to in the
| enterprise.
|
| Thanks, I thought we were one of the last places with that
| setup, nice to know this unholy contraption is actually
| somewhat standard.
| jangxx wrote:
| You can self-host Gitlab CI runners and use them even in the
| free community version.
| gabereiser wrote:
| I know, this is what I've been doing for years. ( _edit_ on
| GitHub, not GitLab, didn't know GitLab allowed community CI
| now)
| prometheon1 wrote:
| I thought using your own runners for free in Gitlab was
| already an option before Github Actions even existed
| gabereiser wrote:
| When it was an open source project, yes. You are correct.
| Ever since GitLab went commercial, it's been behind a
| paywall. Apparently you can run runners on self-managed
| CE so I'm going to look into that.
| mindwok wrote:
| GitLab is still an open source project (the core of it is
| MIT licensed) and using your own runners has always been
| an option. Also, free accounts on the SaaS version get
| free CI/CD minutes as well.
| smashed wrote:
| On Gitlab.com you need to input a valid credit card once
| in order to validate your account, but you can still get
| 400 minutes on shared runners for free.
|
| This is used to combat abuse and crypto miners, they
| don't actually charge the card.
|
| You can also connect your own private runner to either
| the saas or self-hosted gitlab-ce for free, you just have
| to provide your own runner.
| nivenhuh wrote:
| I run a self-managed CE GitLab with my own runners --
| works as expected (no payment required).
| bottled_poe wrote:
| Same, been doing this for many years and upgrade
| frequently.
| jangxx wrote:
| Then I guess I misunderstood "GitLab restricts CI/CD to
| paying customers"?
| gabereiser wrote:
| Sorry, I misread your comment as GitHub, not GitLab. I
| was unaware you can run CI runners on GitLab community
| version.
| Spivak wrote:
| And honestly I can't even imagine ever using the public
| runners because they're permissionless. It's way easier to
| have them live in your own network and doling out permissions
| via tags that get picked up by different runners with
| different iam roles.
| chrisweekly wrote:
| (mods: please forgive the off-topic personal question here)
|
| Hi Spivak, You're not Lee Spivak (formerly of Upromise in
| the early 2000's), are you?
| gabereiser wrote:
| This is why some people don't leave the house.
| AaronM wrote:
| Did you mean argowf instead of argocd? Argocd is pretty simple
| and only syncs k8 resources.
| gabereiser wrote:
| I mean that node (not js) dashboard to build pipelines and
| make things look logical instead of writing 4 lines of bash.
| I'm not a fan of anything that adds complexity. ArgoCD/WF/ALL
| ARGO... is just a pretty dashboard over cli tooling.
| ./deploy.sh <repo>@<version> <pod-name>
|
| This is the contract you should focus on. Whatever you need
| to make ./deploy.sh do this, do it.
| Klugistiono wrote:
| Have you ever used ArgoCD?
|
| No one EVER should run deploy.sh like how you propose it.
|
| ArgoCD abstracts away access to a k8s cluster (login
| through dex).
|
| It has strategies of how to deploy k8s resources like
| through retry, replace (which you would need to write
| manually in your deploy.sh).
|
| It gives you debug output for your deploy process (yes
| thats a thing, you do not assume every deploy just works).
|
| ArgoCD also can and should be used to reference secerts
| from secret store like vault.
|
| And it gives you a history/audit.
| withinboredom wrote:
| And fuck-us-all if you go on vacation.
|
| In a small business (read: startup), `deploy.sh` is all
| you should have. When you go on vacation and it breaks, I
| just need to read a bit of bash/python/php/whatever-
| script-you-use.lang and fix the broken stuff.
| psYchotic wrote:
| Isn't ArgoCD more of a GitOps tool? The pretty UI is mostly
| secondary to its main purpose for me, which is to keep the
| declarative "truth" in source control, and have ArgoCD be
| the control loop that keeps the cluster in sync with that
| truth. Accidentally nuked namespace? No worries, ArgoCD's
| (or whatever alternative, like flux) got your back!
| rrrix1 wrote:
| Exactly this. The critical difference being who deploys
| and when/how your resources are deployed - a human, or a
| machine.
|
| Having git be the source of truth of your production
| environment is a blessing and a curse which is directly
| related to the maturity of the deployment system.
|
| If you have low confidence in your deployments (as in,
| you don't deploy very often and don't have full e2e tests
| & monitoring), GitOps is nightmarishly scary compared to
| classic, battle tested Ops team CLI scripts.
| hhh wrote:
| I feel almost certain someone could wrap ArgoCD into a product
| if they handled the 'patternization' of applicationsets. D2iQ
| already do it with Flux, but we bailed on D2iQ before we even
| got to try it.
| gabereiser wrote:
| ArgoCD is almost worthless if your DevOps teams are IaC
| wielders. Honestly, just a bash script to push a container to
| the pods is all that's required for DevOps deployment. A
| build pipeline should be _get artifacts_ - > _put artifacts
| in container_ - > _push container to registry_ - > _trigger a
| pull on your pods_. If you didn't have a standard cloud
| architecture, I can understand the frustration and reasoning
| behind looking at ArgoCD. If you have a standardized cloud
| practice, it's moot.
| hhh wrote:
| My needs are more 1 application, 150 configurations, 150
| clusters.
| dpeckett wrote:
| I'm not sure feature withholding has traditionally worked out
| well in the developer space. The churn rate for tooling is so
| high that if Earthly were to intentionally cripple their
| product I'm sure the majority of developers would just move on
| to other inferior, but free, options (eg. taskfile). Maybe
| those that remain could be converted successfully but it's
| quite a gamble.
|
| A great turn around story in recent times though is probably
| Docker. But that required them to abandon strict open source
| and make controversial license/product changes.
| BlackjackCF wrote:
| I think a nice compromise is the CircleCI/Travis model of
| providing limited build credits/hours. If you're a small shop
| or single dev, you can use the core product for free, with
| the hope that you'd convert to a paying user if your business
| grows past the free constraint.
| imiric wrote:
| For the open core model to work, the OSS product should be
| standalone and featureful. If users feel like it's just used
| to advertise a commercial product, it doesn't work. And the
| commercial product should offer value-added services and
| features that are not strictly required for the base OSS
| product. These should be features directed towards advanced
| or corporate users, and preferably something that competitors
| lack, or don't do a good job of.
|
| It's very tricky to balance the open core model correctly,
| which is why not many companies get it right. You need to
| invest equally, if not more, in the OSS product, and make
| sure users are happy with it before you even mention a
| commercial addon. Grafana is another example of companies
| that understand and do this well.
| tazjin wrote:
| In this particular case, developers could also move on to a
| _superior_ and completely open alternative (Nix), so making
| even a semi-closed alternative with much fewer people
| contributing etc. was already a hard sell.
| JustLurking2022 wrote:
| Seriously, is there an email distro or something to notify
| Nix users when there's a new post to go troll? It's not
| suitable for 90%+ of users, which seems a far cry from
| superior.
| tazjin wrote:
| It's just very noticeable when half of what the industry
| seems to spend its time on is solved problems. You and
| all the others have to learn why touching the hot stove
| is a bad idea the same way most children do. It's
| frustrating to observe.
|
| It's fine to criticise Nix for its various flaws, but any
| suggestion of an "alternative" that has learned nothing
| from it is just a collective waste of time.
| caseyohara wrote:
| > I'm not sure feature withholding has traditionally worked
| out well in the developer space.
|
| I think it's worked out well for Sidekiq
| (https://sidekiq.org). I really like their model of layering
| valuable features between the OSS / Pro / Enterprise
| licenses.
|
| The trick is you have to do that very early on. Nerfing your
| open source offering by making some existing features paid-
| only is always going to get some backlash.
| hnlmorg wrote:
| > I'm not sure feature withholding has traditionally worked
| out well in the developer space.
|
| It's worked well for GitHub, Slack, and pretty much every
| service that only offer SSO behind enterprise subscriptions.
|
| The trick is to offer enough to make people productive but
| not so much that there isn't a worthwhile upgrade path.
| dpeckett wrote:
| True (for web apps and multiuser applications).
|
| Earthly is a single binary CLI on top of Docker buildkit so
| it's a bit trickier for them.
| gabereiser wrote:
| Yeah, not suggesting feature withholding per se, but a
| differentiator on why one would buy vs run the OSS build.
| staunton wrote:
| What's the difference?
| gabereiser wrote:
| plugins, hardware, hosting, support, there's a number of
| ways to offer a service for an open source project. Open
| Core models come to mind. Another is not having
| enterprise SSO as part of the core. Or not having
| clustering. Something that would make a VP think twice
| about adopting your open source solution vs using you as
| a vendor.
| justin_oaks wrote:
| I know these are examples, so I don't want to pick on you
| too much, but I have one nitpick: Reserving SSO for
| enterprise customers is awful. Please don't do it.
|
| See https://sso.tax/ for details but I'll quote this from
| it "SSO is a core security requirement for any company
| with more than five employees"
| BoorishBears wrote:
| As others are pointing out, once you've grown big enough
| that you can't trust everyone with the keys go the
| kingdom: enterprise pricing is for you.
|
| SSO Tax is a fun meme, but it misses the point: Whether
| it's 5 people or even 3, you've scaled your business
| enough to hire people who aren't in the inner circle.
|
| That's a fair place to consider you an enterprise.
| justin_oaks wrote:
| Not sure what you're talking about. It's not like without
| SSO everyone in the company has to all use the same
| password. Services allow people to have separate users
| with separate privileges.
| BoorishBears wrote:
| It sounds like you're unaware of why SSO is considered a
| security feature at all them, but it's covered right on
| the site: https://sso.tax/
|
| It's to allow centralized access management. Stuff like
| firing someone and revoking their access from one
| platform instantly, instead running around and changing
| permissions in every tool manually. Or ensuring people in
| department A can't be invited to some platform for people
| in department B in order to limit information access.
|
| SSO tax is predicated on the idea that the moment you
| outgrow the informal arrangements and liberal access,
| you're _really_ a business. Seems pretty fair?
| imiric wrote:
| If a company requires SSO, they'll surely have a budget
| for paying for the products and services they use. The
| majority of OSS users won't have this requirement, and
| likely won't have the budget to pay for commercial
| features. So it doesn't make sense to give away a service
| that has a maintenance cost to everyone, as long as it's
| fairly priced.
| gabereiser wrote:
| If you have more than 5 employees, I'm sending you a
| sales rep to sell SSO to you.
| justin_oaks wrote:
| I see, I see. The world isn't fair. We have 5 employees
| and we want SSO but don't need SSO. So we'll go without
| it. It's annoying for us but it allows your business to
| exist because enterprise needs SSO.
| debarshri wrote:
| Let me give a contrarian argument. I dont think it is
| awful to have sso reserved only for enterprise customers.
| I think enterprise customer who are going through
| compliance will definitely have to but into that tier
| therefore.
|
| If you think you need SSO and but you do not have the
| budget for upgrading to their enterprise tier, may be you
| are not the right customer that they are targeting to
| sell. It is not you, it is them.
| justin_oaks wrote:
| You're right. I was thinking from the position of the
| consumer for which SSO is both convenient and a security
| feature.
|
| I wasn't thinking as the service provider that needs a
| way to force the folks with the big bucks to pay up.
|
| It sucks for the little companies, but it may be
| necessary for the service to do so.
| rhaps0dy wrote:
| But it should be OK to reserve SSO for _paying_
| customers.
| caloique wrote:
| Co-founder of BoxyHQ here - We've crafted an open-source
| enterprise SSO because we firmly believe that robust
| security shouldn't be a privilege limited to large
| organizations. Ideally, essential enterprise-level
| features like this should become commonplace for all.
|
| While we acknowledge the reasons behind SSO being in the
| enterprise tier, we're all on a collective journey to
| enhance our security measures. Open Core models are
| indeed a good option (my preference), yet the dynamics
| vary across solutions and industries. It's up to each of
| us to explore, experiment, and discover what resonates
| with our market. In doing so, we can foster growth while
| maintaining our commitment to supporting the community in
| the long run.
| ljm wrote:
| The open source version has to be good and valuable enough
| for you to bring it in as a dependency in a basic setup, and
| then the paid versions provide support for larger scale
| setups where the requirements are a bit different.
|
| There are many ways to do that, depending on what you're
| offering. Limits and quotas are easy enough.
| paxcoder wrote:
| [dead]
| CodeL wrote:
| 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.
| mcnichol wrote:
| 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
| layers above with purchasing power. Giving (or showing) someone
| the solution and then taking it away is probably the most
| common reason I have seen someone leave a situation.
| CodeL wrote:
| Absolutely. It's often those who are in the trenches, dealing
| with the day-to-day challenges, who recognize the need for
| better tools. They craft solutions tailored to their specific
| needs, which often resonate with others facing similar
| challenges.
|
| 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.
| mcnichol wrote:
| Couldn't have said it better. I have loved each one of
| those tools too.
|
| Docker maybe a little more love-hate but I think that has a
| lot more to do with the politics and salesy side of things
| and "Who owns what"
| Klugistiono wrote:
| I'm quite passioned about CI/CD and working in this field for the
| last 7 years.
|
| I'm keeping a close eye on jenkins, tekton, circleci, travis,
| github actions, gitlab etc. and never ever heard about earthly.
|
| Btw. one thing the person doesn't get: Everyone wants to have
| fast and reliable builds but no one cares.
|
| No one.
|
| CI/CD Systems in a developers eye are blackboxes. They don't
| care.
|
| And its already a solved problem somehow. I was waiting for
| Jenkins X to happen (something like jenkins working nicely in a
| cloud native way because Jenkins Plugins!) but that didn't
| happen.
|
| What happend instead is Github Actions. Holy shit are Github
| Actions good. Srsly.
|
| GitLab stuff was slow and effort. GitHub Actions just do what
| they should do 99% of the time.
|
| If you do not have a huge build, you will not care about your
| CI/CD System and everyone who has real build issues, has to solve
| it by another strategy than just switching the build system.
| throwawaaarrgh wrote:
| GitHub Actions is the same as everything else. It doesn't work
| any better or worse. But the UI is clunkier, you can do _less_
| with it than other systems, it lacked important features
| forever (still does). The only reason you think it 's
| significantly better is psychological.
|
| The "market" of actions is better than competitors because the
| incumbent gets an advantage, and it trades on the idea of a
| generic executable as a 3rd party plugin, unlike other systems
| that try to force you into a particular language or paradigm.
| But other systems do this too.
| skinner927 wrote:
| > Write once, run anywhere
|
| Except virtual machines of course. Does everyone only build web
| apps?
|
| What tools do systems developers use? You can't reliably test
| system integration in a container.
| SkyPuncher wrote:
| Unless CI is _really_ painful, it's just not that painful. I
| spend a day cursing about my build when I spin up a new project,
| then I forget about it for months.
|
| Specs run fast enough - especially locally where I only run
| failing or known-modified specs.
| ajmurmann wrote:
| It very much depends on what you are building and testing. I
| work on a distributed database and while our build takes like a
| minute, the tests take hours and we run them on clusters we
| start on-demand. Getting our CI faster, has been a constant
| effort for years that quickly pays for itself.
| theptip wrote:
| This is a good write-up, and contains some well-reasoned PMF and
| product strategy evaluations; grokking the thought process here
| will help you to survive in your own startup.
| progx wrote:
| You get customer when you solve a real problem for them. CI-
| Systems exists, slow or fast doesn't be a problem for most of the
| devs, cause you run normally everything local and only on publish
| in a remote CI-system. So CI-Systems exists and solve their
| problem.
|
| I think only for a really small market the CI-performance is a
| real pain. Sure, everbody wants it fast, but that is not a reason
| to change a huge complex setup.
| goodpoint wrote:
| 5 minutes reading the website and I still don't know how it
| actually works.
|
| Marketing fluff and bits of Earthfile's ugly syntax.
| seanr88 wrote:
| I'm having a very similar issue getting https://brisktest.com/
| out there. People complain about things like the speed of their
| build system, but convincing people that your CI system is faster
| just seems like an uphill battle. Maybe the era of launching new
| indie dev tools to developers is over and you just need a massive
| marketing budget to bombard devs with advertising and lots of
| sponsored content.
| pharmakom wrote:
| The issue is trust. I dislike trusting GitHub / GitLab with my
| code but I already do, so I choose them for CI.
|
| I can already get fast builds using Bazel (or maybe Buck 2) so
| why do I need another tool / provider?
| shepherdjerred wrote:
| If Bazel works for you that's great, although it is still
| rather complex. For smaller projects Earthly is a better fit.
| maxloh wrote:
| GitLab is open sourced. You can self-host GitLab (and their CI
| solution) yourself.
| skybrian wrote:
| This article is confusing because the author is too close to the
| problem, and it needs to be explained from an outsider's point of
| view before diving into the details. But it looks like the
| information is there.
|
| It sounds to me like they ended up with an encapsulation layer
| between language-specific build systems and the continuous build
| systems that kick them off.
|
| A comparison might be with something like Bazel, which does
| everything, but full adoption requires going all-in on using
| their build language to replace language-specific build systems,
| often including moving source files to make it work. This feels
| foreign compared to using a language's own build system, but it
| might seem natural for C programmers, where the language doesn't
| have its own build system. Similarly, Java went through several
| unfortunate build systems before unfortunately settling on
| Gradle.
|
| Language-specific build systems end up not doing everything
| because each language has its own conventions and ecosystem.
| Modern ones don't try, they know what they're good at and stick
| to it.
|
| So, the tool that actually knows about multiple languages and
| their artifacts is often a shell script, makefile, docker file,
| or the continuous build itself. Or even doing it by hand. That's
| the layer they're trying to improve.
|
| I don't have a clear idea what their fundamental insight is that
| makes their way of doing it better, though.
| KETpXDDzR wrote:
| > 2-20X faster builds
|
| This appears several times over the whole article. What are you
| comparing to? Without any baseline, this phrase is worthless
| marketing gibberish.
| shepherdjerred wrote:
| Uncached, unparalleled builds running on other platforms.
| pxc wrote:
| I looked briefly at Earthly a while ago for work because I have
| to write CI integrations for a whole bunch of CI platforms
| (GitLab, Azure DevOps, Jenkins, and maybe GitHub Actions). I
| ended up going with a very similar product (i.e., another nice
| BuildKit frontend with integrations into a bunch of CI systems),
| Dagger, because the DSL it used for defining pipelines at the
| time seemed better to me. I ended up deeply regretting this
| decision, as the Dagger devs have de facto abandoned that
| language entirely in favor of churning out SDKs for the most
| popular programming languages-- all imperative, all Turing-
| complete, and all, imo, bad fits for the space. So now I'm back
| in hell, integrating with all of these systems by hand, hesitant
| to trust this kind of tooling to a startup again.
|
| To me this is still the most appealing use case of something like
| Earthly. Push-and-see-what-happens is still the norm on almost
| all CI systems, and it's an abominable workflow. If you are at a
| large organization and have to support teams that use a wide
| variety of CI/CD platforms, something like Earthly could
| potentially save quite a lot of pain. But the appeal is precisely
| _in_ supporting existing CI platforms, rather than in adding
| another one.
| verdverm wrote:
| CI/CD & provisioning are inherently order driven tasks, I
| actually prefer the SDKs over the CUE implementation. The main
| issue with the old CUE implementation is that they had to try
| and align BuildKits DAG solver with CUE's DAG solver, and they
| worked in opposite ways. I tried to help them through this
| about 3 years ago (being a CUE expert). I definitely think the
| SDKs is a much better solution for them. Whether we like it or
| not, a lot of the industry is moving this way. Pulumi is
| another example of this, though I'm sold on imperative cloud
| infra, builds do seem to have alignment here.
|
| Side note, I will be exploring a new CUE + Dagger setup, though
| it will work differently than the old Dagger engine
| pxc wrote:
| I'm not totally opposed to powerful (Turing-complete)
| languages being used for configuration or defining builds-- I
| think Nix works really well in that space, and someday Nickel
| may as well.
|
| But wherever I've seen build tools from a language ecosystem
| that just embed a DSL in the host language (e.g.: sbt,
| Gradle), I've also seen projects get way too clever with
| their builds and create total nightmares for downstream
| packaging efforts. I anticipate similar problems for other
| kinds of configuration tools based on general-purpose
| languages, like CI or cloud IaC.
|
| > Side note, I will be exploring a new CUE + Dagger setup,
| though it will work differently than the old Dagger engine
|
| Sounds cool! I'll keep an eye out for it. :)
| jordemort wrote:
| I'm glad that they're just shutting down the service and not
| closing up shop entirely. I really like the tool (to the point
| that I regularly stop by their careers page); the syntax for an
| Earthfile is a very sensible and incremental evolution of
| Dockerfile syntax, and it makes a whole bunch of things easy that
| were either previously impossible or very awkward with a
| Dockerfile alone.
|
| I remember when Docker introduced BuildKit and buildx, they were
| trying to push Dockerfiles as a general-purpose build system
| (i.e. not just for containers but also for producing file
| artifacts and the like) - Earthly takes that idea and really
| delivers on it.
| verdverm wrote:
| Try Dagger, it's better than Earthly
|
| I'm a happy user, not paying them yet
| js4ever wrote:
| Writing a new DSL is doomed and OP started by that. You will have
| to bend the world to make devs using it. Give them something they
| want, and no one wants to learn a new DSL and rewrite everything.
___________________________________________________________________
(page generated 2023-09-12 23:01 UTC)