ざっくりん雑記

プログラミングで忘れそうなことをひたすらメモる

Travis CI - repository not known to https://api.travis-ci.com: [repository_name]

RailsアプリをTravis CIを経由してHerokuへのデプロイするように設定していましたが、ある時、失敗するようになりました。

結論から言うと、「リポジトリ名を変更した際に、gitの環境変数まで更新しなかったため」失敗していました。

バージョン情報

$ heroku -v
heroku-cli/6.12.9 (darwin-x64) node-v8.1.4
$ travis -v
1.8.8
$ git --version
git version 2.13.3

発生した際の各種ログ

Travis CI - Job log

...

Preparing deploy
No stash entries found.
API request failed.
Message: Invalid credentials provided.
Reference: 
failed to deploy

Message: Invalid credentials provided.というメッセージから、credentialsをheroku cliから更新してあげればよいかと次の操作をしました。

$ travis encrypt $(heroku auth:token) --add deploy.api_key
 ▸    heroku-cli: update available from 6.12.9 to 6.14.39-addc925
repository not known to https://api.travis-ci.com/: account_name/old_repository_name

account_name/old_repository_nameを参照しようとして、repository not known to https://api.travis-ci.com/ということで、この古いリポジトリ指定を新しくrenameしたリポジトリに更新してあげれば良いことが分かりました。

解決方法

.git/configを更新する

対象のリポジトリ.git/configを開き、[travis]セクションのslugキーのリポジトリ名を更新します。

[travis]
        slug = account_name/old_repository_name 

old_repository_nameからnew_repository_nameへ更新してあげます。

[travis]
        slug = account_name/new_repository_name 

travis encryptコマンドでcredentialsを更新して、.travis.ymlへ反映する

$ travis encrypt $(heroku auth:token) --add deploy.api_key
 ▸    heroku-cli: update available from 6.12.9 to 6.14.39-addc925

こうすると、特にエラーが吐き出されないので、gitで差分を見てみると.travis.ymldeployセクションのsecureが更新されているのが分かります。

$ git diff HEAD
diff --git a/.travis.yml b/.travis.yml
--- a/.travis.yml
+++ b/.travis.yml
@@ -1,35 +1,28 @@
...
 deploy:
   provider: heroku
   api_key:
-    secure: KuiegwFqeEcQAh8fZwMKyYIg6WSAe8EOaO74/t8A5Axz+....
+    secure: Bcq0iP7rlO7LXyLKTMDSqW2GS+bkjB+FxZYUMtscbXcJ...
...

この状態をpushすると、Message: Invalid credentials provided.に対する解決が完了し、無事デプロイできます。

結構ハマりましたが、案外シンプルな問題でした。もっとgitについて知っておけば、ハマらなかったなと…。

f:id:azuuun:20171206184156p:plain

参考

github.com

Linux - atコマンドで任意のコマンドをジョブとしてスケジューリングする

atコマンドの設定方法

基本の設定は以下の記事を参考に進めました。

uxmilk.jp

指定の時刻に任意の場所にnull.txtファイルを生成する

[vagrant@localhost ~]$ at 15:35 2017-11-29
at> touch ~/null.txt
at> <EOT>
job 5 at 2017-11-29 15:35

<EOT>というのは、End of textのことでCtrl + dで実行できます。

job 5というのが、2017-11-29 15:35 に実行されるとの出力がされました。

ジョブで実行されるコマンドを調べる

[vagrant@localhost ~]$ at -c 5
<ここで環境変数などが全て出力されるので、ここは省略>
touch ~/null.txt

touch ~/null.txtが実行されることが分かります。

ジョブの一覧を確認する

[vagrant@localhost ~]$ atq
5   2017-11-29 15:35 a vagrant

先程設定した job 5 が表示されました。

job 5が無事実行されたのか確かめる

2017-11-29 15:35まで待ちましょう。 実行したコマンドはtouch ~/null.txtなので、ホームディレクトリでlsすれば確認できそうです。

[vagrant@localhost ~]$ cd
[vagrant@localhost ~]$ pwd
/home/vagrant
[vagrant@localhost ~]$ date
Wed Nov 29 15:35:26 JST 2017
[vagrant@localhost ~]$ ls
null.txt

生成されてますね。

[vagrant@localhost ~]$ atq

ジョブ一覧からもjob 5は消えたので、実行ができたということが確認できました。

Can't open /var/run/atd.pid to signal atd. No atd running? と警告された場合

[vagrant@localhost ~]$ at 14:40 2017-11-29
at> touch ~/nul.txt
at> <EOT>
job 1 at 2017-11-29 14:40
Can't open /var/run/atd.pid to signal atd. No atd running?

atd.pid というのがatコマンドでスケジューリングしたものを実行してくれるデーモンのようで、これが存在しないので実行されないのでは?という警告みたいです。

なので、起動するように設定してあげれば解決できます。(今回はrootユーザーで設定)

[root@localhost vagrant]# /sbin/chkconfig atd on
[root@localhost vagrant]#  /etc/rc.d/init.d/atd restart
Stopping atd:                                              [FAILED]
Starting atd:                                              [  OK  ]

以上で、設定ができるようになると思います。 なお、この警告を無視しても、指定した時間にコマンドが実行されないで残るだけなので、「設定したのに、実行されない」という場合もこの手段は有効です。

参考

Rails - DeviseのPassword confirmationを無効にする

無効にするには

DeviseのWikiに記述がありました。

Easiest solution is: you can simply remove the password_confirmation field from the registration form located at devise/registrations/new.html.erb (new.html.haml if you are using HAML), which disables the need to confirm the password entirely!

Disable password confirmation during registration · plataformatec/devise Wiki

