{"action":"created","issue":{"url":"https://api.github.com/repos/capistrano/capistrano/issues/929","repository_url":"https://api.github.com/repos/capistrano/capistrano","labels_url":"https://api.github.com/repos/capistrano/capistrano/issues/929/labels{/name}","comments_url":"https://api.github.com/repos/capistrano/capistrano/issues/929/comments","events_url":"https://api.github.com/repos/capistrano/capistrano/issues/929/events","html_url":"https://github.com/capistrano/capistrano/issues/929","id":27275662,"number":929,"title":"Do not load SCM tasks unless an SCM is defined","user":{"login":"leehambley","id":18952,"avatar_url":"https://avatars.githubusercontent.com/u/18952?v=3","gravatar_id":"","url":"https://api.github.com/users/leehambley","html_url":"https://github.com/leehambley","followers_url":"https://api.github.com/users/leehambley/followers","following_url":"https://api.github.com/users/leehambley/following{/other_user}","gists_url":"https://api.github.com/users/leehambley/gists{/gist_id}","starred_url":"https://api.github.com/users/leehambley/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/leehambley/subscriptions","organizations_url":"https://api.github.com/users/leehambley/orgs","repos_url":"https://api.github.com/users/leehambley/repos","events_url":"https://api.github.com/users/leehambley/events{/privacy}","received_events_url":"https://api.github.com/users/leehambley/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/capistrano/capistrano/labels/new%20feature","name":"new feature","color":"009800"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":29,"created_at":"2014-02-10T15:43:59Z","updated_at":"2016-06-15T18:50:30Z","closed_at":null,"body":"Related to #718 and a handful of other issues which relate to deploying without an SCM, unloading the SCM, deploying via copy, tar ball, BitTorrent or quantum entanglement.\n\nI propose, based on the work done in #718 to only load the flow, that without `set(:scm, “something”)` we should not load an SCM at all.\n\nI propose that we could solve this by doing runtime class resolution, and autoloading of files incase a class is undefined, which may mandate changes to the structure of the SCM code. In that case we would still load the `git` namespace from `git.rake` (and others) - but avoid, if possible inserting the tools, which we could do in an `include` or similar hook in `git.rb`"},"comment":{"url":"https://api.github.com/repos/capistrano/capistrano/issues/comments/226283748","html_url":"https://github.com/capistrano/capistrano/issues/929#issuecomment-226283748","issue_url":"https://api.github.com/repos/capistrano/capistrano/issues/929","id":226283748,"user":{"login":"DylanFrese","id":11223986,"avatar_url":"https://avatars.githubusercontent.com/u/11223986?v=3","gravatar_id":"","url":"https://api.github.com/users/DylanFrese","html_url":"https://github.com/DylanFrese","followers_url":"https://api.github.com/users/DylanFrese/followers","following_url":"https://api.github.com/users/DylanFrese/following{/other_user}","gists_url":"https://api.github.com/users/DylanFrese/gists{/gist_id}","starred_url":"https://api.github.com/users/DylanFrese/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DylanFrese/subscriptions","organizations_url":"https://api.github.com/users/DylanFrese/orgs","repos_url":"https://api.github.com/users/DylanFrese/repos","events_url":"https://api.github.com/users/DylanFrese/events{/privacy}","received_events_url":"https://api.github.com/users/DylanFrese/received_events","type":"User","site_admin":false},"created_at":"2016-06-15T18:50:30Z","updated_at":"2016-06-15T18:50:30Z","body":"@mattbrictson \r\n\r\nHey Matt.\r\n\r\n> No, we have a long-term goal of moving all SCM implementations out of Capistrano and into plugins.\r\n\r\nI understand this. By 'by default', I don't mean that the functionality is present in the capistrano library ('capistrano/capistrano'), just that the functionality is in some way made 'official'. If users are expected to also `gem install` a Capistrano SCM plugin when they first install Capistrano, then I suppose there would be no difference.\r\n\r\nUsing interprocess communication with `rsync` *is* complicated, but there is just no other way to tunnel rsync traffic through the tunnels Capistrano has open. The only other way is to let rsync SSH to the server itself, but I do not consider this a working implementation. If there are any differences between the SSH configuration Capistrano is using and the user's SSH configuration, as in my cases, this will flat-out not work. Even if there aren't, it's still opening another SSH connection (let alone another SSH channel) instead of reusing one from Capistrano's pool.\r\n\r\nFor reference, [here is part of the implementation](https://gist.github.com/DylanFrese/afb854245ffe7254aaf072d65dc3f3b4), the part that does all the setup work on the Ruby side.\r\n\r\nAs far as grabbing the Net::SSH connection from SSHKit, I don't really like it either. It gets into SSHKit implementation details, calls a private method (line 38 in the gist), and assumes the SSHKit backend is Net::SSH, which is not necessarily true (but is true in practice). (Line 34 also has a 'defect', in that, if the arguments passed to the server are long enough (greater than 64kb on Linux, I believe), the write to the pipe will block and the `readpartial` won't get all of the arguments.\r\n\r\n\r\nAnd for philosophy on push v. pull:\r\nMaking a guarantee about what's going to be deployed, or what can be deployed is indeed valuable. But I strongly feel that these checks need to happen on the deployer's machine, not on the server being deployed to. If you have a public repository (that needs no authentication), a simple or non-existent build process, and only ever want to deploy the tip of `master` from that public repository, then the pull-based method works just fine, and gives you the guarantee that only the tip of `master` will ever be deployed without any other fuss. I'm certain I've described a lot of Rails and other Ruby projects, and that this works great for them. I don't expect Capistrano to change the way it thinks about things by default, because it grew up in the Rails etc. ecosystem.\r\n\r\nBut a 15-minute Maven build-and-test-suite that uses several gigabytes of memory and way too much CPU time cannot be run on a production server. SSH-key-forwarding to access a private repository, if not a security vulnerability, is a rather dangerous broadening of attack surface. If I do a 'push' deploy to a compromised server (that I don't know is compromised), the server gets the latest version of the built software. If I do a 'pull' deploy to a compromised server with SSH-key-forwarding, the attacker gains access to, at the very least, the private repository containing all sources. Worse, if I authenticate to my servers with the same key I use to authenticate to the git repository, the attacker now pivots to *every server in my fleet*.\r\n\r\nLike I said, I do make the checks that changes have been committed and pushed, that origin and the current branch have not diverged or that one is behind the other. Yes, these checks are SCM-specific, but they would be anyway if it were the server doing the checking implicitly (by only fetching the tip of the default branch). They're also only 20-30 lines. If any of these checks fail, I prompt the deployer. The deployer can still choose to deploy. I think this is a feature: if absolutely necessary, a deployer can deploy hot changes immediately without having to SSH in and do a manual deploy, giving up all of the other reliability automated deployment gives. A deployer should have the have the ability to deploy what is in his/her working directory *right now* (which I also consider the far more intuitive mode of operation)¹.\r\n\r\nA developer *shouldn't* ever have to do this, though. Normally, a developer shouldn't even be deploying, or necessarily even be allowed to deploy. **CI** should be the entity that's doing the deployment, and CI makes sure only changes that should go out to production actually do.\r\n\r\n_1. If this, what I consider to be a feature, is undesirable, then a far simpler `git remote update && git checkout origin/master` would replicate the same qualities as a pull-based approach. Even cloning on the local machine to a temporary directory, building, and then deploying still seems far preferable to me to doing the same on the remote end._"}}
{"actor":{"display_login":"DylanFrese"}}