ekho/capistrano-git-submodule-strategy

Git submodule support for Capistrano 3

capistrano-git-submodule-strategy's Issues

Duplicated commands caused by requiring 'capistrano/git'

Hi Boris,

thanks for your work.

I'm using capistrano 3.4.0 and I've noticed that when using capistrano-git-submodule-strategy git commands are issued twice.

I think the problem is in capistrano itself, because it loads capistrano/git.rb instead of requiring it [1]. Every time git.rb is executed tasks are appended to the existing ones, hence the duplication.

I plan to open an issue in capistrano too, but I was wondering:

1. do you have the same problem?
2. if yes, do you have a workaround?

Thanks

Gabriele

[1] https://github.com/capistrano/capistrano/blob/master/lib/capistrano/setup.rb#L16

Broken with Capistrano 3.7

Related to issue #15. With Capistrano 3.7 I get the following error:

user@pc ~/app> cap -T --trace
cap aborted!
LoadError: cannot load such file -- capistrano/git
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/bundler/gems/capistrano-git-submodule-strategy-fa678a8160c8/lib/capistrano/git-submodule-strategy.rb:1:in `require'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/bundler/gems/capistrano-git-submodule-strategy-fa678a8160c8/lib/capistrano/git-submodule-strategy.rb:1:in `<top (required)>'
/home/user/app/Capfile:18:in `require'
/home/user/app/Capfile:18:in `<top (required)>'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/rake_module.rb:28:in `load'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/rake_module.rb:28:in `load_rakefile'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:687:in `raw_load_rakefile'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:96:in `block in load_rakefile'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:178:in `standard_exception_handling'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:95:in `load_rakefile'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:79:in `block in run'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:178:in `standard_exception_handling'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/rake-12.0.0/lib/rake/application.rb:77:in `run'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/capistrano-3.7.0/lib/capistrano/application.rb:14:in `run'
/home/user/.asdf/installs/ruby/2.3.0/lib/ruby/gems/2.3.0/gems/capistrano-3.7.0/bin/cap:3:in `<top (required)>'
/home/user/.asdf/installs/ruby/2.3.0/bin/cap:22:in `load'
/home/user/.asdf/installs/ruby/2.3.0/bin/cap:22:in `<main>'
/home/user/.asdf/installs/ruby/2.3.0/bin/ruby_executable_hooks:15:in `eval'
/home/user/.asdf/installs/ruby/2.3.0/bin/ruby_executable_hooks:15:in `<main>'

LoadError: cannot load such file -- capistrano/git-submodule-strategy

I installed the plugin as per your instructions in my system and got the following:

$ cap staging deploy
(Backtrace restricted to imported tasks)
cap aborted!
LoadError: cannot load such file -- capistrano/git-submodule-strategy
C:/Users/Len/Desktop/area51/rails/Capfile:11:in `<top (required)>'
(See full trace by running task with --trace)

Can you please help with the same?

Failing to authenticate correctly with git. Capistrano 3.40, git 1.9.1

When trying to the checkout, it doesn't correctly authenticate back to github for the submodule update.

DEBUG [6dd13baf]   git version 1.9.1
DEBUG [6dd13baf] Finished in 0.252 seconds with exit status 0 (successful).
 INFO [a1adaea7] Running /usr/bin/env git clone --depth=1 -b capistrano_update file:///usr/share/puppet/barista/repo /usr/share/puppet/barista/releases/20200831204343 as [email protected]