「単純にパスワードを確認する必要のないViewのフォームからpassword_confirmationフィールドを削除するだけです。」ということみたいです。

参考

Heroku - タイムゾーンを日本に設定する

Herokuのタイムゾーン設定方法

一言でいうと

$ heroku config:add TZ=Asia/Tokyo --app [app-name]で設定可能。

サーバの現在時刻を調べる

HerokuはデフォルトでタイムゾーンAsia/Tokyoではない(リージョンはUnited Statesの場合)

コンソールを立ち上げて確認してみる(heroku run console)。

$ heroku run console --app hoge-app
Running console on ⬢ hoge-app... up, run.1087 (Free)
Loading production environment (Rails 4.2.7)
irb(main):001:0> Time.now
=> 2017-03-25 04:13:28 +0000
irb(main):002:0> exit

なお、Herokuで作成しているアプリが一つしかない場合は--appオプションは必要ないが、複数ある場合は一意に特定して実行するために--app [app-name]という感じで指定してあげている。

日本時間は現在13時頃だが、2017-03-25 04:13:28 +0000となっている。

サーバのタイムゾーンを設定する

$ heroku config:add TZ=Asia/Tokyo --app hoge-app
Setting TZ and restarting ⬢ hoge-app... done, v35
TZ: Asia/Tokyo

TZという環境変数Asia:Tokyoを設定することで、タイムゾーンが日本になる。

設定が反映されているか確認してみる。

$ heroku run console --app hoge-app
Running console on ⬢ hoge-app... up, run.2172 (Free)
Loading production environment (Rails 4.2.7)
irb(main):001:0> Time.now
=> 2017-03-25 13:14:20 +0900
irb(main):002:0> exit

日本での現在時刻と一致していることが分かる。

以上です。

追記: ブラウザで設定する

下記リンクのアプリ設定画面にてConfig VariablesからReveal Config Varsをクリックすることで、環境変数を管理できます。

https://dashboard.heroku.com/apps/[app name]/settings

ターミナルと同様に、TZという環境変数Asia:Tokyoを設定すれば良いです。

https://gyazo.com/885f68d443cd9dd1c671c4f82d6a8759

あれですね、$ heroku config:add TZ=Asia/Tokyoとこのブラウザで設定するのは同じ動作ということです。ブラウザ上で設定しても、heroku run consoleで設定がうまくいっているか確認すると思うので、ターミナルで設定するのがよさそう。

参考

qiita.com

Heroku - git push heroku master すると Everything up-to-date となる

現在チェックアウトして作業しているブランチをpushする

はじめてデプロイする際は難なくデプロイできて、 その後再度デプロイする際に、

$ git push heroku master

すると、

Everything up-to-date

既に全部上がってるよと言われる。

現在、自分がチェックアウトして作業しているブランチがmaster以外で、たとえばissues-3ブランチで作業している場合は、

$ git push heroku issues-3:master

としなければいけない、初歩的な勘違いでした。

参考

Heroku へ初デプロイで引っかかった bundle install - Qiita

Rails - 環境変数を三項演算子を使って適応させる

方法

Rails.env == 'production' ? ENV['FACEBOOK_APP_ID_PRODUCTION'] : ENV['FACEBOOK_APP_ID_DEVELOPMENT']

三項演算子はすっきり書けて、最近ハマっています。

参考

たのしいRuby 第5版

たのしいRuby 第5版

【Ruby・Rails】三項演算子(条件演算子)を使ってif文をスリムに書こう! - Qiita

Swift - switch文

Swiftでのswitch文の書き方

オーソドックスな書き方

let signalColor = "green"
switch signalColor {
case "green":
    print("通過しても良いです")
case "yellow":
    print("停止できるなら停止してください")
case "red":
    print("停止してください")
default:
    print("判定不能")
}
通過しても良いです

レンジ演算子を使った判定

for i in 1...20 {
    switch i {
    case (1...5):
        print("...")
    case (5...10):
        print(".........")
    case (10...15):
        print("................")
    default:
        print("default")
    }
}
...
...
...
...
...
.........
.........
.........
.........
.........
................
................
................
................
................
default
default
default
default
default

タプルを利用したswitch

let imageSize = (1080, 1920)
switch imageSize {
case (0, 0):
    print("幅, 高さともに0です")
case (320, 480):
    print("iPhone 3G世代")
case (1080, 1920):
    print("iPhone 6世代以降")
default:
    print("判定できませんでした")
}
iPhone 6世代以降

バリューバインディング

かっこいい響き。

let resolutionSize = (1080, 100)
switch resolutionSize {
case (0, 0):
    print("幅, 高さともに0です")
case (320, 480):
    print("iPhone 3G世代")
case (1080, let height):
    print("高さが規格外:\(height)")
case (let width, 1980):
    print("幅が規格外:\(width)")
case (1080, 1920):
    print("iPhone 6世代以降")
default:
    print("判定できませんでした")
}
高さが規格外:100

caseの条件式において値を使用する

let physicalInfo = (180, 80, 30) // 身長, 体重, 年齢
switch physicalInfo {
case let (height, weight, _) where (height >= 120) || (weight <= 100):
    print("体重が低すぎるか, 体重が重すぎるため, 乗れません")
case let (_, _, age) where (age >= 12):
    print("12歳以上でなければ, 乗れません")
default:
    print("乗れます")
}
体重が低すぎるか, 体重が重すぎるため, 乗れません

default を省略する

バリューバインディングを用いることで、かならず当てはまる条件式を書いた場合は、defaultを省略できる。

let point = (10,100)
switch point {
case (0, 0):
    print("中心点")
case (0, _):
    print("x軸上にある点")
case (_, 0):
    print("y軸上にある点")
case let(x, y):
    print("(\(x),\(y))")
}
(10,100)

参考