GitHub Actions Tips

mainブランチにpushされたときに実行 on: push: branches: - main Releaseが作成されたときに実行 on: release: types: - created 三項演算子的なやつ ${{ env.VARIABLE }}の形式 ${{ condition && 'true_value' || 'false_value' }} ${{ github.event.release.tag_name != '' && github.event.release.tag_name || 'latest' }} 注意: true_valueがboolean的にfalseと解釈される値(空文字列)であってはならない。その場合、true_valueとfalse_valueを交換してconditionを反転させる。 文字列が空文字列の場合は空文字列、そうでなければ加工した文字列を変数に格納する、という方法で文字列を少しずつ加工していくと複雑な文字列が作りやすい 文字列の結合 フォーマット関数を使う :区切りで結合: ${{ format('{0}:{1}', env.VARIABLE_A, env.VARIABLE_B) }} 便利なAction 大抵の場合、READMEに用例が載っているのでコピペして使う 新しい機能、細かい機能、細かい挙動は載っていなかったりする。そのときはコードを読む Dockerイメージのビルド・プッシュ: https://github.com/docker/build-push-action Docker Hubにpushする場合、アカウントを作成し、アクセストークンを取得しておく(無料プランでは1つしか作成できないので注意) https://hub.docker.com/settings/security GitHub Pagesの公開: https://github.com/peaceiris/actions-gh-pages 同一リポジトリにpushする場合、トークンなどを特別に設定する必要はない(何もしなくても、自動でgithub_tokenという変数にトークンが格納されている) 別リポジトリにpushする場合、Personal Access Tokenはリポジトリのスコープを切れないので、SSH鍵を生成してDeploy keysに登録するのがおすすめ

2022年5月21日 · aoirint

GitHub Actions, DockerイメージをビルドしてDocker Hubにpushする(アクセストークン)

Docker Hubにアクセストークンを追加する。 https://hub.docker.com/settings/security リポジトリのSettingsから、Secretsを開き、New repository secretから DOCKER_USERNAME、DOCKER_PASSWORDを追加する。 DOCKER_USERNAMEはDocker Hub上のユーザ名、 DOCKER_PASSWORDはアクセストークンを設定する。 以下のファイルをリポジトリに追加する(ファイル名docker.ymlは変更可)。 mainブランチにgit pushされたとき、Dockerイメージのビルドが走り、イメージがDocker Hubにdocker pushされる。 .github/workflows/docker.yml name: Push to Docker registry on: push: branches: - main jobs: push: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Login to Docker Hub uses: actions-hub/docker/login@master env: DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }} DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }} DOCKER_REGISTRY_URL: docker.io - name: Build :latest if: success() run: docker build -t username/imagename:latest . - name: Deploy :latest if: success() uses: actions-hub/docker@master with: args: push username/imagename:latest

2021年7月10日 · aoirint

GitHub Actions, ビルド結果を別ブランチにpushする

GitHub Actions実行中に生成したbuildディレクトリの内容を別ブランチにpushする。 github:s0/git-publish-subdir-action name: Build on: push: branches: - master jobs: deploy: name: Build runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Build run: python3 app/main.py # run: | # python3 app/cmd1.py # python3 app/cmd2.py # https://github.com/s0/git-publish-subdir-action - name: Push to build branch uses: s0/git-publish-subdir-action@master env: REPO: self BRANCH: build FOLDER: build GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

2020年9月27日 · aoirint

静的サイトジェネレータMiyadaiku + GitHub Actions + GitHub Pagesでブログを作る

