atton.blog: GitHub

ラベル GitHub の投稿を表示しています。すべての投稿を表示

2020/07/19

GitHub へ push した際に Docker Hub で docker image を自動 build する

過去に「GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した」という記事を書きました。

前回は image の build を GitHub で行なっていましたが、今回は Docker Hub で build するように変更したお話です。

Docker Hub で docker image を build する

GitHub と連携した automated build という機能を利用しました(設定方法はドキュメント参照)。

前回同様、GitHub に push すると自動的に Docker Hub に image が更新されます。

これまた前回同様、以降は作業ログ等です。

何故構成を変更したのか

image を更新する為に Docker Hub を触っていた時、 GitHub 連携の存在に気付いた為です。

ちなみに、更新していた image は latex-make というもので、MacTeX をインストールせずに LaTeX を実行できる image です。

更新内容は TeX Live 2019 から TeX Live 2020 へのアップデートでした。

GitHub Actions 作成時に気にしていた3つの条件のゆくえ

過去の記事では以下の3つの条件を気にしていました。

Dockerfile が増えた場合も自動で対応する
Dockerfile や関連ファイルに更新が無い Image は Push しない
GitHub Actions だけでなく、ローカルの環境でも build できる

第1条件と第2条件は、 Repository を分割して解決としました(latex-make, webpage-title)。

第3条件はビルドスクリプトをローカルマシンに残す事で解決としました。

構成を変更して良かった点

他の image の README を参考にした結果、 README が整備された

latex-make には使用例が無かったので追記した
shields.io を利用して image のサイズ等のバッジを追加
GitHub/Docker Hub の README を(手動で)統一

Docker Hub に automated build のログが残るようになった

前回は「push したユーザは atton, push 時刻」程度の情報しか無かった

ログイン情報を書くが必要無い

連携時に Docker Hub から GitHub へ権限を要求しているので docker login を実行する必要は無い
具体的に言うと GitHub Actions ではログインパスワードを Secrets に書いていた

なので、Docker Hub のログインパスワードを変更後、Secrets を更新しないと docker login に失敗する

構成を変更して良くなかった点

移行作業が手作業だった

対象となる docker image が2つのみだったので、手作業で移行を行なった
仮に docker image が多かった場合、移行スクリプト等を書く必要があったかもしれない

第2条件が若干緩くなった

master が更新された際に build が行なわれるので、 README だけの変更 commit でも build が発生する
git の tag をトリガーにして build する、等の設定で修正可能
しかし現状の image の tag は latest しか無いので放置中

2020/06/09

GitHub Actions で複数の Dockerfile の build と DockerHub への push を自動化した

私は作成した Dockerfile を GitHub で公開しています(前回の記事の atton/webpage-title も含む)。
Docker Image を手動で管理するのは面倒なので、何らかの形で自動化する事にしました。
最終的に、 Dockerfile が更新された際に build して DockerHub に push する GitHub Actions を作成しました。

GitHub Actions を作成する際に考慮した条件

Dockerfile が増えた場合も自動で対応する(現時点では2つ)
Dockerfile や関連ファイルに更新が無い Image は Push しない
GitHub Actions だけでなく、ローカルの環境でも build できる

具体的な GitHub Actions の内容

作成した .github/workflows/build-and-push.yml とbuild.sh は以下です(commit: 427f143)。

自動化できたので手動 push の必要は無くなりました。べんり。

これ以降は作業ログなどを書いておきますが、かなり長いです。

第一条件: Dockerfile が増えた場合も自動で対応する

この条件については、特定の構成をしているディレクトリを build 対象にする事で対応しました。具体的には

ディレクトリ名は任意

ls と [ -d ] で確認

ディレクトリの直下に Dockerfile が存在する

ls と [ -f ] で確認

といったディレクトリです。なお、ディレクトリ名は Docker Image の tag を決める際に使っています。

第二条件: Dockerfile や関連ファイルに更新が無い Image は Push しない

Docker Image を自動 build する際、最初は elgohr/Publish-Docker-Github-Action@master を使っていました。

