山pの楽しいお勉強生活

勉強の成果を垂れ流していきます

GitHub ActionsでGitHub Package RegistryにDocker Imageをpushする

前の記事では手動でGithub Package RegistryにDocker Imageをpushしましたが、実際にはそんなの手でやってられません。こういう事はCIにやらせましょう。

GitHub Actions及びGitHub Package Registryは正式公開されたばかりだからか、情報が少なかったのでメモ。
特に docker login については個人ユーザに紐づく方法しかみつからないので、結構ハマる方がいるはずです。

結論

以下のようにログインユーザ及びパスワード(トークン)を指定して、docker login すればOK

    - name: Push to Github Package Registry
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u ${GITHUB_ACTOR} -p ${GITHUB_TOKEN}
        docker tag original docker.pkg.github.com/yamap55/python_dev_env/original:latest
        docker push docker.pkg.github.com/yamap55/python_dev_env/original:latest

設定ファイル全て

name: Build Dockerfile and Push Github Package Registry
on:
  push:
    branches:
      - develop

jobs:
  build-and-push:
    runs-on: ubuntu-18.04
    timeout-minutes: 300
    steps:
    - uses: actions/checkout@v1

    - name: Build Image
      run: |
        cd docker/ && docker build -f Dockerfile_original.dockerfile -t original .

    - name: Push to Github Package Registry
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        docker login docker.pkg.github.com -u ${GITHUB_ACTOR} -p ${GITHUB_TOKEN}
        docker tag original docker.pkg.github.com/yamap55/python_dev_env/original:latest
        docker push docker.pkg.github.com/yamap55/python_dev_env/original:latest

他のファイル構成などは以下を参照
https://github.com/yamap55/python_dev_env

参考

GitHub Package RegistryにDocker imageを格納する

公式のドキュメントでうまくいかなかったものの、検索しても記事がみつからなかったのでメモ。 (GitHub Actionsでのサンプルはいくつもあったが、手動でのサンプルがみつからなかった。)

※わかってる人なら特に記事にする事でもないので、サンプルがなかっただけという話。

GitHub Package Registryとは

この記事見ていてわからない人はいないかもですが一応記載。

GitHub Packages is a software package hosting service that allows you to host your software packages privately or publicly and use packages as dependencies in your projects.

https://help.github.com/en/github/managing-packages-with-github-packages/about-github-packages

GitHub Package Registryとはソフトウェアパッケージのホスティングサービスです。 2019年5月にβがはじまり、11/13?に正式版になりました。

