メむンコンテンツぞスキップ

note版_AIで䞋駄を履いおなんかすごそうなゲヌムやらツヌルを䜜るのではなく、たずは再孊習も兌ねお身の䞈に合った開発から始めた話_3



    前回↑たでは、Zenn向けの蚘事自動敎圢ツヌルずしお、

    H2の敎圢
    +
    連続する空行の倉換
    +
    匕甚ブロックの倉換
    +
    実Markdownを䜿ったpytest
    

    ずいうずころたで䜜った。


    今回はツヌルそのものぞ機胜を远加するのではなく、

    GitHubぞpushする
    ↓
    pytestが自動で実行される
    ↓
    結果がGitHub䞊で分かる
    

    ずいう状態を䜜るこずにした。


    目暙はかなり小さく、

    GitHubにコヌドを送っただけで、pytestが勝手に緑になるずころたで䜜れるか

    の、ここたで。


    実際に䜜ったものはここに眮いおいる。




    1. 今回圢にしたかったもの



    䜜りたかったのは、GitHub Actionsを䜿った最小限のCI。

    やりたいこず自䜓は単玔で、

    push
    ↓
    GitHub Actions起動
    ↓
    Pythonを甚意
    ↓
    必芁なパッケヌゞを入れる
    ↓
    pytest
    

    だけ。


    Dockerやデプロむをやりたいわけではない。

    耇雑なWorkflowを組みたいわけでもない。


    たずは、

    手元で毎回pytestを打たなくおも、pushしたコヌドのテスト結果がGitHub䞊で分かる

    状態を䜜るこずにした。



    2. たずは、芚えおいる範囲でWorkflowを曞いおみた



    最初は雛圢を䞀床芋たあず、
    できるだけ思い出しながら曞いおみた。

    最初に曞いたものはこんな感じだった。

    name: run-pytest
    
    on: push
    
    jobs:
    
    uses: ubuntu-latest
    
    steps:
    
    name: Checkout repo
    uses: actions/checkout@7
    
    steps:
    
    name: Set up python
    uses: actions/python-setup@7
    
    steps:
    
    name: install requirements
    run: pip install requirments.txt
    
    steps:
    
    name: run pytest
    run: python3 -m pytest
    

    ...圓然、色々おかしい。


    jobsの䞋にはjobを定矩する必芁があるし、

    runs-on:
    

    も必芁。

    stepsも、䞀぀ず぀䜕床も曞くものではない。

    Action名も、

    actions/python-setup
    

    ではなく、

    actions/setup-python
    

    だった。


    正解サンプルを芋ながら照らし合わせお、
    少しず぀構造を盎しおいった。



    3. ubuntu 26ず曞いたら、氞遠に埅ち始めた



    途䞭で、こんなWorkflowになった。

    jobs:
      test:
        runs-on: ubuntu 26
    

    これをpushしおみるず、

    Requested labels: ubuntu 26
    
    Waiting for a runner to pick up this job...
    

    ずいう状態から進たなくなった。


    しばらく埅っおみたが始たる様子がないので、
    䞀床手動で䞭断。

    最終的には、

    runs-on: ubuntu-latest
    

    ぞ倉曎した。


    ここで、

    runs-on
    → Workflowを実行する環境を指定するもの
    

    ずいう意味が少し具䜓的になった。


    適圓なUbuntuのバヌゞョン名を曞けばいいわけではなく、

    GitHub Actions偎が䜿えるrunnerを指定する必芁がある。



    4. 次はpip installで二回転んだ



    runnerが動くようになったあず、
    今床は䟝存パッケヌゞのむンストヌルで倱敗した。


    たず単玔に、

    requirments.txt
    

    ずスペルを間違えた。


    そしおこれを盎したあずも、

    pip install requirements.txt
    

    ずしおいたため、再び倱敗。


    ログを芋るず、

    Could not find a version that satisfies the requirement requirements.txt
    

    ず出おいた。


    さらに、

    You are attempting to install a package literally named "requirements.txt"
    

    ずいうヒントも衚瀺された。


    ぀たりこの曞き方では、

    requirements.txtずいう名前のパッケヌゞをむンストヌルする

    ずいう意味になっおしたっおいた。


    必芁だったのは、

    pip install -r requirements.txt
    

    だった。


    最終的には、䜿甚するPythonも明確になるように、

    python -m pip install -r requirements.txt
    

    ぞ倉曎した。



    5. 最小のWorkflowが通った



    最終的に、Workflowはこうなった。

    name: run-pytest
    
    on: push
    
    permissions:
      contents: read
    
    jobs:
      test:
        runs-on: ubuntu-latest
    
        steps:
          - name: Checkout repo
            uses: actions/checkout@v7
    
          - name: Set up python
            uses: actions/setup-python@v7
            with:
              python-version: "3.14"
    
          - name: Install requirements
            run: python -m pip install -r requirements.txt
    
          - name: Run pytest
            run: python3 -m pytest -v
    

    やっおいるこずを䞊べるず、

    リポゞトリの䞭身を取埗
    ↓
    Python 3.14を甚意
    ↓
    requirements.txtから䟝存関係を入れる
    ↓
    pytestを実行
    

    だけ。


    これをpushしたずころ、
    䞀通りのstepが通り、

    pytestも緑になった。

    これで最初に眮いおいた、

    GitHubにコヌドを送っただけで、pytestが勝手に緑になる

    ずいう状態たでは䜜れた。



    6. せっかくなので、わざずpytestを壊しおみた



    ただ、

    緑になった
    

    だけでは、

    GitHub Actionsがテスト倱敗をどう扱うのかをただ芋おいない。


    そこで䞀぀、
    必ず倱敗するテストを远加しおみた。

    元の凊理では、

    formatted_text = ["foo", "bar", "hoge"]
    

    を保存するず、

    ファむルから読み蟌んだ倀は、

    "foo\nbar\nhoge"
    

    ずいう文字列になる。


    そこをわざず、

    assert target_path.read_text(encoding="utf-8") == formatted_text
    

    ずしお、

    文字列ずリストを比范するテストを远加した。

    圓然倱敗する。


    pushするず、GitHub Actions偎でも、

    9 passed
    1 failed
    

    ずなり、

    Error: Process completed with exit code 1.
    

    でRun pytestが赀くなった。


    そのテストをコメントアりトしおもう䞀床pushするず、

    今床は再び緑になった。

    🟢
    ↓
    わざず壊す
    ↓
    🔎
    ↓
    元ぞ戻す
    ↓
    🟢
    

    たで䞀通り確認できた。



    7. GitHub Actionsがpytestを理解しおいるわけではなかった



    今回の挙動を敎理するず、

    GitHub Actionsが、

    pytestのテストが1個倱敗した
    

    ずいう内容そのものを理解しおいるわけではない。


    Workflowから、

    python3 -m pytest -v
    

    ずいうコマンドを実行する。


    pytestがテスト倱敗を怜知しお、

    exit code 1
    

    で終了する。

    それを受け取ったGitHub Actionsが、

    このstepは倱敗
    ↓
    jobも倱敗
    ↓
    èµ€
    

    ず刀定する。


    逆にpytestがすべお通れば、

    exit code 0
    ↓
    step成功
    ↓
    job成功
    ↓
    緑
    

    になる。


    最初は、

    GitHub Actions
    → pytestなどの䜕らかのテストを自動でやっおくれるもの
    

    くらいの認識だった。


    今回実際に動かしおみおわかったのは、

    「新しくたっさらな環境を立おお、
    そこに䜜ったものを配眮しお、
    テストする」

    ぀たり

    GitHub Actions
    → 別の環境を甚意しお
    → 指定したコマンドを順番に実行しお
    → その成功・倱敗を管理するもの
    

    ず捉えた方が分かりやすそうだった。



    8. 今回の倱敗は、党郚違う堎所で起きおいた



    今回だけでも、いく぀か違う皮類の倱敗があった。

    ubuntu 26
    ↓
    実行するrunnerが決たらず埅機
    
    pip install requirements.txt
    ↓
    䟝存関係のむンストヌルで倱敗
    
    pytestに倱敗するテストを远加
    ↓
    pytestがexit code 1を返しお倱敗
    


    党郚画面䞊では最終的に「赀」になる。

    ただ、

    どこたで成功しお、どのstepで止たったのか

    を芋るず原因は党然違う。


    今回、

    Checkout repo       ✓
    Set up python       ✓
    Install requirements ✓
    Run pytest          ✕
    

    ずいう状態を実際に芋られたこずで、

    「CIが倱敗した」

    だけではなく、

    pytestを実行するずころたでは正垞に到達しお、そのpytestが倱敗した

    ず切り分けられるこずも分かった。



    9. 今日できたもの



    今回の終了時点では、

    • GitHub Actions甚のWorkflow

    • pushをきっかけにした自動実行

    • Ubuntu runner䞊での実行

    • Python 3.14のセットアップ

    • requirements.txtからの䟝存関係むンストヌル

    • pytestの自動実行

    • pytest成功時の緑

    • pytest倱敗時の赀

    • Actions䞊でのpytest倱敗ログ確認

    たでを実際に確認できた。


    蚘事敎圢ツヌルそのものの機胜は、
    今回は䞀぀も増えおいない。

    ただ、

    自分のPCでpytestを実行する
    

    だけだった状態から、

    コヌドをGitHubぞ送る
    ↓
    別の環境でもpytestが実行される
    ↓
    壊れおいれば赀で分かる
    

    ずいうずころたでは進んだ。



    10. 終わりに



    今回やりたかったのは、
    GitHub Actionsを詳しく勉匷するこずではなかった。

    最初に必芁だったのは、

    pushしたらpytestが動く

    ずいう䞀番小さいずころ。


    実際には、

    runnerの指定を間違える
    ↓
    requirements.txtのスペルを間違える
    ↓
    -rを付け忘れる
    ↓
    ようやく緑になる
    ↓
    わざずpytestを壊しお赀にする
    ↓
    元ぞ戻しお再び緑にする
    

    ずいう流れになった。


    最初から正しいWorkflowを貌り付けお終わるよりは、

    どこで止たるのか
    ↓
    ログには䜕ず出るのか
    ↓
    盎すず次のstepぞ進むのか
    

    を䞀぀ず぀芋られた。


    前回たでは、

    コヌドが期埅通り動くかをpytestで固定する

    ずころたでだった。

    今回はそこから少し進んで、

    そのpytest自䜓を、自分のPC以倖でも自動的に走らせる

    ずころたで来た。


    ただ最小構成ではある。

    ただ、ずりあえず今は、

    GitHubぞpushするず、pytestが勝手に結果を返しおくれる。

    たずはそれで十分な気がしおいる。

     
     
    Thinking Git - Think, git. 䞍成ならず者よ、考えよ。

    あなたぞのおすすめ