3 ms·

bazels for building. and by all means use bazel if thats your jam, not what EG is about directly. Personally, I never saw bazel as terribly useful with the lan

bazels for building. and by all means use bazel if thats your jam, not what EG is about directly. Personally, I never saw bazel as terribly useful with the languages I use since they tend to have decent build/dependency management built in. (aka: it was a solution made for c/c++ and python which have terrible build systems) Nor did I find it useful for running test suites when I needed to include postgresql/redis/what have you into the environment. EG is about integrating the entire lifecycle from local development to deploying into production to managing SOP for deployed environments using virtualization. You can think of it as codespaces/temporal combined without ever needing to touch a cloud provided system. My main problem with those systems is essentially: not local first, priced for large companies, and usually require a team of engineers to maintain for the company. essentially I find those to be the antipatterns in software today. (I dont consider EG a CI/CD tool to be honest, just a problem it handles really well)

LegNeato 2y ago
You are mistaken on many accounts: 1. Bazel/Buck is not just for building, it is a task runner with built in distributed execution and caching. Which is, uh, what CI is. 2. You not finding it useful might be because you want to continue to use the same methods and tools yet get different results. Bazel/Buck supports Go and Rust and those just fine (JS is steadily improving as well, I know multiple public companies using it). Now, the DX may be different or non-standard but that's the point...different methods for different results. Of course there are tradeoffs to it not being the standard way to do things for a particular language! 3. You can run postgresql/redis/what have you into the environment with Bazel/Buck, all the companies using these tools do it. Almost everyone wires it up to https://testcontainers.com/ https://testcontainers.com/, see https://www.docker.com/blog/revolutionize-your-ci-cd-pipeline-integrating-testcontainers-and-bazel/ https://www.docker.com/blog/revolutionize-your-ci-cd-pipelin.... 4. For integrating the entire lifecycle, this is how it is set up at most companies...use Bazel/Buck for building the environment, use Bazel/Buck for building, use Bazel/Buck to trigger a deploy, etc. For example, see https://github.com/adobe/rules_gitops https://github.com/adobe/rules_gitops Again, not trying to be rude, just drop info. Your list of pain points in the post is real, but only with certain / older systems or ways of using them. If you look into the newer systems, you'll see that they were largely created to solve those issues!

LegNeato 2y ago

You are mistaken on many accounts: 1. Bazel/Buck is not just for building, it is a task runner with built in distributed execution and caching. Which is, uh, what CI is. 2. You not finding it useful might be because you want to continue to use the same methods and tools yet get different results. Bazel/Buck supports Go and Rust and those just fine (JS is steadily improving as well, I know multiple public companies using it). Now, the DX may be different or non-standard but that's the point...different methods for different results. Of course there are tradeoffs to it not being the standard way to do things for a particular language! 3. You can run postgresql/redis/what have you into the environment with Bazel/Buck, all the companies using these tools do it. Almost everyone wires it up to https://testcontainers.com/ https://testcontainers.com/, see https://www.docker.com/blog/revolutionize-your-ci-cd-pipeline-integrating-testcontainers-and-bazel/ https://www.docker.com/blog/revolutionize-your-ci-cd-pipelin.... 4. For integrating the entire lifecycle, this is how it is set up at most companies...use Bazel/Buck for building the environment, use Bazel/Buck for building, use Bazel/Buck to trigger a deploy, etc. For example, see https://github.com/adobe/rules_gitops https://github.com/adobe/rules_gitops Again, not trying to be rude, just drop info. Your list of pain points in the post is real, but only with certain / older systems or ways of using them. If you look into the newer systems, you'll see that they were largely created to solve those issues!