Capistrano3のデプロイのリポジトリ先を変更する

Capistrano3を使ってデプロイを行っているアプリがあったのだけれど、途中でgitのリポジトリを変更しなければならなくなってしまったので、そのときのメモ。

config/deploy.rbのrepo_urlを変更する。

diff --git a/config/deploy.rb b/config/deploy.rb
index 871df02..ba68d20 100644
--- a/config/deploy.rb
+++ b/config/deploy.rb
@@ -2,7 +2,7 @@
 lock '3.2.1'

 set :application, 'mywebapp'
-set :repo_url, 'git@git123.foo.com:mywebapp.git'
+set :repo_url, 'git@git789.bar.com:mywebapp.git'

 # Default branch is :master
 ask :branch, proc { `git rev-parse --abbrev-ref HEAD`.chomp }.call

新しいgitリポジトリに向き先を変えて、pushする。

$ git remote set-url origin git@git789.bar.com:mywebapp.git
$ git push -u origin master

ここまでは簡単なのだけれど、Capistrano3ではこのままだとまだ旧リポジトリの方を参照し続けてしまうので、デプロイ先のサーバで作業が必要だった。

$ cd /var/www/mywebapp
$ rm -r repo

deploy_toに設定しているディレクトリの、「repo」というディレクトリに既存のリポジトリ情報が入っているので、一度消してしまえば次からは上で設定したrepo_urlのリポジトリを見るようになる。

試してないけど、

$ cat repo/config
[core]
	repositoryformatversion = 0
	filemode = true
	bare = true
[remote "origin"]
	url = git@git123.foo.com:mywebapp.git
	fetch = +refs/*:refs/*
	mirror = true

のurlを書き換えるだけでもいけるかもしれない。

あとはデプロイ。

$ bundle exec production deploy

参考:
ruby - Capistrano deploy fails after I changed the repository URL - Stack Overflow

SidekiqのWorkerクラス内でJobIDを知る

Sidekiq::Workerをincludeして使っているクラス内のperformメソッド内で自分のJobIDを知るには、self.jidで取れる。

class MyWorker
  include Sidekiq::Worker

  def perform
    job_id = self.jid
    puts job_id
    # some codes
  end
end

job_id = MyWorker.perform_async

なので、Sidekiqに登録したJobIDを、そのままworkerの処理結果のキーとして使えば結果の取得が簡単だ。

親メソッドのテスト

よくわからなくなったのでメモ。

メソッドを作ったのでテストを書く。

class H
  def hoge(flag)
    if flag
      "hogehoge"
    else
      "hoge"
    end
  end
end

describe H do
  describe "#hoge" do
    subject{ H.new.hoge(flag) }
    context "when flag is true" do
      let(:flag){ true }
      it{ should eq "hogehoge" }
    end
    context "when flag is false" do
      let(:flag){ false }
      it{ should eq "hoge" }
    end
  end
end

この後、このH#hogeを呼び出すメソッドを作ったときにそのメソッドのテストは、hogeのflagにまで言及すべきなのだろうか。

class H
  def hoge(flag)
    if flag
      "hogehoge"
    else
      "hoge"
    end
  end

  def h(flag)
    [hoge(flag)]
  end
end

describe H do
  describe "#hoge" do
    subject{ H.new.hoge(flag) }
    context "when flag is true" do
      let(:flag){ true }
      it{ should eq "hogehoge" }
    end
    context "when flag is false" do
      let(:flag){ false }
      it{ should eq "hoge" }
    end
  end

  describe "#h" do
    subject(:h){ H.new }

    # このcontextは必要？
    context "when flag is true" do
      let(:flag){ true }
      specify{ expect(h.h(flag)).to eq ["hogehoge"] }
    end
  end

  describe "#h" do
    # それとも#hogeはもうテストしているから、もっと単純なテストの方がよいのか？
    subject(:h){ H.new.new(flag) }
    let(:flag){ true }
    it{ should eq [hoge(flag)] } # そのままhoge()を呼んでいる
  end
end

[hoge(flag)]で動的に期待値を出しているのは強引な感じがするけど、
このあとhogeメソッドの挙動が変わったときに、hの方のテストの修正までするのはちょっと面倒くさい。

hogeの方のテストでカバレッジは網羅できていて、hの方のテストでtrue/falseを試す必要があるのかどうか悩む。