ここで問題が発生。README.md を変更しただけの commit でも Docker Image の更新が行なわれました。

幸い、GitHub Actions の step では if が使えるようなので試してみましたが改善せず。

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

なので elgohr/Publish-Docker-Github-Action@master は利用しない方針に変更。
使わない事になりましたが、 entrypoint.sh に書かれた(docker login/logout など)内容は参考にできそうです。

さて、次は「Dockerfile や関連ファイルに更新が無い」事を判定をできれば解決しそうです。ググってみると

$ git diff-tree --no-commit-id --name-only -r ${{ github.sha }}

で確認できるとの事。ではこれを grep して exit code で判定すれば解決、しませんでした。

更新の有無に関わらず、全ての grep の exit code が 1 になっていました。
加えて、ローカル環境では想定通りの exit code が得られるので、どうやら原因は実行環境固有のようです。

「ローカルでは動くが、別環境では動かない」という悲しい事態なので、 printf debug で少しずつ状態を確認していきます。

git は存在するか
git の version は何か
git は実行できるか
remote origin は存在するか
commit log は辿る事ができるか
grep の version は何か
...

結果、「actions/checkout@master を使うと repository の情報が消える(?)」事が判明しました。具体的には

git コマンドは実行できる
git show を行なうと、全ファイルが新規作成扱いになっている
origin を fetch しても commit が取得できない

という謎の状態でした。その為、 actions/checkout@master は利用せずに直接 git clone を実行。
clone した repository では diff-tree が実行可能で、更新の有無が判定可能になりました。

余談: 第二条件の部分を書いている時に思った事

elgohr/Publish-Docker-Github-Action@master のソースを確認すると、 action.yml に if はありませんでした。

Pull Request を作成して提案する手がある

「ローカルでは動くが、別環境では動かない」

GitHub で動作 Image を提供している可能性がある

「actions/checkout@master を使うと repository の情報が消える(?)」

今は git clone で対応できるが、 branch の指定といったオプションに対応できない

第三条件: GitHub Actions だけでなく、ローカルの環境でも build できる

この条件は「ローカル環境でも Docker Image を作成可能」にする為につけました。メリットとしては

問題発生時の再現に使用できる
commit 前の Dockerfile も試しに build できる
新しい Image 作成時の build が楽

等があります。なお、この条件は build.sh に与える引数の有無で解決しました。

まとめ

結構な文量になりました。debug の説明を含めると長くなりますね。

結果的に「uses を排除して自前の run で記述する」というオレオレ GtiHub Actions で解決。

前回も書いた気がしますが、「個人的には十分満足しているので良しとします。」

参考文献や関連した文献など

2019/08/20

hub コマンドの user 設定を変更する

hub というコマンドがあります。
GitHub に関連したコマンドが追加された git の wrapper です。
例えば

$ hub clone neovim/neovim

とすると

$ git clone git@github.com:neovim/neovim.git

相当の事をしてくれます。

git の wrapper になってるので、 hub だけで全てを済ませる派の人がいるかもしれません。

環境

OS: macOS Mojave 10.14.6
Homebrew: 2.1.10
Homebrew/homebrew-core: (git revision ea34; last commit 2019-08-20)
hub: version 2.12.3
git: version 2.23.0

設定を変更するきっかけ

$ hub browse tmux/tmux

とすると tmux/tmux をブラウザで開いてくれます。

$ hub browse hoge

とすると atton-/hoge が開かれました。
私の GitHub Account は 'atton-' で取得して 'atton' に変更した経緯があります。
なのでどこかに古い設定が残っている筈。

$ git config --list

で git の設定を確認しても 'atton-' は存在しない。
むしろ github.user=atton になってるくらい。
hub が git の wrapper になってる事のデメリットがちょっとあって

$ hub config --list

としても git config --list の時と同じ内容が出てくる。
つまり hub 経由で config を update しても git の config が変更されそう。

ということで 'atton-' を設定している部分を探してみる。

設定箇所探し + 設定

$ hub --help

