🦡

Git Hub Actions入門

7 min read

Github Actionsって何?

主にCI/CDを実現するためにGithubが提供している機能。
Github上の何らかのアクションに応じた動作を定義できる。

例えば「git pushした場合に自動的に環境をビルドし、実環境にデプロイする」とか「自動テストを定義しておき、定期的に環境に対して実行する」など

Githubって?

Microsoftが買収した会社。
主にGithub.comというGitホスティングサイトを運営している。

Gitって?

Gitはソースコードを管理するためのバージョン管理システム。
過去の変更や最新のコードの管理を簡単に管理できる。

CI/CDって?

CI/CD (継続的インテグレーション/継続的デリバリー) とは、アプリケーション開発に自動化を取り入れて、顧客にアプリケーションを提供する頻度を高める手法。
ソフトウェア開発にで、ビルドやテストを自動化し、短期間で品質管理を行う手法。

とりあえず、お客様に早く届けるために自動化してやってこうぜって考え方。

とりあえずやってみる

1. gitレポジトリを作成する。

とりあえず、試すためのレポジトリを作成してください


この辺は適当に作成します。
今回はAdd a README fileなどにチェックすると新しいレポジトリにファイルが追加される方法でやっています。

2. ローカルにクローンする


レポジトリ右上のCodeの部分からURLをコピーしてgit cloneします。

3. 実行ファイルを作成/実行

.github/workflows/フォルダを作成し、任意の名前のyamlを作成します。
今回はrun.yamlというファイルを作成しています。

.github/workflows/run.yaml
name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - run: echo "this is pen"

この実行ファイルは「pushが実行された場合に最新のGithubが準備したUbuntu環境でecho "this is pen"というコマンドを実行する」という内容のワークフローになります。
この変更をレポジトリに追加し、git pushを行います

git add .
git commit -m"this is pen action add"
git push

このプッシュのタイミングでワークフローが実行されます。

4. 実行の確認

実行されたことを確認するには、Githubの対象のレポジトリのActionsを参照してください。
実行された、過去のワークフローを確認する事ができます。

下記の手順で選択をすると、this is penと出力されていることがわかります。

以上がgit hubactionsの超基本利用方法です。

好きなことをやらせてみる

これでubuntuで実行可能がことが、ほとんど可能なことがわかりました。
しかし、自動化する場合に0から他の環境構築などを行うと大変です。
それを簡単にするために、githubはマーケットプレイスを用意しています。

https://github.com/marketplace?type=

ここには、すでにパッケージ化された処理を共有し、再利用する事ができます。
少しパッケージを紹介します。

checkout

多分、最もよく使うやつです。
このアクションは「レポジトリからソースコードを取得する」というアクションになります。

https://github.com/actions/checkout

下記のように利用すると、ソースコードが取得できる事がわかると思います。

.github/workflows/new.yaml
name: learn-github-actions
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - run: echo "this is pen"
      - uses: actions/checkout@v2
      - run: |
          ls -al
          cd .github/workflows/
          ls -al

- uses: actions/checkout@v2checkoutのアクションを実行して、その後lsコマンドで作業フォルダ内と.github/workflows/内を確認しています。
実行結果として下記のようになり、レポジトリのソースコードがcloneされていることが分かると思います。

docker/build-push-action

このアクションは、Dockerイメージをビルドし、自動的にdocker hubなどのイメージレポジトリサービスにPushするアクションです。

https://github.com/docker/build-push-action

zaproxy/action-baseline

このアクションはZAPという脆弱性検査ツールを実行するアクションです。

https://github.com/zaproxy/action-baseline

単純実行のみなら容易だが、ログイン処理を組み込もうとするとデスクトップソフトの設定を読み込む必要があり面倒。

steebchen/kubectl

kubernetesを操作するkubectlというCLIアプリケーションを利用するアクションです。

https://github.com/steebchen/kubectl

変数

コンテキストと環境変数

変数周りに関しては下記にまとめさせていただきました。

