Ensure UUID of command is shared when redacted #455
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In logging, the command UUID displayed in the "command start" phase was sometimes different to that displayed with the output of the command. This is because the backend can call `.with_redaction` on a command when logging the start, and this causes the command to be duplicated. However, if the `uuid` method hadn't been called before that point, the copy command would generate its own UUID, distinct from the original command. This change avoids that by eagerly calculating the UUID when the command is created, so that any copied objects share the same UUID.
Member
|
Excellent PR, thanks! Congratulations on your first code contribution to the project 🎉 |
Member
|
Kudos @lazyatom really nice fix, practical and has flown under the radar for circa 5 years! 🥇 |
Contributor
Author
|
My pleasure, and thanks for your help and work on this project! 🎉 |
netbsd-srcmastr
pushed a commit
to NetBSD/pkgsrc
that referenced
this pull request
Nov 18, 2019
Update ruby-sshkit package to 1.20.0. ## [1.20.0][] (2019-08-03) * [#468](capistrano/sshkit#468): Make `upload!` take a `:verbosity` option like `exec` does - [@grosser](https://github.com/grosser) ## [1.19.1][] (2019-07-02) * [#465](capistrano/sshkit#456): Fix a regression in 1.19.0 that prevented `~` from being used in Capistrano paths, e.g. `:deploy_to`, etc. - [@grosser](https://github.com/grosser) ## [1.19.0][] (2019-06-30) * [#455](capistrano/sshkit#455): Ensure UUID of commands are stable in logging - [@lazyatom](https://github.com/lazyatom) * [#453](capistrano/sshkit#453): `as` and `within` now properly escape their user/group/path arguments, and the command nested within an `as` block is now properly escaped before passing to `sh -c`. In the unlikely case that you were manually escaping commands passed to SSHKit as a workaround, you will no longer need to do this. See [#458](capistrano/sshkit#458) for examples of what has been fixed. - [@grosser](https://github.com/grosser) * [#460](capistrano/sshkit#460): Handle IPv6 addresses without port - [@will-in-wi](https://github.com/will-in-wi) ## [1.18.2][] (2019-02-03) * [#448](capistrano/sshkit#448): Fix misbehaving connection eviction loop when disabling connection pooling - [Sebastian Cohnen](https://github.com/tisba) ## [1.18.1][] (2019-01-26) * [#447](capistrano/sshkit#447): Fix broken thread safety by widening critical section - [Takumasa Ochi](https://github.com/aeroastro)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In logging, the command UUID displayed in the "command start" phase was sometimes different to that displayed with the output of the command. This is because the backend can call
.with_redactionon a command when logging the start, and this causes the command to be duplicated. However, if theuuidmethod hadn't been called before that point, the copy command would generate its own UUID, distinct from the original command.This change avoids that by eagerly calculating the UUID when the command is created, so that any copied objects share the same UUID.
Fixes #454