GitHub

https://qiita.com/aoirint/items/09ea153751a65bf4876f#github-release%E4%BD%9C%E6%88%90%E6%99%82%E3%81%ABpypi%E3%81%AB%E3%82%A2%E3%83%83%E3%83%97%E3%83%AD%E3%83%BC%E3%83%89 上の記事のWorkflowテンプレートをちょっと改良した。 GitHub Release作成時にリリースタグをパッケージバージョンにしてpush 構成 mypackage/__init__.pyに以下のように開発用のバージョン情報を記述する。 リリース時にGithub Actionsでリリースタグに置換してからPyPIにpushする。 __VERSION__ = '0.0.0' GitHub Secrets PYPI_API_TOKEN GitHub Workflow .github/workflows/pypi.yml name: Publish a package to PyPI on: release: types: - created env: VERSION: ${{ github.event.release.tag_name != '' && github.event.release.tag_name || '0.0.0' }} jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: python-version: 3.x - name: Install Dependencies run: | pip3 install -r requirements.txt pip3 install wheel - name: Replace version run: | sed -i "s/__VERSION__ = '0.0.0'/__VERSION__ = '${{ env.VERSION }}'/" mypackage/__init__.py - name: Build Package run: python3 setup.py sdist bdist_wheel - name: Publish to PyPI uses: pypa/gh-action-pypi-publish@release/v1 with: user: __token__ password: ${{ secrets.PYPI_API_TOKEN }}

https://blog.aoirint.com/entry/2021/github_actions_docker_io_token/ 上の記事のWorkflowテンプレートをちょっと改良した。 Docker Hub以外のDockerレジストリに対応 GitHub Release作成時にリリースタグをイメージタグにしてpush レジストリURL Docker Hub: docker.io GitHub Container Registry: ghcr.io GitLab Container Registry: registry.gitlab.com GitHub Secrets DOCKER_USERNAME DOCKER_TOKEN GitHub Workflow .github/workflows/docker.yml https://github.com/docker/login-action https://github.com/docker/build-push-action name: Push to Docker registry on: push: branches: - main release: types: - created env: IMAGE_NAME: docker.io/username/imagename IMAGE_TAG: ${{ github.event.release.tag_name != '' && github.event.release.tag_name || 'latest' }} jobs: push: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Setup Docker Buildx id: buildx uses: docker/setup-buildx-action@v2 - name: Login to Docker Registry uses: docker/login-action@v2 with: registry: docker.io username: ${{ secrets.DOCKER_USERNAME }} password: ${{ secrets.DOCKER_TOKEN }} - name: Build and Deploy Docker image uses: docker/build-push-action@v3 env: IMAGE_NAME_AND_TAG: ${{ format('{0}:{1}', env.IMAGE_NAME, env.IMAGE_TAG) }} with: context: . builder: ${{ steps.buildx.outputs.name }} file: ./Dockerfile push: true tags: ${{ env.IMAGE_NAME_AND_TAG }} cache-from: type=registry,ref=${{ env.IMAGE_NAME_AND_TAG }}-buildcache cache-to: type=registry,ref=${{ env.IMAGE_NAME_AND_TAG }}-buildcache,mode=max

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

