-
-
Notifications
You must be signed in to change notification settings - Fork 234
feat(bash-hook): Add cli arg to override sentry-cli command #852
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
When using `sentry-cli` through Docker, the bash hook does not work as: 1. The inferred path of `sentry-cli` becomes the path inside the container, and does not apply to the host 2. The files used for reporting live outside the container and they need to be mapped to the container when running it. This patche choses the more flexible `--cli` argument to solve both problemes where one can do something like ```docker run --rm getsentry/sentry-cli bash-hook --cli='docker run --rm -v "$_SENTRY_TRACEBACK_FILE:$SENTRY_TRACEBACK_FILE" -v "$_SENTRY_LOG_FILE:$_SENTRY_LOG_FILE" getsentry/sentry-cli ``` Now that's ugly as hell, yes and we may opt to have auto detection for running inside docker to handle this. The downside is then we'd not support any other container engine.
src/commands/bash_hook.rs
Outdated
| if matches.is_present("cli") { | ||
| script = script.replace( | ||
| "___SENTRY_CLI___", | ||
| &env::current_exe().unwrap().display().to_string(), | ||
| ); | ||
| matches.value_of("cli").unwrap() | ||
| ); | ||
| } else { | ||
| script = script.replace("__SENTRY_CLI__", &env::current_exe().unwrap().display().to_string()); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of this, I tried every possible variation of matcher and unwrap_or_else etc. but they gave me hell with the temporary return value of the env::current_exe().unwrap().display().to_string() call or some weird mismatch between String and str types.
Open to suggestions to make this more "rustic".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.replace(
"__SENTRY_CLI__",
matches
.value_of("cli")
.unwrap_or(&env::current_exe().unwrap().display().to_string()),
);There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kamilogorek that runs the expression &env::current_exe().unwrap().display().to_string() for the fallback unconditionally, which is why I went with this path (after exhausting the path of closures)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, that'll be eagerly evaluated, and returning a ref from unwrap_or_else is tricky.
src/commands/bash_hook.rs
Outdated
| if matches.is_present("cli") { | ||
| script = script.replace( | ||
| "___SENTRY_CLI___", | ||
| &env::current_exe().unwrap().display().to_string(), | ||
| ); | ||
| matches.value_of("cli").unwrap() | ||
| ); | ||
| } else { | ||
| script = script.replace("__SENTRY_CLI__", &env::current_exe().unwrap().display().to_string()); | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.replace(
"__SENTRY_CLI__",
matches
.value_of("cli")
.unwrap_or(&env::current_exe().unwrap().display().to_string()),
);
When using
sentry-clithrough Docker, the bash hook does not work as:sentry-clibecomes the path inside the container, and does not apply to the hostThis patch chooses the more flexible
--cliargument to solve both problems where one can do something likedocker run --rm getsentry/sentry-cli bash-hook --cli='docker run --rm -v "$_SENTRY_TRACEBACK_FILE:$SENTRY_TRACEBACK_FILE" -v "$_SENTRY_LOG_FILE:$_SENTRY_LOG_FILE" getsentry/sentry-cliNow that's ugly as hell, yes and we may opt to have auto detection for running inside docker to handle this. The downside is then we'd not support any other container engine.