よしたく blog

ほぼ週刊で記事を書いています

git rebaseでコミットを分割する

git rebase でコミットの分割ができる。

今回は題材としてスターウォーズを取り上げて実践してみる。 想定のケースは「いくつかコミットをしたが、シーズンごとにファイルをまとめてコミットしてしまった箇所があり、その部分を分割する」というものにする。

準備

まずはファイルを作成する。

mkdir star-wars
cd star-wars
touch star-wars1.txt
touch star-wars2.txt
touch star-wars3.txt
touch star-wars4.txt
touch star-wars5.txt
touch star-wars6.txt
touch star-wars7.txt
touch star-wars8.txt
touch star-wars9.txt

次に git でコミットしていく。 ep4,ep5,ep6 だけseason1 ep4,ep5,ep6というコミットメッセージになっている。

git init
git add star-wars1.txt
git commit -m 'ep1'
git add star-wars2.txt
git commit -m 'ep2'
git add star-wars3.txt
git commit -m 'ep3'
git add star-wars4.txt star-wars5.txt star-wars6.txt
git commit -m 'season1
ep4,ep5,ep6'
git add star-wars7.txt
git commit -m 'ep7'
git add star-wars8.txt
git commit -m 'ep8'
git add star-wars9.txt
git commit -m 'ep9'

コミットの粒度が合っていないので分割する。

現状の確認

現在の状態を確認しておく。

f:id:yoshitaku_jp:20201204214015p:plain

git rebaseでコミットを分割する

git rebase -i HEAD~6を実行するとエディタの画面に切り替わる。 今回は 6 個前までのコミットを表示している。

f:id:yoshitaku_jp:20201204214025p:plain

今回の場合は、ep4,ep5,ep6 を分割したい。 「season1 ep4,ep5,ep6」のpickeditに変更する。 終わったら保存する。

f:id:yoshitaku_jp:20201204214038p:plain

エディタ画面が終わって、普通の画面に戻ってくる。

f:id:yoshitaku_jp:20201204214050p:plain

もう一度、現在の状態を確認しておく。 すると、HEAD の位置が「season1 ep4,ep5,ep6」のコミットメッセージに移っている。

f:id:yoshitaku_jp:20201204214102p:plain

git statusをおこなっても何もファイルがない。

f:id:yoshitaku_jp:20201204214111p:plain

git reset HEAD~を実行し、1 つ前のコミットをステージングに戻す。

もう一度git statusを実行すると、「season1 ep4,ep5,ep6」のコミットがステージングに戻っているのがわかる。 f:id:yoshitaku_jp:20201204214121p:plain

これで、エピソードごとにコミットが可能になる。

git commit -m 'ep4'
git add star-wars5.txt
git commit -m 'ep5'
git add star-wars6.txt
git commit -m 'ep6'

git rebase --continueをおこない、編集状態から抜ける。

f:id:yoshitaku_jp:20201204214133p:plain

git logをすると無事に分割されていることがわかる。

f:id:yoshitaku_jp:20201204214141p:plain

yoshitaku-jp.hatenablog.com

git rebaseでコミットをまとめる

git rebase で過去のコミットをまとめることができる。

今回は題材としてスターウォーズを取り上げて実践してみる。 想定のケースは「各エピソードごとのファイルを作成しコミットしたが、やっぱりシーズンごとにファイルをまとめてコミットしたい」というものにする。

準備

まずはファイルを作成する。

mkdir star-wars
cd star-wars
touch star-wars1.txt
touch star-wars2.txt
touch star-wars3.txt
touch star-wars4.txt
touch star-wars5.txt
touch star-wars6.txt

次に git でコミットしていく。

git init
git add star-wars1.txt
git commit -m 'ep1'
git add star-wars2.txt
git commit -m 'ep2'
git add star-wars3.txt
git commit -m 'ep3'
git add star-wars4.txt
git commit -m 'ep4'
git add star-wars5.txt
git commit -m 'ep5'
git add star-wars6.txt
git commit -m 'ep6'

ここまではエピソードごとにファイルをコミットしてきた。 しかし、コミットの粒度が細かすぎると感じたため、シーズンごとまとめることにした。

