mileswjohnson

11 ms·

1.
Moon now supports Rust in its task runner(moonrepo.dev)
1 points by mileswjohnson 3y ago|0 comments
2.
Moon task runner now on v1(moonrepo.dev)
2 points by mileswjohnson 4y ago|0 comments
3.
Moon task runner now supports Deno(moonrepo.dev)
1 points by mileswjohnson 4y ago|0 comments
4.
by mileswjohnson 4y ago
<3
5.
by mileswjohnson 4y ago
Should give moon a try if you ever have free time :)
6.
by mileswjohnson 4y ago
moon will only run on affected projects, so you're not building/testing everything. This is done through a combination of hashing + caching. It's also language agnostic because you can technically run anything through moon, b
7.
by mileswjohnson 4y ago
We'll get there eventually! Adding support for other languages in Rust is a very long process.
8.
by mileswjohnson 4y ago
At a quick glance, I don't believe there's any overlap.
9.
by mileswjohnson 4y ago
Yes it can! That's pretty much the only way it works. The `moon run` command will only run if affected by changed files, and `moon ci` will only run affected tasks/projects in CI pipelines.
10.
by mileswjohnson 4y ago
Thanks will take a look at.
11.
by mileswjohnson 4y ago
Gotcha. While moon doesn't solve this directly, you do have a few options here: - Use git submodules. Have the node repo have a submodule on the app repo. - Publish the shared code to a private registry (like github's package regi
12.
by mileswjohnson 4y ago
Yeah, we kind of regret mentioning Bazel in the original post, but we can't change it now.
13.
by mileswjohnson 4y ago
Based on everyone's feedback about YAML (we didn't expect this much), we'll probably reconsider this!
14.
by mileswjohnson 4y ago
Thanks for the feedback and prototyping with it immediately! Always appreciated to get hands on feedback.
15.
by mileswjohnson 4y ago
We have a long ways to go, but our end goal for moonbase is basically buildbuddy, but for non-bazel users. Right now moonbase requires moon, but we're looking to decouple it.
16.
by mileswjohnson 4y ago
If you end up using moon, and there's anything abrasive/convoluted, let us know! We're always looking for ways to streamline.
17.
by mileswjohnson 4y ago
> Does it enforce hermecity or deterministic builds or give me tools to accomplish it? I wouldn't say moon is hermetic, nor are we trying to be. We don't use the sandbox approach for tasks, and run against the original files. F
18.
by mileswjohnson 4y ago
Can you speak to what kind of "functionality" you need a language for? Are you referring to Starlark-like files?
19.
by mileswjohnson 4y ago
Can you talk a bit more about what kind of code is being copied?
20.
by mileswjohnson 4y ago
Thanks for the feedback. Too much configuration is something we keep thinking about, and are working to streamline. It's a bit involved since we support multiple languages.
21.
by mileswjohnson 4y ago
We agree. We weren't happy with all of the current solutions, at least in the JavaScript space. In regards to build graph invalidation, we attempt to hash pieces at the granular level. This includes per file content hashing, and for de
22.
by mileswjohnson 4y ago
I don't disagree here. At the moment, moon leans closer to a task runner, with hashing, incremental caching, and other features tacked on. All of our currently supported languages are not compile based languages, and run with pre-built
23.
by mileswjohnson 4y ago
Thank you. This is how we feel as well.
24.
by mileswjohnson 4y ago
A lot of our decisions were based on our past experience with Bazel. We both have worked at companies that tried to use Bazel and failed miserably. There's stuff we like about Bazel (and copied in some capacity, like file groups), and
25.
by mileswjohnson 4y ago
We haven't built the on-prem solution yet, but we're leaning towards using Helm charts + Kubernetes. At minimum, it will all be Dockerfile based.
26.
by mileswjohnson 4y ago
insert xkcd comic
27.
by mileswjohnson 4y ago
Our configuration is using globs but under the hood we content hash all the files that match the glob, and only run/cache if the aggregated hash has changed. For the languages we currently support, this is more than enough. Once we div
28.
by mileswjohnson 4y ago
Yup exactly that! We want a single to to handle version bumping, changelog generation, publishing to a registry, etc, for _all_ languages that we support.
29.
by mileswjohnson 4y ago
Yeah at a high-level, that's how it works. However, the incremental caching part does require remote caching of artifacts, so that they can be shared across CI jobs/runs.
30.
by mileswjohnson 4y ago
I'm not very familiar with Buck. But I'm assuming it works the same way as Bazel's Starlark? I can see the benefits of "generating code" within the BUILD file, but honestly, we haven't required it yet, and have

More ›