Open baxterjo opened 1 month ago
Looks like the only ones missing are
WORKSPACE_ROOT
CRATE_ROOT
DRY_RUN
Not to say "no" but to further explore this, is there a reason you need access to these on the command-line, rather than using a script to wrap them that can access them?
Mainly repository hygiene. I could add a script at the root of each package that accesses the WORKSPACE_ROOT
env var to call the main pre-release hook. But that option requires N scripts to be added/changed in the repo when they're just wrappers for the pre-release hook I really want.
To address the issue that I really^2 want is the option to run a pre-release hook only once at the root of the workspace when releasing the workspace. The way I'm versioning/releasing the workspace is by sharing versions with all the packages and releasing the whole workspace at once.
The behavior I expected originally when adding the pre-release-hook
to [workspace.metadata.release]
was that it would run once in the root of the workspace. Then if I wanted a "per-package" release hook I could add it to the [package.metadata.release]
for that package. But that was not the case.
To address the issue that I really^2 want is the option to run a pre-release hook only once at the root of the workspace when releasing the workspace. The way I'm versioning/releasing the workspace is by sharing versions with all the packages and releasing the whole workspace at once.
My main concern with supporting this is cargo-release
can't tell when the end of a release set is done. We can't infer user intention which is made harder by the fact that releases are non-atomic and doing releases in piece-meal is our recommended recovery step if a release fails.
In the past, we've recommended people pick a representative crate to run a hook. Is there a reason you can't do that here?
It sounds like you want one post-workspace-release hook but instead you run a hook after every package. Is it happenstance that your scripts don't interfere with each other or do you have to take extra steps for that?
I appreciate the add for having placeholders resolve in pre-release hooks.
Could we expand this functionality to also include some of the ENV vars that are passed to the hook? I would love the ability to define my hook at the root of my workspace and run it anywhere, regardless of the shape/depth of the workspace. This would require me to expand the
WORKSPACE_ROOT
env var in the pre-release-hook argument list. Which is not possible since it is not a shell.Thanks!