Handle workspaces that are not located at the root of a repository

[LukeMathWalker]

Annoying fact: .github is only taken into account if it sits at the root of the repo. In Pavex our workspace is rooted at libs. If I run cargo dist init from the repository root, I get an error: "No workspace found; either your project doesn't have a Cargo.toml/dist.toml, or we couldn't read it" If I run cargo dist init from the libs subfolder, the command works, but the generated CI files go into libs/.github, which will not work.

I can see a few different ways to solve this (e.g. take some kind of workspace path in init or detect the git root from wherever init is run).

[LukeMathWalker]

If you're looking for an example: https://github.com/LukeMathWalker/pavex/blob/main/.github/workflows/release.yml It's the vanilla script generated by cargo-dist modified to prepend the nesting prefix libs/ where necessary to get things to work.

[Gankra]

We should absolutely be handling this right, been putting it off for too long!

There's kinda two levels of support here:

• have manual config to tell cargo-dist "the root of the repo is actually over there" (which i think would mostly just tell ci.yml.j2 to cd into that dir at the start of every job...? oh and of course change the path to .github we use)
• have cargo-dist properly detect your git repo and do this For You (i'm sure there's some Very Evil corner cases to doing this, so the manual impl will probably be necessary regardless) (but if we do this it Probably wants to live in axoproject..?)

lemme see how bad the manual solution is...

[Gankra]

actually unless you wanna give it a shot?

[LukeMathWalker]

I think the design space is a bit larger than what I can sign myself up to handle right now. Another relevant corner case: there might be multiple workspaces in the same repository, nested at different sub-paths, each with its own applications to release.

[Gankra]

I think we're ~fine to require you to have only one cargo-dist workspace in a repo (we're increasingly developing our own manifest format so a Really complicated situation can be forced into that path).

[mistydemeo]

This situation has improved with recent changes we've merged, but we're not quite there yet. We now generate the config in the right spot, instead of inside the workspace, but the Actions scripts will still try to run cargo-dist in the root of the repo instead of the root of the workspace. This brings us a lot closer to fixing it though!

[mistydemeo]

I just noticed this is a duplicate of #870. I'm going to close this to consolidate the discussion in one place.