{"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":28,"created_at":"2014-02-10T15:43:59Z","updated_at":"2016-06-15T16:34:20Z","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/226244206","html_url":"https://github.com/capistrano/capistrano/issues/929#issuecomment-226244206","issue_url":"https://api.github.com/repos/capistrano/capistrano/issues/929","id":226244206,"user":{"login":"mattbrictson","id":189693,"avatar_url":"https://avatars.githubusercontent.com/u/189693?v=3","gravatar_id":"","url":"https://api.github.com/users/mattbrictson","html_url":"https://github.com/mattbrictson","followers_url":"https://api.github.com/users/mattbrictson/followers","following_url":"https://api.github.com/users/mattbrictson/following{/other_user}","gists_url":"https://api.github.com/users/mattbrictson/gists{/gist_id}","starred_url":"https://api.github.com/users/mattbrictson/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/mattbrictson/subscriptions","organizations_url":"https://api.github.com/users/mattbrictson/orgs","repos_url":"https://api.github.com/users/mattbrictson/repos","events_url":"https://api.github.com/users/mattbrictson/events{/privacy}","received_events_url":"https://api.github.com/users/mattbrictson/received_events","type":"User","site_admin":false},"created_at":"2016-06-15T16:34:19Z","updated_at":"2016-06-15T16:34:19Z","body":"@DylanFrese I think many people would appreciate a robust rsync plugin for Capistrano. This isn't my usual method of deployment, and I don't have much experience with rsync beyond the basics, so I'm afraid I can't offer much implementation advice.\r\n\r\n> should this functionality be part of Capistrano by default?\r\n\r\nNo, we have a long-term goal of moving all SCM implementations out of Capistrano and into plugins. In terms of official documentation and sample code maintained core team, we will likely continue to recommend the pull-based-SCM strategies as the official \"Capistrano way\" of deploying. Of course this doesn't prevent you from publishing a plugin and adding it to the [plugins page](http://capistranorb.com/documentation/third-party-plugins/).\r\n\r\n> There are a few rough edges\r\n\r\nMy first impression is that direct net-ssh access, using interprocess communication with rsync, etc. sounds very complicated. Keep in mind that if you choose to publish this, other people that use it will feel entitled to support. The easier you can make the solution, the easier it is to troubleshoot, and the lower the support burden will be. Good documentation also helps a lot, so also budget time for that when making your decision whether to open source.\r\n\r\n>  I hear there's a new plugin infrastructure?\r\n\r\nIt is coming, but not released yet. You can get a sneak peak here: https://github.com/capistrano/documentation/pull/188\r\n\r\nMy final bit of advice: the pull-from-SCM approach that Capistrano uses today is particularly useful because it makes a guarantee about what will be deployed. When you `cap deploy`, you and your colleagues can be certain that a particular tag or commit was actually deployed. With a push-based approach, unless you put lots of SCM-specific safeguards in place, you could end up deploying code that hasn't been committed or pushed. Deployment is all about predictability and reproducibility, so this is something I would seriously consider before choosing a push-based solution."}}
{"actor":{"display_login":"mattbrictson"}}