[2022/03]GithubActionsでやったこと全部[まとめ]

Table of Content

GithubActionsで学んだ事をまとめておきます。
Zennのブックにする案もあったんですが、まずはこちらにまとめておきます。

前提記事

ここでは、私が実際に運用している方法について解説していきます。

解説の前に、hubコマンド(Github)について

GAからプルリクを出しているコマンドです。

https://github.com/github/hub

まずは公式を参照してください。
本稿はほぼ焼き増し、やってみた記事です。

書いていない注意点(運用とか)

hubコマンドで色々やろうとすると、ウッカリ忘れやすいgitのルールを再確認しておきます。

自分でpushしたものを自分に向けてPRを出す事はできない

PRを出すならBOTアカウントなどを使いpushしないと、自分を対象にしたRPは作れません。
自分のアカウントでpushして、自分にレビューを求めるのはおかしいよね?と考えればわかる話ですが、別のアカウントを用意する必要があり、しかしGithubで複数のアカウントを持つ事は許されません。
BOTアカウントのユーザー名とメールアドレスを探して、それっぽいやつを巻き込む他ないです。

こういう事を言うとアフィリエイターの汚いところが出てきて嫌なんですが、要は別の電話番号を用意できればいいので、名前は適当にやって電話を使い分ければ一人で完結できてしまいます。
個人で運用している場合でもmainブランチをプロテクトを掛けたい場合があるので、自分に自分でPRを出したい時に活用してみてください。

devブランチを作った後に、ブランチを削除しない(PRをmergeする前など)状態でdevブランチを作れない

説明のためにdevブランチと言いましたが、名前はなんでもいいです。
mergeする前にまたPRを出す可能性がある運用をする場合、PRを出すヘッドブランチ名はユニークであるべきです。
理屈を考えればわかりますが、コンフリクトを起こしそうですよね。
コンフリクトの解消はユーザー自身の手で行う必要があります。

これを踏まえて、実例

本題です。

mainリポジトリにプロテクトルールを掛けていた場合に別ブランチを作成してPRを出す、ついでにアサインする

個人開発でも結構需要がありますが、結構面倒くさいのでプロテクトルールを掛けないリポジトリを作ってそっちでmergeした方がマシかもしれません。
チーム開発だと絶大な威力を発揮します。

ポイントは

- name: 変数設定
  id: define

の部分です。
このスクリプトは、本来他のCIでやりたい事に影響しない範囲で使い回すことを前提にしているので、運用時はオレオレフレームワークとして強制します。
フレームワークを使う=運用ルールを強制することになるため、むやみやたらにプロテクトルールを掛けるぐらいなら、CI専用の別ブランチでpushを自動化した方がマシかもしれません。
PRをmergeするだけの作業ですが、思っている以上に運用負荷が高くなるはずです。
すべてのブランチ・リポジトリに適用するのはあまりにも危険です。
個人開発ならやらない方がマシかもしれません。

# ここで何かしらの処理をする
〜
# ここまでに、何かしらの処理をする

の間に本来制御したいスクリプトを格納してください。
なお、pushはフレームワークに組み込まれているので、ファイルの変更処理だけすれば完結できます。

README.mdをwebから編集した時にdiffが見れないので、README.txtに書いてmdファイルに変換する

changelog_aggregation.yml

まずは簡単なものから。
複雑度は上がりましたが、大体はスクリプト内コメントに埋め込んだ通りです。
上記のifとか変数の渡し方をなんとなく理解できれば、難しいことはやってないです。

これの https://gist.github.com/shimajima-eiji/c67cb398efe29f76aabf59f79331959c#file-txt2md-yml-L32-L41 です。
執筆時点だと32〜41行目、

      # ここで何かしらの処理をする
      - name: copy txt -> md
        run: |
          # 前回の更新でREADME.txtを変更していた場合に実施。削除時は動かないようにgrepでフィルタしている
          # 奇しくも、READMEには A, M, Dのすべてが揃ってしまっているので、行頭を完全一致にする必要があった。
          if [ -n "$(git log -1 – oneline – name-status | grep -e '^A' -e '^M' | grep 'README.txt')"  ]
          then
            cp README.txt README.md
          fi
      # ここまでに、何かしらの処理をする

の部分が、本スクリプトで実装した範囲です。
git clonegit pushprotect_main.ymlのフレームワーク部分で実施しているので、ここでは考える必要はありません。

リポジトリをcloneする

テンプレートを使うとデフォルトにあるuses: actions/checkout@v2が何者か、という話です。
色々解説しようと思ったんですが、こっちみた方が早かったです。

GAでcloneしてpushするコマンド

pythonのバージョン管理も上記に移動しています。

CHANGELOG.mdを自動生成する

まずCHANGELOGをどうやって作るか、というのが焦点です。
どういった情報を求めているのか、というのがポイントになります。
決まったフォーマットもないですし、なんのために作るのかも分かりません。

ある程度いい感じにやってくれるジェネレーターを探せば見つかるので、そちらを色々ガチャガチャいじって、気に入ったものを使ってみてください。
私の場合、github-changesを採用しました。
タグで分けないと真価を発揮できないので、これから情報整備にかかります。

豆知識:色々なアカウントでpushしてしまった履歴を統一させたい

開発中にやらかしました、
色々な端末でガチャガチャいじっていたので、メールアドレスは一定ながらユーザー名がGithubアカウント名だったりログインツール名だったりwordpress名だったり、色々な名前でやっていたので更新状況が行方不明になっていました。
なので、こちらを参考にして一括で名前を統一しました。
https://qiita.com/nagito25/items/2463a677e46210c6a90f

これにより、頑張って開発した結果や、記事を書いた結果が正しくコントリビューションに反映されるようになりました。

シェアする