git rebaseでコミットをまとめる

git rebase -i HEAD~5を実行するとエディタの画面に切り替わる。 今回は 5 個前までのコミットを表示している。

f:id:yoshitaku_jp:20201204212147p:plain

今回は「ep4,ep5,ep6」をシーズン 1 としてまとめたい。 ep4 へまとめる形にするので、「ep5,ep6」のpicksに変更する。 終わったら保存する。

f:id:yoshitaku_jp:20201204212206p:plain

保存が終了すると、まとめたコミットのコミットメッセージをどうするか聞かれる。 このままでよければ変更をせずに保存する。

f:id:yoshitaku_jp:20201204212222p:plain

ちなみに、変更をせずそのまま保存したときは git log すると次のようになる。 「ep4,ep5,ep6」のコミットメッセージがそのまま結合されている。

f:id:yoshitaku_jp:20201204212234p:plain

まとめるコミットメッセージを変更したい場合

まとめたコミットのコミットメッセージを変更したい場合は、ep4 部分に加筆修正し、ep5,ep6 の部分は削除する。今回は次のメッセージでコミットしてみた。

season1
ep4,ep5,ep6

f:id:yoshitaku_jp:20201204212247p:plain

git logすると、コメントが変更されていることがわかる。

f:id:yoshitaku_jp:20201204212301p:plain

yoshitaku-jp.hatenablog.com

blackをVS codeで使うための手順

Python に限らず、プログラミングで開発する際には様々な便利ツールを導入する。 今回は Python の フォーマッタ である black を VS Code に導入する方法をメモしておく。

black を有効にする

VS Code では autopep8 がデフォルトで有効になっている。 black も設定としては持っているので、変更する。 GUI で設定をおこなうと settings.json にも反映される。

f:id:yoshitaku_jp:20201126214814p:plain

f:id:yoshitaku_jp:20201126215015p:plain

保存時のフォーマット実行 を有効にする

手動でフォーマットを実行するのはめんどくさいので、ファイルを保存したタイミングで実行するようにしたい。 こちらも VS Code の設定画面から有効にできる。 settings.json に追記されていることも確認できる。

f:id:yoshitaku_jp:20201126215036p:plain

f:id:yoshitaku_jp:20201126215101p:plain

貼り付け時のフォーマット実行 を有効にする

貼り付けたタイミングでも実行するようにしたい。 こちらも VS Code の設定画面から有効にできる。 settings.json に追記されていることも確認できる。

f:id:yoshitaku_jp:20201126215136p:plain

f:id:yoshitaku_jp:20201126215202p:plain

black をインストールする

VS Code から black がないことを警告されるのでインストールする。

f:id:yoshitaku_jp:20201126215246p:plain

確認

VS Code で black が有効になっている。

f:id:yoshitaku_jp:20201126215314p:plain

f:id:yoshitaku_jp:20201126215329p:plain

ブログ環境 2020

今年の締めくくりとして今の執筆環境とこれまで移ってきたツールについてアウトプットしておく。

細々と技術ブログを書き続けてきた中で様々なツールに手を出してきた。 例えば、Inkdropだったり、Google Keepだったり、Notion と言ったツールになる。 もちろん、投稿先であるはてなブログや note にそのまま書くこともあった。

これらのツールを選んだ理由としては、2 つある。 一番重視したのはどのデバイスからでも編集できることであり、次に重視したのは自動で保存してくれることだった。 しかし、在宅勤務だったり、家から出る機会が減ったことによって重視する部分に変化が生じてきた。 今重視している部分は、はてなブログへの投稿のしやすさになり、それを実現するためのツールは VS Code となっている。

Notion を断念した

VS Code に寄せる直前は Notion に書いていて、これは自分の情報のすべてを Notion 上で管理したい思いから、ブログも寄せようとしていた。 現状簡単なメモ系はすべて Notion になっている。 しかし Notion は、Markdown で書けるのはよかったものの、段落ごとで文章が独立してしまい投稿する直前で「全選択 → コピー → 貼り付け」ができなかった。 これは自分の使い方が悪かったようなので訂正。