概要 新しく静的サイトジェネレータでブログ環境を整備した。 細かい使い方には触れないが、構成を書いておく。 静的サイトジェネレータとCI/CD 静的サイトジェネレータ 静的サイトジェネレータというのはSphinx(Python製)とかJekyll(Ruby製、GitHub Pages標準らしい)とかHugo(Go製)みたいなやつで、 MarkdownだとかreStructuredTextだとかのファイル群からHTMLを生成するツール。 Sphinx Jekyll Hugo Miyadaiku MiyadaikuはPython製の静的サイトジェネレータ。 Flaskで使うテンプレートエンジンのJinja2が使えることが特徴みたい。Jinja2はDjangoのテンプレートエンジンに似ている。 テンプレート上でどんな変数が使えるかはMiyadaikuの領域なので、ドキュメント(とサンプルテンプレート、ソースコード)を見ていくしかないかも。 github:miyadaiku/miyadaiku pypi:miyadaiku GitHub Actions GitHub上のリポジトリに対してpushやPull Requestがなされた時に事前に指定した処理を実行することのできるGitHubの機能。 Jenkinsなどに近そう。また、GitLabにも同様の機能があったはず。 GitHubのサーバで動く仮想環境上でDockerのような使い方でテストケースの実行やリリースファイルのビルド、サーバへのデプロイ、 つまりCI(Continuos Integration、テストやビルドの自動化)/CD(Continuous Delivery、デプロイの自動化)を設定できる。 Pull Requestなどへの自動ラベル付けやSlackへの通知なんかも設定することがあるのかな。 この設定はYAMLファイルとしてGitリポジトリ内に保存しますが、秘密鍵/トークンなどの情報を参照するための機能もあるみたい。 バージョン管理システム的な点ではGitは分散型なので文書自体の分散バージョン管理はできるが、 GitHubが落ちたら解消するまで(手元にリポジトリがあっても)GitHub ActionsによるCI/CDができないのが難点な気がする。 GitHub Status 考えていること レンダリング後のHTMLファイルの分離 Markdownを書いている時に見えるところに(レンダリング後の)HTMLファイルを置きたくない。 できれば何も考えずに(Markdownで書いた)メモファイルを置くのに使っていた適当なディレクトリの上でコマンドを実行したら HTTPサーバを介して(オプションで指定したテーマなどで)いい感じにレンダリングしてくれるようなものがいい (HTMLファイル自体にファイルシステムからアクセスできる必要はない)と思っていた。 このHTMLはMarkdownファイル群とレンダリングのオプションだけでいつでも生成可能なので、 レンダリング後のファイル自体が見えなければ、後からこのファイルを何かの間違いで編集してしまって正規性(再レンダリングしても差分がない状態)が崩れてしまうことがない。 それからMarkdownファイルをGitで管理する場合、レンダリング後のファイルの差分には実質的に意味がないので、(見える)commitに含めたくない気持ちがある。 この部分は適切に.gitignoreやCI/CDを設定すれば大抵の静的サイトジェネレータで実現可能だろうと思う。 今回はGitHub Actionsを使って、GitHub上の仮想環境にリポジトリから文書を読み込んでHTMLを自動生成し、文書と履歴を共有しない別ブランチ(gh-pages)に自動でcommitされるように設定する。 GitHub Actionsを動かすには.github/workflows以下にYAMLファイルを配置する。例えばこのような感じ。GitHub Pagesへのデプロイ(gh-pagesブランチの更新)にはgithub:peaceiris/actions-gh-pagesを使っている。 # deploy.yml name: Deploy # Controls when the action will run. Triggers the workflow on push or pull request # events but only for the master branch on: push: branches: [ master ] # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" build: # The type of runner that the job will run on runs-on: ubuntu-latest # Steps represent a sequence of tasks that will be executed as part of the job steps: # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: # Version range or exact version of a Python version to use, using SemVer's version range syntax. python-version: 3.x - name: Install dependencies run: pip3 install -r requirements.txt - name: Run miyadaiku-build run: miyadaiku-build --output public . - name: Deploy uses: peaceiris/actions-gh-pages@v3 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public name、runのところをコピーして増やせばコマンドを増やすことができる。 ...

2020年9月9日 · aoirint