GitHubがパスワードによるGitアクセスを無効化する（正確にはパーソナルアクセストークン認証を必須化する、だが現状SSH認証は残る）旨のアナウンスをした（Token authentication requirements for Git operations - The GitHub Blog）。 これまで、コマンドラインGit操作のためのGitHubの認証にはパスワード認証（HTTPS Basic認証）を使っていた。 一応、リポジトリを操作するたびにパスワードを入力するのは面倒なので、 cacheは有効化していた。（git config --global credential.helper cache）。 パスワード認証は、持ち出せないPCやVPS、モバイル端末や新しいPCから一時的にリポジトリにアクセスする必要があるときに便利だった。 もちろん、キーロガーやgitコマンドなどシステムがハックされている可能性を考えると望ましくないことはわかっていたが..。 以前はSSH認証を使っていた時期もあったが、ブラウザ上での鍵の登録削除操作が必要でこういった一時的な認証には向かない（この記事ではこの問題は解決しない。都度PATを用意するか、平文保存するか、あるいは手元で認証情報を持つ必要のない自動デプロイを採用することになるかもしれない）。 また、同じGitホスティングサービスに複数アカウントを作っているとき、デバイス数×アカウント数と大量に鍵を管理する必要が出てくる（この記事ではこの問題も解決しない）。 自分の認識として、GitHubのGit操作をする認証にはパスワード認証（HTTPS Basic認証）、SSH認証、パーソナルアクセストークンがある（GitHub ActionsのトークンやOAuthなどは除く）。 SSH認証を使っていなかった理由は先に述べた問題（一時的なアクセス・大量の鍵管理）のほかに、プロキシがある。 自分の環境では、ネットワーク/場所が変わるたびにプロキシ設定を切り替える必要があり、 HTTPS認証の場合、毎回git config --global http.proxyあるいはgit config --global --unset http.proxyを打つことになっている（あるいはシェルスクリプト。globalなのはリポジトリ別に設定を残さないためとcloneができないから）。 ここでSSHを使うとHTTPプロキシ経由で通信するためのProxyCommandを設定することになるが、これがやっかいである。 まず、OSごとにプロキシコマンドが異なる。connect -H（Windows）、ncat --proxy-type http --proxy（macOS）、nc -X connect -x（Linux）とそれぞれのOS用の設定を用意することになる。 また、プロキシのON/OFF自体については、ふつうにsshでつなぐときは、ワイルドカード設定を使って接続先名でプロキシを切り替えるようにしているのだが、 Gitの場合は接続先名を変えるためにgit remote set-urlする必要があり、これにはリポジトリのパスを記憶して頻繁に入力する必要が出てきてしまう。今のところそのような認識であるので、パーソナルアクセストークンを使った認証に切り替えていく。 パーソナルアクセストークン（PAT）は、パスワードの代わりに利用可能な認証情報で、権限を絞ったトークンを生成できる。GitHub Package Registryを利用するときに使っていて（docker login docker.pkg.github.com。パスワード認証不可。現在GitHubのDockerレジストリはpull認証不要のGitHub Container Registry ghcr.io に置き換えられる予定でパブリックベータ中）、好印象を持っていた（PyPIやDocker Hubでもトークン認証が便利）。また、GitHubはSSH認証よりもHTTPS認証を推奨している。PATの設定箇所は若干わかりにくいが、Settings > Developer settings > Personal access tokensから設定できる。 主要機の切り替えにあたって、トークンを毎回入力するわけにはいかないので、入力されたパスワード（トークン）を認証情報マネージャを使って永続化する設定をする。Windows（Git for Windows）、macOSでは自動で設定されるように思うが、Ubuntuでは手動設定することになる。 libgnome-keyringのgit-credential-gnome-keyringというのがあるが、libgnome-keyringが非推奨になっている（linux - Error when using Git credential helper with gnome-keyring as Sudo - Stack Overflow、[libgnome-keyring] Deprecate libgnome-keyring. Use libsecret instead）ようなのでlibsecretを使う（裏側では同じgnome-keyringが動いているようだが）。 どちらもほぼ手順は同じだが、開発用パッケージからソースコードを取得したあと、手動でmakeするという謎手順がある（#パッケージマネージャとは）。これで一応保存時の暗号化（復元可能）は施された状態で永続化できる。 ...

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 }}

概要 新しく静的サイトジェネレータでブログ環境を整備した。 細かい使い方には触れないが、構成を書いておく。 静的サイトジェネレータと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のところをコピーして増やせばコマンドを増やすことができる。 ...

URL：USERNAME.github.io リポジトリ：USERNAME.github.io ブランチ：master 通常のGitHub Pagesと違ってmasterブランチが使われる https://qiita.com/ryokosuge/items/f929821ba5ae9ba2c32b