f:id:yoshitaku_jp:20201201182055p:plain
全選択ができない…

VS Code の環境を整えた

今は VS Code 上で書いている。 クラウド上に保存してすべてのデバイスから編集はできなくなったが、いまのところ不便は感じていない。 むしろ、iPadiPhone を文章を書くツールから分離できて今のところ良かった。

現在のフォルダ構成

現在はキャプチャのようなフォルダ構成をとっている。

  • .imagesフォルダは後で解説する。
  • .vscodeフォルダはsettings.jsonが入っていて、このフォルダ配下で実行したい設定を書いている。
  • YYYY/MMフォルダははてなブログの投稿の「月別アーカイブ」がYYYY/MMで管理されているので寄せた。
  • draftフォルダは書きかけのものを管理している。
  • templateフォルダは技術ブログだったり、書評向けだったりのテンプレートを管理している。

f:id:yoshitaku_jp:20201201182125p:plain

textlint を使って校正

textlint を使って校正している。 まだ自分なりの設定は組み込めていないので、少しずつカスタマイズしていきたい。 このブログを書いている目的が、このタイミングでの自分の考えとか思いを反映させたメモであると同時に、「誰か同じことを書いてくれないかな」という期待も含めてあるので書いてくれると嬉しい。

Paste Image を使ってキャプチャ画像をテキストに貼り付ける

拡張機能である「Paste Image」を使って撮ったキャプチャを VS Code に貼り付けて管理している。 各 PC でスクリーンキャプチャを撮った後はクリップボードに内容を持っているが、そのまま VS Code のテキスト部分に貼り付けることはできない。 しかし Past Image を導入すると Mac の場合、「Cmd+Alt+V」で VS Code に貼り付けることが出来る。

下に Past Image のキャプチャを貼り付けた。

f:id:yoshitaku_jp:20201201182139p:plain
これは画像です

marketplace.visualstudio.com

貼り付けた直後のテキスト上だと、次のようになっている。 ../.images/ブログ環境2020/2020-12-01-18-06-32.pngという形でファイルが作成されたことになる。

f:id:yoshitaku_jp:20201201182222p:plain
これも画像です

先程、紹介を飛ばした.imagesフォルダの下は次のようになっている。

f:id:yoshitaku_jp:20201201182310p:plain

Paste Images の設定

保存する形もsettings.jsonで設定でき、自分はデフォルトから下記のように変更した。

{
    "editor.formatOnSave": true,
    "pasteImage.path": "${projectRoot}/.images/${currentFileNameWithoutExt}/",
}

困っていること

現状困っていることは、はてなブログへ投稿する時に画像を 1 回 1 回アップロードし、文章の間に画像を挟み込まなければいけないことである。 Paste Images で VS Code 上では画像の管理がすごく楽になったが、はてなブログにアップロードするときの面倒さは取り除けていない。 VS Code にする以前から存在していた問題ではあるのだが、解決策には巡り会えていない。

はてなブログに投稿するプラグインも見つけたが、自分の問題は解決できなさそうで踏み切れない…。

marketplace.visualstudio.com

まとめ

今年の締めくくりとして今の執筆環境をアウトプットしておいた。 3 ヶ月後、半年後、来年のタイミングで見返した時にどう変化しているか楽しみだ。

flake8をVS codeで使うための手順

Python に限らず、プログラミングで開発する際には様々な便利ツールを導入する。 今回は Python の linter である flake8 を VS Code に導入する方法をメモしておく。

Pylint を無効にする

VS Code では Pylint がデフォルトで有効になっている。 これをまずは無効にする。 GUI で設定をおこなうと settings.json にも反映される。

f:id:yoshitaku_jp:20201125213847p:plain

f:id:yoshitaku_jp:20201125213911p:plain

flake8 を有効にする

デフォルトで入っていた pylint を無効にしたので、次は flake8 を有効にする。 こちらも VS Code の設定画面から有効にできる。 settings.json に追記されていることも確認できる。

f:id:yoshitaku_jp:20201125213941p:plain

f:id:yoshitaku_jp:20201125214005p:plain

flake8 をインストールする

