-
Notifications
You must be signed in to change notification settings - Fork 255
Teach upload! and download! to respect within(...) #408
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
Teach upload! and download! to respect within(...) #408
Conversation
3b75f57 to
1db04bf
Compare
|
I totally missed the functional test directory. After some fun with Vagrant I got some tests similar to the existing tests which |
|
Thanks for the PR! I appreciate the tests and CHANGELOG entry. I hope to have time to review this soon. Would you say this is a breaking change? |
|
This doesn't break existing documented usage, which is to use absolute paths. That usage should be totally unaffected. But if a user has relied on the incidental behaviour of relative paths being relative to the ssh connection's default current working directory (instead of sshkit's within(...) working directory) then that might break. But it was always documented that this wasn't supported, so maybe that's okay? Idk. Perhaps a minor version increment with a note calling out the change? |
mattbrictson
left a comment
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.
Looks good! If you could add a note regarding potential breakage to the CHANGELOG as you suggested, that would be great. Put it as another bullet point and I'll make sure it gets formatted correctly when I do the next release.
lib/sshkit/backends/local.rb
Outdated
| end | ||
|
|
||
| def upload!(local, remote, options = {}) | ||
| remote = File.join(pwd_path, remote) unless remote[0] == "/" |
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.
Nitpick: I'd prefer remote.start_with?("/") instead of remote[0] == "/" here and elsewhere, for readability.
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.
Oh yeah that's much nicer. 👍
I always avoid #start_with? thinking it was ActiveSupport or introduced in Ruby 2+, but it's been around since 1.8.7. 🙈
|
@mattbrictson Thanks for helping me get this through! Totally agree with the nitpick, fixed. And I've added a note to the changelog which you can edit as you like. Also had to fix a bundle problem with Ruby 2.0 on Travis. |
|
Looks good, thanks! |
|
Thanks! 🙇 When do you think this might make it into a release — is there anything else lined up? |
|
This will probably go out on Friday or over the weekend |
|
🙇 |
|
Just had a script breaking because it relied on the old behaviour. Easy enough to fix, but as far as I can tell simply detecting that we're not in a within block and then keeping the new behaviour should be as easy as adding a check for |
|
@Fjan Ah, you're right. Good catch! This breaks if you upload to a relative remote path without using a Anyway, I agree that a |
|
Yep, the old behaviour just uploads / downloads relative to the user's home directory. I'm a it swamped at work and have not contributed to the project before so it will take some time before I can get to doing a PR, so would be great if someone more experienced can do it. |
|
Ok, I went ahead and created a PR (#411) |
## [1.16.0][] (2018-02-03) * [#417](capistrano/sshkit#417): Cache key generation for connections becomes slow when `known_hosts` is a valid `net/ssh` options and `known_hosts` file is big. This changes the cache key generation and fixes performance issue - [@ElvinEfendi](https://github.com/ElvinEfendi). ## [1.15.1][] (2017-11-18) This is a small bug-fix release that fixes problems with `upload!` and `download!` that were inadvertently introduced in 1.15.0. ### Breaking changes * None ### Bug fixes * [#410](capistrano/sshkit#410): fix NoMethodError when using upload!/download! with Pathnames - [@UnderpantsGnome](https://github.com/UnderpantsGnome) * [#411](capistrano/sshkit#410): fix upload!/download! when using relative paths outside of `within` blocks - [@Fjan](https://github.com/Fjan) ## [1.15.0][] (2017-11-03) ### New features * [#408](capistrano/sshkit#408): upload! and download! now respect `within` - [@sj26](https://github.com/sj26) ### Potentially breaking changes * `upload!` and `download!` now support remote paths which are relative to the `within` working directory. They were previously documented as only supporting absolute paths, but relative paths still worked relative to the remote working directory. If you rely on the previous behaviour you may need to adjust your code.
I've been using sshkit to automate some deployment tasks recently and found the tasks would be easier if
upload!anddownload!respected mywithin(...)context.They already seem to work with remote relative paths which use the remote cwd, but don't respect the
within(...)path stack. But we can just prependpwd_pathto remote path if it's relative to make it work.This might be a breaking change for some users, although the documentation does say to always use absolute paths.
Also I have no idea how to test this, beyond doing a whole bunch of manual testing against a real ssh remote. 😅