hub と git の help が出る
hub 部分に config とか setting とかの項目は無い

$ man hub

config で search するとありました。
どうやら $HOME/.config/hub に書かれているようです。
編集すると 'user: atton-' になっていたので 'user: atton' に修正。

$ hub browse dot_files

とかすると私の dot_files が開かれるようになりました。良し良し。

おまけ

ちなみに私が良く使うコマンドは

$ hub browse

です。

current directory の repository の github ページがブラウザで開きます。

あとは hub clone くらい……?

実際 hub をあまり使わないのは

hub が無い環境で作業することもある
wrapper が隠してくれているオプションとかに「気付かずに助けられている」のは勘弁

とかの理由があります。

なので、個人的にはなるべく git を使うようにしています。

もちろん hub の方が便利な時は hub を使います。

2017/11/11

ドワンゴの Scala 研修用テキストに Pull Request を投げた

ドワンゴ在籍時代に新人向けの Scala 研修がありました。
研修テキストはGitHubで公開されていて、間違いや修正点があれば Pull Reqest を投げることができます。
テキストを読んでいると、文とサンプルコードの整合性が取れていないのに気付いたので、修正の PR を出しました。
そうしたらマージされた。やったね。

2017/11/01

tmux のバグを踏んだので Pull Request を作ったら Terminal.app のバグだった話

さて。私は tmux の線を ascii にするパッチを自分であてています。
tmux は線を ascii で表示するか、UTF-8 で表示するのオプションがあります。
今日日 UTF-8 非対応というのは稀なので、基本は UTF-8 で表示される筈です。

問題

tmux の線に使われている文字が曲者で、EastAsianAmbiguous という文字種です。
これは文字幅を1にするか2にするか、言語圏によって決めます。
そんな文字を分割線に使うと、言語圏によって線の長さが変わってしまいます。
幅を決める部分は tmux の内部実装と glibc と utf8proc があります。
それらが EastAsianAmbiguous に対応していると問題ないのですが、全部非対応。これはつらい。

UTF-8 で表示する際は、EastAsianAmbiguous を幅固定の線にする Pull Request を作りました。

Pull Request による変更点

単に文字の置換です。

─ (0x2500) -> ￚ(0xffda)
│(0x2502) -> ￨(0xffe8)

という変更をしています。

両方とも固定で幅が1なので、言語圏に依存しません。

例えば、このように表示が崩れていた場合でも

この Pull Request によってこのように綺麗に表示してくれます。やったね。

修正と文字リテラル

さて、当然ですが、文字を置換するにはソースをいじる必要があります。
tty-acs.c というファイルに文字テーブルがあるのでそれらを変更。具体的には x と q です。
さてこれで修正完了、と思ったら "\342\224\200" という謎の表記がある。

実はこいつが分からなくて今まで PR を作ってませんでした。
q に相当する ─ (0x2500) のページを見つめていると、

UTF-8 (binary) 11100010:10010100:10000000

という表記が。

こいつをさらに良く見ると8進数で 3bit ずつ表記されていることに気がつく。

修正する予定のￚ(0xffda) は

UTF-8 (binary) 11101111:10111111:10011010

なので

11 101 111:10 111 111:10 011 010
3 5 7: 2 7 7: 2 3 2
\357\277\232

で書いてみると動いた。やったね。
単に私がこの文字リテラルを知らなかっただけなのですが、閃いた時は楽しかったですね。

メンテナのコメント

この PR で EastAsianAmbiguous を排除するので言語圏に依存せず正しい線が引けます。
なのでマージされると思っていましたが、メンテナの環境では上手くいかないらしい。

んで、以下のオプションを試してくれと

set -as terminal-overrides ',*:U8=0'

こいつを .tmux.conf に書くも、やっぱり私の環境だと上手くいかない。

UTF-8 表示に強制するオプションのようなのですが、そいつを修正するパッチなのに……
正確には ACS というものを使って線を描画するようです。

ちなみに Terminal.app + Ricty では上手くいかない。こうなります。