まだ flake8 をインストールしていないので、VS Code から flake8 をインストールするように促される。 今回は install ボタンをクリックしてインストールをおこなう。

f:id:yoshitaku_jp:20201125214030p:plain

確認

VS Code で flake8 を有効になっている。

f:id:yoshitaku_jp:20201125214047p:plain

write-blog-every-week Advent Calendar 2020 を作成しました

今年もやります。

Write-Blog-Every-Weekコミュニティのアドベントカレンダーです
現在所属されている方も、卒業された方も、外から見ている方もお待ちしています
サイト: https://write-blog-every-week.netlify.app

adventar.org

このコミュニティもいつの間にか3年目ですね。 毎年アドベントカレンダーを作ってはTwitterに流していましたが、ストック的な場所にも残しておこうと思ってブログにしておきます。

登録ボタンを押すのはタダですし、投稿するのもタダなので、ぜひよろしくおねがいします。けど、タダほど怖いものはないので計画的に執筆をよろしくおねがいします。

ネタがない人は「イレギュラーな年になったので、今後のキャリア的なことを深く考えた話」系の記事を自分が読みたいので、よろしくおねがいします。

過去のアドベントカレンダー

adventar.org

adventar.org

余談

この記事は今年の投稿数としてカウントしないものとします。

「AWSではじめるデータレイク」を読んだ

AWS ではじめるデータレイク」を読んだ。 この本は、タイトルにもある通りデータレイクの説明を AWS の製品を軸にして語られている。 本の中身は 3 部構成になっていて、1 部で理論を、2,3 部でハンズオンが語られている。

今回ハンズオンは手を付けておらず、1 部の理論について読んだ。 その中で参考になった場所についてまとめておく。

AWSではじめるデータレイク: クラウドによる統合型データリポジトリ構築入門

目次

  1. データレイクの概念と知識
    1. データレイクの構築
    2. データレイクの活用
    3. データレイクの運用
    4. データレイクのセキュリティ
  2. データレイクの実践(基礎編)
    1. ハンズオンの概要 - ビジネスデータのデータレイク
    2. デートを可視化する
    3. サーバレスSQLによるデータ分析
    4. データを変換する
    5. データを分析する(データウェアハウス)
  3. データレイクの実践(応用編)
    1. システムの概要 - ログデータのデータレイク
    2. ログを集める
    3. ログの保管とカタログ化
    4. ログを加工する
    5. ログを分析する

1 章 データレイクの構築

まずはデータレイクの全体像から入り、それを AWS の製品でどう実現するかが語られていた。 その後はもう一度、データの収集、データの保存、データの変換といった詳細部分に話が移っていた。

少し気になった部分があり、まとめの以下の文章になる。

データレイクには「収集」「保存」「変換」「分析」の 4 つのコンポーネントがあります。

と書いてあった。 自分は「データレイクはデータの保管庫」という印象を持っており、他の 3 つの機能も含んでいる表現に違和感があった。 現時点でどちらが正しいかはわからないが、このように表現する人もいることを意識し、認識確認を怠らないように努めたい。

2 章 データレイクの活用

1 章はデータを使う前の段階までの工程の話だった。 2 章はデータを「誰が」「どのツールを使って」「どのようにデータを利用するか」について重きをおいて話が進んでいる。

  • BI
  • SQL によるアドホック/探索的な分析
  • データウェアハウスによる複雑/定常的な SQL
  • Python/R による応用的な分析

ここでも AWS の製品の名前と具体的な使い方が上がっていて、わかりやすい。 データウェアハウスとデータマートの切り分け方やストリーミングデータの分析方法など、少し突っ込んだ部分にも触れられていてよかった。

3 章 データレイクの運用

1,2 章に関しては事前知識が合ったので、サラッと読んだ。そして、この本で一番知りたかった部分が、3 章と 4 章になる。 1 章の部分でも表現した「データレイクはデータの保管庫」という意識が自分にはあったが、実際に運用していくとイメージが沸かなかった。 もちろん、何でもかんでもデータいれることが悪いのはわかる。しかし、実際にどういう基準で運用していけば良いのかというのがわからなかった。