DEBUG [a1adaea7] Command: cd /usr/share/puppet/barista/repo && ( export GIT_ASKPASS="/bin/echo" GIT_SSH="/tmp/barista/git-ssh.sh" ; /usr/bin/env git clone --depth=1 -b capistrano_update file:///usr/share/puppet/barista/repo /usr/share/puppet/barista/releases/20200831204343 )
DEBUG [a1adaea7]   Cloning into '/usr/share/puppet/barista/releases/20200831204343'...
 INFO [a1adaea7] Finished in 0.896 seconds with exit status 0 (successful).
DEBUG [f3715b46] Running if test ! -d /usr/share/puppet/barista/releases/20200831204343; then echo "Directory does not exist '/usr/share/puppet/barista/releases/20200831204343'" 1>&2; false; fi as [email protected]
DEBUG [f3715b46] Command: if test ! -d /usr/share/puppet/barista/releases/20200831204343; then echo "Directory does not exist '/usr/share/puppet/barista/releases/20200831204343'" 1>&2; false; fi
DEBUG [f3715b46] Finished in 0.269 seconds with exit status 0 (successful).
 INFO [034e30f5] Running /usr/bin/env git remote set-url origin [email protected]:onehub/barista.git as [email protected]
DEBUG [034e30f5] Command: cd /usr/share/puppet/barista/releases/20200831204343 && ( export GIT_ASKPASS="/bin/echo" GIT_SSH="/tmp/barista/git-ssh.sh" ; /usr/bin/env git remote set-url origin [email protected]:onehub/barista.git )
 INFO [034e30f5] Finished in 0.253 seconds with exit status 0 (successful).
DEBUG [3b601a64] Running if test ! -d /usr/share/puppet/barista/releases/20200831204343; then echo "Directory does not exist '/usr/share/puppet/barista/releases/20200831204343'" 1>&2; false; fi as [email protected]
DEBUG [3b601a64] Command: if test ! -d /usr/share/puppet/barista/releases/20200831204343; then echo "Directory does not exist '/usr/share/puppet/barista/releases/20200831204343'" 1>&2; false; fi
DEBUG [3b601a64] Finished in 0.256 seconds with exit status 0 (successful).
 INFO [bdd9c110] Running /usr/bin/env git submodule update --init --recursive as [email protected]
DEBUG [bdd9c110] Command: cd /usr/share/puppet/barista/releases/20200831204343 && ( export GIT_ASKPASS="/bin/echo" GIT_SSH="/tmp/barista/git-ssh.sh" ; /usr/bin/env git submodule update --init --recursive )
DEBUG [bdd9c110]   Submodule 'Verona' (https://github.com/onehub/verona) registered for path 'Verona'
DEBUG [bdd9c110]   Cloning into 'Verona'...
DEBUG [bdd9c110]   remote: Invalid username or password.
DEBUG [bdd9c110]   fatal: Authentication failed for 'https://github.com/onehub/verona/'
DEBUG [bdd9c110]   Clone of 'https://github.com/onehub/verona' into submodule path 'Verona' failed

I know that my credentials are good because I can update the submodule manually on the remote server:

git submodule update --init --recursive
Cloning into 'Verona'...
Username for 'https://github.com': xXxXxXxXxX (hiding login)
Password for 'https://[email protected]':
remote: Enumerating objects: 2308, done.
remote: Counting objects: 100% (2308/2308), done.
remote: Compressing objects: 100% (1596/1596), done.
remote: Total 2308 (delta 400), reused 2292 (delta 389), pack-reused 0
Receiving objects: 100% (2308/2308), 4.47 MiB | 0 bytes/s, done.
Resolving deltas: 100% (400/400), done.
Checking connectivity... done.
Submodule path 'Verona': checked out 'f5656edb151bd65ed9c703dd916d92a278dd0562'

So I'm not sure what is going on. Why isn't the --recursive being done at initial checkout?

Adopt to new capistrano plugin system

Discuss started at capistrano/capistrano#1572

Cache submodules

... to prevent cloning from remote server everytime

update mirroring

see clone and update
https://github.com/capistrano/capistrano/blob/master/lib/capistrano/git.rb

Will this over-ride existing strategy?

My deploy.rb already sets a git_strategy.

set :git_strategy, RemoteCacheWithProjectRootStrategy

Will this gem over-ride that? Can strategies be combined or chained?

git_keep_meta is undocumented

I'm setting it to true for a project of mine to avoid the "fatal: not a git repository" message with every bundler invocation.

I am not sure about the tradeoffs of this option.

unknown option `dissociate'

Hi,

I am having an issue related to 'dissocate' option.

cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing as [email protected]: git exit status: 129
git stdout: Nothing written
git stderr: error: unknown option `dissociate'

It's not ignoring the folders defined in the .gitattributes

I'm trying to not deploy the folders defined in my .gitattributes but it's not working. Have a look in my file:
/tests export-ignore
/bin export-ignore

Is there another way to ignore some folders?

double-checking on git:release not working quite right.

I don't know why the cap tasks run twice, do you?

Anyway, I hit that issue and I found that your fix wasn't working for me.

If I understand what you are trying to do you only want to do the git clone if:

• the directory exists AND
• the directory is empty

I made a quick hack in the gem and found that the following change worked:

# git-submodule-strategy.rb
...
    def release
      if context.test(:test, '-e', release_path) && context.test("find #{release_path} -maxdepth 0 -empty | read")
        git :clone, '--depth=1', '--recursive', '-b', fetch(:branch), "file://#{repo_path}", release_path
        context.execute("find #{release_path} -name '.git*' | xargs -I {} rm -rfv {}")
      end
    end
...

Remove .git/objects/info/alternates after clone

git status 
error: object directory /path/to/mirror/repo/objects does not exist; check .git/objects/info/alternates.
fatal: bad object HEAD

Error - fatal: destination path '/var/sites/s/staging/public_html/releases/xxxxxx' already exists and is not an empty directory.

I modified my files as described in your Readme, ran bundle update and then bundle exec cap staging deploy.

All looks good until I get the following error. I hope it's due to some basic mistake on my part(!) as the directory it is complaining about looks like it is meant to exist as it's the one we are deploying to...

https://gist.github.com/henscu/b38b0943b14b20358b6b

Thanks,
H

Git Submodule Sync should be called before Update

If for whatever reason the url for a submodule in .gitmodules is changed, if you don't run "git submodule sync", your current checked repo will still use the old url if it has checked that submodule before.

So, there is no other option than running 'git submodule sync' before the 'git submodule update --init --recursive'.