動かないよって文句を言ったら、「ACS サポートしてないターミナル使ってない?」と。

いやいや公式の Terminal.app ですよと内心思いましたが、iTerm2 と xterm を試すことにしました。
そうしたら何と綺麗に表示されるではありせんか。

どうやら Terminal.app は ACS をサポートしていないようです。つらい。

iTerm2 に乗り換えを検討しましたが、今度は EastAsianAmbiguous に対応しているか問題に変わる。
面倒になったので今まで通りの

Terminal.app
独自パッチの tmux

で運用していこうと思います。

しかし tmux のバグだと思ったら Terminal.app だとは。

流石にそれは修正できない。

これはちょっとしたぼやきなのですが、Terminal.app は結構バグがあるらしい。

Terminal Multiplexer のメンテナが言うからには、色々あったんだろうな、と察する。

しかし nicm さん対応が早い。最初のコメントは10分とかでついた気がする。

反応が早いのはこちらとしても助かるし、いろいろと助言を貰えました。

まー助言の結果 Terminal.app は残念というオチなのですが。

ということで、tmux のバグを踏だので Pull Request を作ったら Terminal.app のバグでした。

環境

OS: macOS 10.12.6
Terminal.app: 2.7.3 (388.1.1)
iTerm2: Build 3.1.5.beta.1
xterm: XQuartz 2.7.11 (xorg-server 1.18.4)
Ricty: 3.2.2
tmux: cf782c4f546fb11f3157de7aecff85845b0dbed9

参考

2017/10/30

Mercurial Repository を Git Repository に変換する

Findy という転職サイトが GitHub の public repository からスキル偏差値なるものを算出してくれます。
一度登録してみると、スキル偏差値はプレミアム本会員になるギリギリの60でした。
実際どのくらいなのだろう60。定量的な値になってると良いのだけれど。

さて、 GitHub には大学とは関係ない個人のプロダクトとかを載せていました。
大学での課題やプロダクトは大学の Mercurial Repository に残しています。
ですが、この際 GitHub にも載せることにしました。
単にスキル偏差値を上げたいだけとも言う。
単に bitbucket に上げても良いのだけれどそれだと Findy に拾って貰えないので。

環境構築

Mercurial から Git への変換は fast-export を使います。

$ git clone https://github.com/frej/fast-export

こいつは python を内部で使ってるのでその調整も必要です。

$ easy_install mercurial

とかかな。

私は python2 を brew で明示的に入れてるので

$ vim fast-export/hg-fast-export.sh

python -> python2

$ pip2 install mercurial

とか。実行時にエラーが出なければOKだと思います。

自分だけが Author の Mercurial Repository の変換

fast-export のセットアップが終わったら、変換します。

$ mkdir git_repo
$ cd git_repo
$ git init
$ ../fast-export/hg-fast-export.sh -r /path/to/hg_repo

これで Mercurial の Repository を元に git に commit しまくってくれます。

きちんと時刻とかも残るので便利。

Author Information が気に入らない場合

私は大学時代の時は大学のメールアドレスで commit していたので、GitHub にはアイコンが無い。

これはちょっ悲しいので Author の情報を変更する。

具体的には username と email ですね。変更するには

とかすると良い。長いけれど1コマンドです。

これは他人の commit も変更できちゃうので完全に悪用厳禁ですね。

他の人も commit している repository の変換

最初にやることは変わらずに変換。

$ ../fast-export/hg-fast-export.sh -r /path/to/hg_repo

んで、 Author を変更する時に発行するコマンドを変えます。

if 文で自分の変えたい username+email を指定してあげています。

これで指定したものだけが変更されます。便利。

こっちも長いけれど1コマンドですね。

これで他人の成果をきちんと残したまま、自分の気に入らないメールアドレスを書き換えられます。

やっぱり悪用厳禁なコマンドなので注意。

fast-export で変換した Repository List

どうせなので公開できる成果物のリストを残しておきます。

思ってたよりありますね。仕事してたなー。

この成果物が誰かの参考になれば幸いです。

オチ