データレイクの「正常」を定義する として、次のようなものが挙げられていた。

他にもいくつか例が挙げられているが、導入段階でも上記のものを算出するためのどのようなデータが必要か、確認するのに役立ちそうだと思った。 障害が起きたときのために、度のサービスレイヤに対して監視をおこなわなければいけないのか確認したり、マネージドサービスであっても冗長化をどこまで考えなければいけないのかといった気づきを与えてくれた。

クラウド自体も障害を起こすことがあるので、データに関しても扱い方のレベルを変えると言った対策が必要であると感じた。 例えば、常にアクセスできなければいけないデータなのか、消失させていはいけないデータなのかといった部分の確認になる。

最後に、使われていないデータを確認するため、データカタログを使ってアクセス履歴を取得したり、加工の変遷をたどったりすることも重要と語られていた。 「クラウドで大容量のデータレイクなんだからいいのでは?」と思ったが、アーカイブや重複分の削除をおこなうことで、利用料を削減できるので塵も積もれば山となる理論に近いなと思った。

4 章 データレイクのセキュリティ

3 章と同じで、とても読みたかった章である。

最初にある

セキュリティというと、「どういった対策があるか」ということから考えがちですが、そうではなく、「どういった状況で誰から何を守りたいのか」という脅威の想定を最初に考えるべきです

という文章がとても気に入った。 実務の中でも「セキュリティ対策はどんなことをしなければいけないかな」と言った漠然とする質問から、果てしないリスクの可能性を探しに行くことがある。 しかし、自分ごととして捉えるような、自分たちの場合だとどうなのか具体的な状況を想定することでとても建設的な議論がおこなえるように感じた。 これはセキュリティ対策以外でも、今後使っていこうと思った。

早速具体的なデータレイクの運用を想定し、「通信経路」「暗号化」「権限管理と統制の手法」について述べられている。 安全にするため暗号化しましょうという話だけでなく、暗号化の処理で発生するオーバーヘッドについても考慮しようと言ったことも書かれている。 また、ソフトウェアを使った場合のライセンス料などにも目を向けようと言ったことも書かれていて、こういう部分を無視しない姿勢に好感が持てた。

アクセス権限の部分に関しても、利便性とリスクは比例関係にあるので、バランスが大切になると言った話がされていた。 ガードレールのようなものと意識するとわかりやすいと例が示されていて、自分も誰かに説明するときは使わせていただこうと思ったぐらいだ。

まとめ

AWS ではじめるデータレイク」はデータ分析基盤の構築や運用を検討している人にはとても参考になる本だった。 4 章分だけで 130 ページ近くになり、データレイクを学びたい人にとっても有用であるが、AWS での構築を検討している人には残り半分のハンズオンも参考になり価格以上の価値を見いだせると思う。 自分は普段 AWS を使っていないことと、個人利用の無料枠を使い切ってしまっているので、割愛したが時間とお金に余裕がある時に手を付けてみようと思う。

Data Engineering Study #4「データ分析基盤の障害対応事例LT祭り」 を視聴した

Data Engineering Study #4「データ分析基盤の障害対応事例 LT 祭り」に視聴者として参加させてもらった。 自分は普段、 Azure を使ったデータ分析基盤の導入支援をおこなっている。 そのため、各コンポーネントの簡単な知見などは知っているが、運用面や障害対応の知見がないため非常に楽しみにしていた。

今回のブログは自分用のメモと資料のまとめとして書き留めておく。

Data Engineering Study #4「データ分析基盤の障害対応事例 LT 祭り」

forkwell.connpass.com

アーカイブはこちら

正確な意思決定を阻む問題障害との向き合い方

発表者は @syou6162さんです。

(仕事の打ち合わせで視聴できずアーカイブ待ちです…) (ブログ投稿直前にアーカイブに気がついたので、後で編集)

www.slideshare.net

データ分析基盤の障害を未然に防ぐためのチェックリスト

発表者は @sotaron さんです。

コンポーネント毎にチェックポイントがあってわかりやすかった。

(見直したかったけど、資料が見つかりませんでした…)

IoT デバイスデータ収集の難しい点