https://zenn.dev/hashito/articles/aef4de448f341b

Github コンテキスト

Github Actionsの実行状態によって可変するGithub コンテキストというものも利用できます。
例えばgithub.shaなどはワークフローの実行をトリガーしたコミット SHAを取得する事ができます。

https://docs.github.com/ja/actions/reference/context-and-expression-syntax-for-github-actions#contexts

シークレット

秘密鍵やパスワード、IDなど表示したくない変数を利用する場合にシークレットという機能を利用できます。

定義

定義は、Organization単位かレポジトリ単位で定義する事ができます。
それぞれのSettingからSecretに移動し、変数名と内容を設定するだけです。

Organizationで利用すればレポジトリをまたいだ共有も可能となります。

https://docs.github.com/ja/actions/reference/encrypted-secrets

利用方法

yaml上では下記のようにコンテキストの一種類として利用できます。

on: push
name: deploy
jobs:
  deploy:
    name: deploy to cluster
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@master
    - name: deploy to cluster
      uses: steebchen/kubectl@v2.0.0
      with: # defaults to latest kubectl binary version
        config: ${{ secrets.KUBE_CONFIG_DATA }}
        command: set image --record deployment/my-app container=${{ github.repository }}:${{ github.sha }}
    - name: verify deployment
      uses: steebchen/kubectl@v2.0.0
      with:
        config: ${{ secrets.KUBE_CONFIG_DATA }}
        version: v1.21.0 # specify kubectl binary version explicitly
        command: rollout status deployment/my-app

この場合は、steebchen/kubectlはkubernetesを操作するためのアクションになっていて、KUBE_CONFIG_DATAというSecretにBase64で加工した$HOME/.kube/configというkubernetesへの接続方法が記載された設定ファイルが入っています。

イベント

GithubActionsは実行されるタイミングも任意で設定できます。
yamlファイルの最初に記載されているon: pushなどと定義されている部分を変更すれば、任意のタイミングで実行する事ができます。

https://docs.github.com/ja/actions/reference/events-that-trigger-workflows

※本当にいろいろなイベントが用意されていますが、一部のイベントはメインブランチにコミットしておく必要があることを注意してください。

よく使いそうな設定

push

ブランチがpushされたタイミングで実行されます。
ブランチを別に指定することで、特定のbrunchにpushされたタイミングでアクションを実行する事ができます。

on:
  push:
    branches:
      - main

https://docs.github.com/ja/actions/reference/events-that-trigger-workflows#public

schedule

スケジューリングされたタイミングでGithub Actionを実行できます。
このタイミングはCron構文で定義する事ができ、簡単に設定する事ができます。

on:
  schedule:
    - cron:  '*/1 * * * *' #1分に1回実行

https://docs.github.com/ja/actions/reference/events-that-trigger-workflows#schedule

マニュアル実行

手動で任意のタイミングで実行したい場合、workflow_dispatchを利用します。
また、このときに実行時引数なども定義しておき、実行前に選べるようにも設定する事ができます。
実行はGithub Actionsのタグから選択することができます。

https://docs.github.com/ja/actions/reference/events-that-trigger-workflows#workflow_dispatch

外部連携

GithubAPIを利用して、外部と連携して実行する事もできるようです。
この場合、repository_dispatchというイベントを利用します。
作者は利用したことがないので紹介だけ…

https://docs.github.com/ja/actions/reference/events-that-trigger-workflows#example

価格

パブリックレポジトリの場合は無料で利用できます。
ただし、プライベートレポジトリの場合はFreeプラインの場合は2000分が上限になります。

https://docs.github.com/ja/billing/managing-billing-for-github-actions/about-billing-for-github-actions

これを回避するためにはホストランナーといわれる、外部のサーバを用意してそちらでGithub Actionsを実行する方法もあります。

検索すると下記のような記事が色々と見つかります。
<ActionsのホストランナーをEC2でやってみた>

https://dev.classmethod.jp/articles/hosted-runner-on-ec2/

Discussion

ログインするとコメントできます