この後 Findy で GitHub 再連携をしたところ、算出方法が変わったようで51に下がりました。かなしい。

環境

OS: macOS 10.12.6
fast-export (cc8fefe0083bc38c781341a86a1779dc5941f6e2)
python: 2.7.10

pip: 9.0.1
mercurial: 4.3.3

Mercurial: 4.3.3
Git: 2.14.3

参考

2017/10/07

Akatsuki を OSS 化した

Akatsuki を OSS 化して GitHub で公開しました。

Akatsuki とは琉球大学情報工学科のシステムです。具体的には

学生のIP申請

対応するドメインを内向き DNS へと登録
その IP を DHCP で配れるように

学生のVM新規作成/起動
学生のパスワード変更

unix login
802.11X で無線に繋ぐ際の RADIUS を提供

といったことができます。

つまり今まで記事で部分部分を解説していたものの本体です。

公開にあたって

もちろん大学の内部情報をそのまま GitHub に投げるわけにはいきません。

なので、こいつは OSS 化用にいじってあります。

具体的には漏れたらまずい情報を消してあります。
あとライセンスは MIT だし気にせず自分でいじって公開していく。

その手順として

$ git rm very-important-information

で公開してはいけない情報を消して

$ git commit

コミットします。

$ git rebase -i --root

その後に rebase します。
全部 fixup して一つのコミットにまとめてしまいます
fixup しないと復元ができてしまうので、消しても意味がない。
ということで、逆に言えばこの手順を踏めばアカンやつを隠蔽できます。

まとめ

所謂実績の一つとして見てもらえると良いかなー、と思って OSS 化しました。

ということで、大学生/大学院生時代にしていた仕事の1つが OSS になりました。

2017/09/23

RGhost に PR を送ってマージされた

現プロジェクトで画像を扱う機会があって RGhost を使っていました。
その時以下のようなエラーが。パッと見て何が起きたか何も分からない。

具体的にその時は Tempfile を渡していたのですが、nil 関係無くても出てくる。

ちょっと困ったなー、ということで調べてみる。
具体的にエラーが発生しているのは shellescape というメソッド。
これを呼んでるのはこことかこことかここ。
RGhost は ImageMagick を使って画像を変換するのでそれ用に引数を shellescape しているようです。
(書いてて思ったけれど ImageMagick 側は何もAPIとか提供してないのかな)

それで、よくよく見てみると file_in は case を使って @document のクラスで確定するらしい。
あー、それなら Tempfile は扱えないな。
ということで File にして一時の問題は解決。
他の人にも同じ轍を踏んで欲しくないので、対応してないのならメッセージが出るとかした方が良いな、と思う。

ということで PR にしてみました。
やったことは単純で、case に else 節を足して例外を投げるように変更。
RGhost::Document と File と String しか対応してないよー、と例外経由でメッセージが出るようになった。
RSpec ももちろん追加。
gemspec に RSpec のバージョンが指定されていないのが若干ひやひやものである。
3.0 未満の RSpec だと raise_error とか無かった気がする。
あと浮動小数の値がちょっと違う。なんか最近YARVに変更入ったっけ。分からない。
そのあたりも含めて最新に合わせつつ、バージョン情報とかを PR に書いて投げた。
そしたら一晩でマージしてくれた。対応早くてうれしい。

という訳で Rubykaigi の熱がさめないうちに OSS 活動をしたのであった。まる。

2017/08/15

GitHub のアカウント名を atton にしてもらった話

GitHub のアカウント名は前々までは atton- だったのですが、atton-.github.io が URLとして認識されづらい問題があったので変更をお願いしてみました。

GitHub には Name Squatting Policy なるものがあり、名前を取るのは早いもん勝ちだけれど流石に使ってない奴に名前を使われ続けるのも何なので、全然使われてないアカウントなら消してあげるよ、みたいなもののようです。

参考にもあるようにテキトーに英文をちょちょっと書いて送る。
実名も載せたのでここでは公開できませんが、

atton github で検索すると私が出る
他のサービスでも私がだいたい atton として通っている