発表者は@fetarodc さんです。

  • IoT デバイスのデータ収集はスキルセットがぜんぜん違う
  • IoT はエンジニアの総合格闘技
    • エンジニア成り立ての時、ラズパイでなにか作ってみようとしたけど、全然うまくいかなかったことを思い出した。
  • ネットワークは切れることがある。
  • ログは見ることが出来ない
    • このあたり、Maker Faire 東京で、会場に持っていったときに動かなくなったのは思い出だ…。

ラズベリーパイのデータを OSS を組み合わせて可視化しようとしたが、断念したことを思い出した。 いつか手を付けてみよう。

www.slideshare.net

障害、解決、その先に

発表者は@sista05 さんです。

4 つの事例が出てきた上に、Twitter 上での議論が非常に活発になって面白かった。 総論に出てきた「マネージドサービスに任せるほうがいい」「構成は簡単に、保守はしやすいように」ということは非常に共感した。

docs.google.com

障害はチャンスだ!障害を前向きに捉える

発表者は@nii_yan さんです。

  • モブプロ/ペアプロになり、他の人のコマンドを見られる。
    • Q&A に出てきたが、モブプロと言うより、二次災害を防ぐためにダブルチェックを兼ねての知見共有の意味合いがある
  • 知らないシステムでも仕様を知れる。
  • ポストモーテム

    • 障害の事後検証報告書の意味
    • 障害復旧へ携わった本人以外に、組織も成長できる。
  • 障害対応しているときにモブプロしている余裕がある?

  • 障害対応しているときに別の障害を起こしてしまう可能性がある。ダブルチェックをするような感覚でモブプロをしている。

speakerdeck.com

バッチとストリーミング それぞれの障害に立ち向かう

発表者は@syu_cream さんです。

自分はデータ処理基盤の「導入支援」はおこなっていて、バッチレイヤとスピードレイヤをラムダアーキテクチャとしてお客様に紹介する機会はあった。 しかし、運用面での知見がないので、分けたあとでの実務面で発生しうる問題を把握できておらず大変参考になった。

speakerdeck.com

まとめ

普段からデータ分析基盤を運用している方々の知見が聞けてよかった。 やはりこの手の勉強会は OSS だったり Azure 以外のクラウドベンダーの話が多かった。 自分自身の話の幅を広げるためにも他のコンポーネントも少しは理解しようと思った。

今回のテーマは障害についてだった。 障害対応した際の話はなかなか表に出てこなかったり、発表する機会もなかったりする。 なので、発表の中の話の言葉を借りると、この LT 祭りをポストモーテムのような役割として四半期に 1 回ぐらいのペースでおこなうと良いのではないかと思った。

Twitterハッシュタグが流れる速さもちょうどよくて、そちらからも情報収集ができ刺激を受けることが出来た。

余談

オンラインイベントに参加したときのレポートは「視聴した」にしたほうが良いのかと思って、タイトルを変えてみた。

じぶん Release Notes 0.30.06

10 月 1 日〜31 日の間の出来事がリリースされました。

10 月の感想