2019/12/23現在ではnpm,gem,mvn,gradle,docker,dotcetをサポートしています。(詳細は公式ページ参照

手順

基本的に公式ドキュメント通りです。

  1. トークンの作成
  2. docker login
    • docker login docker.pkg.github.com -u USERNAME -p TOKEN
    • 例 : docker login docker.pkg.github.com -u yamap55 -p 8982f91d09e95dda471d67ff9f68408eed9adc8c
  3. docker build
    • docker build -t docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION PATH
    • 例 : docker build -t docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0 .
  4. docker push
    • docker push docker.pkg.github.com/OWNER/REPOSITORY/IMAGE_NAME:VERSION
    • 例 : docker push docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0
  5. 確認

imageを使用する

  • docker pull
    • docker pull docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0
  • dockerfile
    • FROM docker.pkg.github.com/yamap55/python_dev_env/dev-python:1.0

参考

Windowsで今まで動いていたdocker runが失敗する

あまりわかってないけど、解決した & 日本語の情報がみつからなかったのでメモ

エラーメッセージ

SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories.
Run: docker run -a STDOUT -a STDERR --mount type=bind,source=c:/work/github/python_dev_env,target=/workspaces/python_dev_env,consistency=consistent -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=c:\work\github\python_dev_env -u vscode --entrypoint /bin/sh vsc-python_dev_env-78a41ebd12f13d8077d12b38bafdcbc8 -c echo Container started ;  while sleep 1; do :; done
C:\Program Files\Docker\Docker\Resources\bin\docker.exe: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /host_mnt/c/work/github/python_dev_env.
See 'C:\Program Files\Docker\Docker\Resources\bin\docker.exe run --help'.
Failed: Starting the development container
Command failed: C:\Program Files\Docker\Docker\Resources\bin\docker.exe run -a STDOUT -a STDERR --mount type=bind,source=c:/work/github/python_dev_env,target=/workspaces/python_dev_env,consistency=consistent -l vsch.quality=stable -l vsch.remote.devPort=0 -l vsch.local.folder=c:\work\github\python_dev_env -u vscode --entrypoint /bin/sh vsc-python_dev_env-78a41ebd12f13d8077d12b38bafdcbc8 -c echo Container started ;  while sleep 1; do :; done

※1つ目のWARNINGは関係ないかも

対応方法

  • Docker desktop起動して、パスワード再入力
  • Shared Drivesを一旦解除して、再度設定

原因

  • パスワード変更

参考

GitHubのマージ済のブランチをGitHub Actionsで定期的に削除する

追記(2019/10/28)

GitHubリポジトリ設定にマージ完了後にブランチを削除する設定がありました。(2019/07/31に追加されたらしいです。)よって、GitHub Actionsなんて使用せずにリポジトリの設定を変更しましょう!

help.github.com


はじめに

プルリク後のブランチ削除忘れってありますよね。気づいたらマージ済みのブランチが山のようにあったり。

で、今までは「GitHubのマージ済のブランチをCircleCIで定期的に削除する」を参考にCircleCIを使用していたのですが、GitHub Actionsでできるのでは?と思ったので調査したメモです。

面倒な設定やGitHub連携なども不要なので、プルリクを使うリポジトリには必ず入れる位でも良いかも?

一言で

branch-cleanup-action」を見てください

手順とか

  • GitHub Actionsを有効にする
  • リポジトリのメニューに「Actions」が表示されていることを確認
  • Actions → Set up a workflow yourselftをクリック
    • 既にGitHub Actionsで何か動いている場合には「Actions → New workflow → Set up a workflow yourselft」
  • ファイル名を「pull_request-branch_cleanup.yml」に変更(main.ymlでも問題はないが。。。)
  • コードを以下のように設定
on:
  pull_request:
    types: [closed]
name: Branch Cleanup
jobs:
  build:
    name: branch-cleanup-action
    runs-on: ubuntu-latest
    steps:
    - name: branch-cleanup
      uses: jessfraz/branch-cleanup-action@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  • Start commit → コミットメッセージ入力 → Commit new file

※この設定自体をプルリクにしたい場合には、「 .github/workflows/pull_request-branch_cleanup.yml 」に上記の設定書いてプルリクすればよろし。

参考URL

setuptoolsがsetup.cfgを読んでくれない

現象

Pythonでsetuptoolsを使用してwheelファイルを作成しようとしたが、自動的に読んでくれるはずの「setup.cfg」を読んでくれない。

※setup.pyで「setup(name='hoge')」などと指定すると正しく動作する
※正確には、license_fileなどで存在しないファイルを指定するとエラーになるので読んでくれているが、wheelファイル作成時に使用してくれない。

結論

setuptoolsのバージョンが低い

※setuptools 30.3.0から読んでくれるようになったらしい

確認

pip list
pip list -o # 更新があるライブラリのみ

アップデート

pip install --upgrade setuptools

何故発生したか

  • setuptoolsはPythonに付随してくるので、最新版のPythonを使用すればこの事象は発生しない。
    • 意図的にバージョン下げれば発生する?(動かない気もするが。)
  • 今回はvenvでPython3.5.2を使用していたため、3.5.2に付随したsetuptoolsのバージョンが仮想環境に入り、本事象が発生した。
    • 正確にはpipに依存するsetuptoolsか?

今後の対応

最初に環境を作る際に以下のようにアップグレードを行う!

mkdir hoge
cd hoge
pyenv local 3.5.2
python -m venv .venv
.venv\Scripts\activate.bat
python -m pip install --upgrade pip setuptools

Windowsでpyenv(pyenv-win)

pyenvを使おうと思って公式見たらpyenv-win使えと書いてあった。

If you're on Windows, consider using @kirankotari's pyenv-win fork. (pyenv does not work on windows outside the Windows Subsystem for Linux)

使い方も含めてメモ

pyenvとは

  • Pythonのバージョンを切り替えるツール
    • それ以外の事をしないというのが混乱しないためのポイント。
  • ライブラリ管理的な事もできるようだが、そちらはPython公式がサポートしているvenvを使用する
    • この記事の最後に書いた。

前提

  • python(pip)がインストール済み

インストール

詳細はpyenv-winのGitHubをみてください。

  • install
pip install pyenv-win --target %USERPROFILE%/.pyenv
  • PATHに追加
    • 既存のpythonよりも前に追加する必要がある
      • 管理者権限を持っておらず、管理者権限のPATHにpythonがあるPATHが設定してあるとpyenv云々の前に使用するpythonが決まってしまう。
      • ↑この場合、打つ手はなさそう。
    • %USERPROFILE%\.pyenv\pyenv-win\bin
    • %USERPROFILE%\.pyenv\pyenv-win\shims
      • この時点だと「shims」は空
    • %USERPROFILE%/.pyenv 」は「 C:\Users\yamap_55\.pyenv 」となる。
  • 別のコマンドプロンプト起動
    • セッションを切り替えないと環境変数が有効とならないため
  • PATHが通っていることを確認
    • pyenv --version
  • 設定
    • pyenv rehash
    • バージョンが切り替わらないなど何かあったらrehash

使い方

  • インストール可能なバージョン確認
pyenv install --list
pyenv install 3.5.2
  • pythonのバージョン切り替え
pyenv local 3.5.2

どうやって切り替えている?

  • pythonが呼ばれる
  • PATHを辿る
  • shims下にpython.batを見つける
    • shimsの前にpythonがあるとpyenvは起動せず、バージョンが切り替わらない
    • shims内が空だとpyenvは起動せず、バージョンが切り替わらない
  • python.batからpyenvが呼ばれる
  • 「.python-version」から指定されたpythonのバージョンを調べ、pythonが実行される
    • ここはコード見ていないので想定。

メモとか

  • pyenvがある状態での仮想環境作成
mkdir project
cd project
pyenv install 3.5.2
pyenv local 3.5.2
python -m venv .venv
.venv\Scripts\activate

JDK 1.8.0_221を管理者権限がないWindowsにインストールする

今時Java8?管理者権限がないとかどういうこと?とか色々言いたい事はありますが、やらなきゃいけない事もあるのです。

同内容の記事がWeb上で見受けられますが、落とし穴いっぱいなので改めて記事にしています。

手順

  • jdkを取得
  • 7zipインストール
    • 管理者権限が必要www(矛盾)
    • ↓の注意点に記載しています。
  • jdk-8u221-windows-x64.exe」を解凍
    • ↓「x」は「-」は付けない、「-o」の後はスペースなし
    • C:\work\20190911\7zip\7z.exe x C:\work\20190911\a\jdk-8u221-windows-x64.exe -oC:\work\20190911\a\o
  • 111ファイルからtool.zip(JDKの実体)を取得
    • バージョンによってはexe展開後にtool.zipが存在することもあるようです。
    • 111は cab ファイルなので展開が可能。
    • extrac32 C:\work\20190911\a\o\.rsrc\1033\JAVA_CAB10\111
  • tool.zipを展開
    • zipの展開方法は省略
  • jarが.packファイルとなっているらしいので、jarに変換
    • cd C:\work\20190911\tools
    • for /r %x in (*.pack) do .\bin\unpack200 -r "%x" "%~dx%~px%~nx.jar"
  • 確認
    • C:\work\20190911\tools\bin\java -version
  • toolsフォルダを任意のPATHに移動
    • move tools C:\tools\java\jdk-8u2212

※PATHやJAVA_HOMEの設定は省略(既にJavaがインストールされており、システム環境変数のPATHに設定されていると、ユーザ環境変数では上書きする事はできないので注意)

注意点

  • 7zipがインストールできない
  • jdkのexeを展開後に111が展開できない
    • 111はzipではなく cab です。
      • extrac32を利用して展開が可能です。
    • よく見るとディレクトリ名に書いてありますが、参考サイトをみるとzipとなっている所もあります。。。
  • jdkのexeを解凍後にtool.zipがない
    • tool.zipがあるかどうかはjdkのバージョンによって異なるようです。

参考