Subdirectory/Monorepo support?

[DenuxPlays]

Hey, In one of my rust projects we use a monorepo. I've wondered if it is possible to tell cargo-dist to run all the workflows within a sub directory?

[ashleygwilliams]

@DenuxPlays hey! we do support this. a good example is how libsql uses us. the primary tool that they use is that they "namespace" the tag that they release libsql-server with, and they configure cargo-dist using the "tag-namespace" config to recognize it.

here's a link to the "tag-namespace" docs: https://opensource.axo.dev/cargo-dist/book/reference/config.html#tag-namespace

and here's a link to the libsql monorepo if you are curious about an example! https://github.com/tursodatabase/libsql/blob/main/.github/workflows/libsql-server-release.yml

[DenuxPlays]

@DenuxPlays hey! we do support this. a good example is how libsql uses us. the primary tool that they use is that they "namespace" the tag that they release libsql-server with, and they configure cargo-dist using the "tag-namespace" config to recognize it.

here's a link to the "tag-namespace" docs: https://opensource.axo.dev/cargo-dist/book/reference/config.html#tag-namespace

and here's a link to the libsql monorepo if you are curious about an example! https://github.com/tursodatabase/libsql/blob/main/.github/workflows/libsql-server-release.yml

That sounds awesome. Our release procedure has changed a little bit I will have to look into if we can implement cargo-dist in it.

[Gankra]

development note: we've mostly refactored the code in preparation for this, the last thing that needs to be done is changing the release.yml template to support the various dirs it works with being in non-default locations. This requires additional piping of relevant values.

In the process we'll probably fix the issue with us hardcoding the target dir

[Gankra]

Hmm I am realizing that now that we have a dist-workspace.toml which you can drop in the root and point at other subdirs, we don't necessarily need to natively support the actual workspace root not being in the repo root. So it's possibly a good idea to close this out with a recommendation that people who need this should use that?