9 月から一転して、10 月はリフレッシュと自分を見つめ直す月になりました。 リフレッシュに関しては旅行に行きました。行った場所については下記です。

  • 宮城(松島)・福島(蔵王
  • 北海道(札幌)
  • 大阪・京都・静岡

社会的に少し落ち着いてきたといいつつ、まだまだ怖い部分もあります。 そのため、移動手段を車にしたり、日帰りにしたりと少し工夫をしました。

自分見つめ直すに関しては、いろいろな人と話す機会を設けました。 これは自分から動いた時もありますし、相手から声をかけてもらえた時もあります。 単純に気分が落ちていたところで話聞いてもらえるだけでも嬉しかったのに、わざわざ DM やらメッセージやらいただくケースもあって最高に嬉しかったです。

中でも話題として多かったのは今後のキャリアについて考える話でした。 常日頃から漠然と「今後どうしていこうかなぁ」とは考えていましたが、毎回の結論も漠然と「技術力を身に付けなきゃなぁ」となっていました。 それが、多くの人と話している中で「(ユーザに貢献したいので、多様な実現手段として)技術力を身に着けなきゃなぁ」と思っていることが自分の中ではっきりしました。 これは自分の中でとても大きな体験でした。

自分の中で「技術力を身につける」と言う目標を立てたときは、「ギークになりたいわけではないけど…」少ししっくりこない場面はありました。 もちろん、新しいことを学ぶことは常に楽しいですし、技術を深くことを学びたくないわけではありません。 しかし、何のために学ぶのかを考えたときに、本当にやりたいことかモヤモヤしていました。

何の為学ぶのかがはっきりしましたが、もちろんこれが正解かわかりません。 しかし、今自分が向くべきベクトルをはっきりさせることができました。 これからはそれに合わせてインプットとアウトプットを変えていきたいと思います。

技術・開発関連

イベント

  • Effective Python 輪読会
    • 8 章
    • 9 章
    • 10 章
  • レガシーコードからの脱却輪読会

読んだ本

ブログ

リリースノートを除き、次のエントリを書きました。

yoshitaku-jp.hatenablog.com

yoshitaku-jp.hatenablog.com

PV 数

3475 でした。

GitHub Actionsを手動で実行する

GitHub Actions が手動での実行に対応していたので試した。 以前 Firebase Hosting にデプロイするとき、 GitHub Actions は使ったことがあった。しかし、そのときには手動実行はなかった。 ブログによると 2020/07 に手動実行への対応をしていたようだ。

github.blog

今回は既存のワークフローに手動実行を取り込むのではなく、新しいワークフローを作成し確認していく。

使い方

テンプレートから GitHub Actions を作成する

GitHubリポジトリに移動し、「Actions」をクリックする。次に「New workflow」をクリックする。

f:id:yoshitaku_jp:20201022074942p:plain

2020/10/20 現在はデフォルトの画面が次のようになっている。今回は HelloWorld が出力される「Simple workflow」を使用する。「Set up this workflow」をクリックする。

f:id:yoshitaku_jp:20201022075004p:plain

「Simple workflow」の内容が書いてある、「blank.yml」ファイルを作成する画面になる。まずは設定値を付けないと手動実行ができないことを確認する。このまま「Start commit」をクリックする。コミットメッセージを入力する画面が表示されるので、そのまま「Commit new file」をクリックする。

f:id:yoshitaku_jp:20201022075029p:plain

GitHub Actions」の実行ファイルを配置するディレクトリに「blank.yml」が作成されている。

f:id:yoshitaku_jp:20201022075046p:plain

「Actions」タブを開いてみる。「blank.yml」を作成したタイミングで「GitHub Actions」が動いていることが確認できる。また、現時点では手動実行ができる画面は見当たらない。

f:id:yoshitaku_jp:20201022075107p:plain

手動実行の設定をおこなう

ここから手動実行の設定をおこなっていく。まずは、作成した「blank.yml」をブラウザ上から編集するため移動する。右端に存在するエンピツマークをクリックし、編集モードに移行する。

f:id:yoshitaku_jp:20201022075127p:plain

手動設定を追記する。キャプチャの画像はエディターを拡大したものになる。12 行目 13 行目に追記している。追記したら「Start commit」をクリックする。コミットメッセージを入力する画面が表示されるので、そのまま「Commit change」をクリックする。

f:id:yoshitaku_jp:20201022075145p:plain

# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the main branch
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]
+  workflow_dispatch:
+    branches: [ main ]

再び「Actions」タブに移動する。先ほどとは違い、画面上に手動実行できるボタンが表示されている。 「Run workflow」をクリックすると、吹き出しが表示され、緑色の「Run workflow」をクリックすると「GitHub Actions」が実行できる。 今回は吹き出しの中に、ブランチの選択と緑色の「Run workflow」しか表示されていないが、手動実行する際に入力値を送る設定をいれると用途の幅が広がる。

f:id:yoshitaku_jp:20201022075202p:plain

画面での差分確認

f:id:yoshitaku_jp:20201022075220p:plain

おわりに

今回はGitHub Actionsを手動で実行する方法を確認した。 すぐに設定して使うことができるが、まだまだ知らない人も多そうなので参考になれば!