と主張してみたらものの1時間くらいであっさり開放してくれました。

その後は名前変更から atton に変更してしまっておしまい。

ということで使いやすい atton.github.io が使えるようになりました。やったね。
しかし、このブログから参照していたURLが404になる可能性もあるのでその辺りは補完して欲しいです。

参考

2017/06/13

GitHub に push された時に Docker 上の Jenkins から SSH 越しでコマンドを実行する

長いタイトルですがやりたい事は以下です。

Jenkins 経由でデプロイ
デプロイするタイミングは GitHub の master が更新された時
Jenkins は Docker で起動しておく
デプロイに使用するコマンドは SSH 経由で本番サーバに適用

さて、タイトル通りややこしい状態なので記事もだいぶ読み辛いものになりそうです。

環境

CentOS Linux release 7.0.1406 (Core)
Docker version 1.12.6, build 1398f24/1.12.6
Jenkins 2.46.3

Docker でやること(Jenkins を起動する)

docker run -itd --privileged --name kaban -v /hoge/fuga:/var/jenkins_home -P jenkins

これで Jenkins が立ち上がります
--name で名前を付けておくと楽です。とりあえずかばんちゃんです。
Jenkins はデータの永続化のためにボリュームを使っています
適当なディレクトリを /var/jenkins_home にマウントしてください
Jenkins は uid 1000 なので chown 1000 -R <dir> などをしておくと良いです
もしくは chmod で適切な permission を与えてください
-P でポートマッピングを適当にやってもらいます。

docker exec -it kaban cat /var/jenkins_home/secrets/initialAdminPassword

後で Jenkins を起動した際に要求される初期パスワードです。

Jenkins でやること(初期設定)

docker ps をして、8080 がどのポートに割り当てられているか確認します。
ブラウザから Jenkins にアクセスします (http://localhost:32769 とか)
まず初期パスワードを使って Jenkins を起動します
適当に Install Suggested Plugin を選択します(これに Github Plugin とか入ってたので)
管理者ユーザを作ります
Manage Jenkins > Manage Plugins から Available > Publish over SSH を選択します

Publish over SSH プラグインを使ってデプロイします

Install without restart で Publish over SSH を入れます
Configure System > Publish over SSH でデプロイ用サーバに SSH できる設定をします

SSH Servers > Add でサーバを追加します
Name や Hostname や Username 、 Key か Password を設定します

これで土台ができました。

GitHub でやること

デプロイ対象のプロジェクトのリポジトリページに行きます
Settings > Hooks&Services > Add Service から Manage Jenkins(Github Plugin) を入れます

Git Plugin もありますが今回は GitHub Plugin なので間違えないように

Jenkins hook URL に Jenkins の URL を指定します

http://192.168.0.1:32769/github-webhook/ とかです

これで push された際に Jenkins へ通知がいきます。

Jenkins でやること(プロジェクトの設定)

New Project から Freestyle Project を作ります
GitHub Project に check をいれます

なので最初から GitHub Project で作っても良いかも?
Repository URL は GitHub の Project URL を指定してください
Branch Specifier は */master で良いです。 master に変更があった時のみにデプロイなので

Build Triggers で GitHub hook trigger for GITScm polling に check を入れます
Build で Send files or execute commands over SSH を指定します。

SSH Server は先程 Configure で追加したデプロイサーバを指定します。
Transfars: Exec command で SSH 後に実行したいコマンドを指定します。

これで完了です。 GitHub の master が更新されると自動で SSH 経由でコマンドが発行されます。

長い道のりでしたがこんな感じで。

2017/06/08

GitHub Badge なるものを設定してみた

GitHub Badge なるものを設定してみた。

一応このブログの右側には私の各種アカウントを書いているのだけれど、リンクを列挙しているのみなのでちょっと素っ気無かった。
どこかのブログで Github Badge を使っているのを見付けて、単なるリンクより見栄えも良さそうなので使ってみることにしました。

ちなみにこういうものです。

登録: 投稿 (Atom)