Hook Environment Variables Mirrored in Template Placeholders

[baxterjo]

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!

[epage]

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?

[baxterjo]

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.

[epage]

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?