Git Created: 2026/06/27 Updated: 2026/06/30

Gitea Actions入門
pushでテストとデプロイを自動化するCI/CD

Gitea Actionsの始め方を解説。act_runnerの登録、.gitea/workflowsの書き方、コミット規約チェックやテスト、SSHでの自動デプロイ、SecretsやGitHub Actionsとの違いまで実例付きで紹介します。

#デプロイ #Git #Gitea #CI/CD #Github Actions

シリーズ：Git 実践シリーズ

ソース管理ワークフロー

タグの使い方（ローカル / Gitea Web）

コミットメッセージ規約

rebase の使い方

GitHub / Gitea Actions

ここまでのシリーズで、ブランチ運用・タグ・コミット規約・rebase と、「人が手で整える」スキルを積み上げてきました。最終回では、その仕上げとして「pushしたら、あとは自動」の世界に踏み込みます。使うのは Gitea に組み込まれた CI/CD、 Gitea Actions です。

Gitea Actions は GitHub Actions とほぼ互換で、.github/workflows のYAMLをほぼそのまま使えます。しかも自前サーバーで動くため、人数が増えても料金が膨らみません。この記事では、準備から「テスト＋規約チェック」「自動デプロイ」までを一気通貫で組み立てます。

💡 前提条件

自分で運用している Gitea（または管理者権限のあるリポジトリ）があることを前提にします。Gitea のバージョンは Actions が導入された 1.19以降が必要です。デプロイ例では第1回・Bunシリーズで触れたdeploy.sh の考え方を再利用します。

Gitea Actions の全体像

まず登場人物を整理します。Gitea 本体はジョブを自分では実行しません。実際に処理を走らせるのはact_runner という別プログラムで、これを登録しておくことで初めてワークフローが動きます。

開発者
git push

Gitea
ジョブを登録

act_runner
ジョブを取得

Docker
で実行

push → Gitea がジョブを登録 → act_runner が取得し、Dockerコンテナの中で実行する

ワークフロー（何を実行するか）の定義は、リポジトリ内の.gitea/workflows/ ディレクトリに置いた YAML ファイルに書きます。.github/workflows/ も認識されるため、GitHub から移行する場合はそのままコピーしても動くことが多いです。

準備：Actionsを有効化してランナーを登録する

Step 1：インスタンスで Actions を有効化する

管理者作業（済んでいれば飛ばしてOK）

管理者作業（済んでいれば飛ばしてOK） Gitea の設定ファイルapp.ini で Actions を有効にします。新しめのインスタンスでは既に有効な場合もあります。

; Actions を有効化
[actions]
ENABLED = true

編集後は Gitea を再起動します。

Step 2：リポジトリで Actions を有効化する

リポジトリ設定

インスタンスで有効でも、各リポジトリは既定でオフです。対象リポジトリのSettings → Actions から「Enable Repository Actions」を有効にします。すると上部メニューに Actions タブが現れます。

Step 3：act_runner を登録して起動する

ランナー準備

ジョブを実行するランナーを用意します。 Gitea本体とは別マシン（または別コンテナ）で動かすのが推奨です。登録トークンはSettings → Actions → Runners （インスタンス全体なら管理画面）から取得します。Docker が動いている環境で次を実行します。

bash

# ランナーを登録（トークンは管理画面から取得した値に置き換える）
$ ./act_runner register --no-interactive \
    --instance https://gitea.example.com \
    --token <登録トークン> \
    --name my-runner \
    --labels ubuntu-latest:docker://node:20-bookworm

# 起動（以後ジョブを自動で拾って実行する）
$ ./act_runner daemon

✨ labels が runs-on の正体

登録時の--labels ubuntu-latest:docker://node:20-bookworm は、「ワークフローでruns-on: ubuntu-latest と書かれたジョブを、node:20-bookworm のDockerイメージで実行する」というマッピングです。runs-on の値とランナーのラベルが一致しないとジョブが拾われないので、ここはセットで覚えておきましょう。

⚠️ ️ instance に localhost を使わない

ジョブ用コンテナはランナーとは別のネットワークから Gitea へ接続します。そのため--instance に127.0.0.1 やlocalhost を指定すると、コンテナから Gitea に届きません。LAN内のIPか正式なドメインを指定してください。

最初のワークフローを書く

準備ができたら、リポジトリに最初のワークフローファイルを置きます。まずは構造を理解するためのシンプルな例です。

yaml

name: Hello                    # ワークフローの名前

on: [push]                    # pushされたら起動

jobs:
  greet:                       # ジョブ名（任意）
    runs-on: ubuntu-latest      # どのランナーで動かすか
    steps:
      - name: チェックアウト
        uses: actions/checkout@v4   # リポジトリを取得する定番アクション

      - name: あいさつ
        run: echo "ブランチ ${{ gitea.ref }} で起動しました"

このファイルをコミットして push すると、その push 自体がトリガーになり、Actions タブに最初のジョブが現れます。各キーの役割は次の通りです。

キー	役割
`on`	起動のきっかけ（`push` /`pull_request` /`workflow_dispatch` ＝手動など）
`jobs`	実行する処理のまとまり。複数定義でき、並列・依存関係も組める
`runs-on`	どのランナー（ラベル）で動かすか
`steps`	ジョブ内の手順。`uses` で既製アクション、`run` でコマンドを実行

実用編①：テストとコミット規約チェックを自動化する

第3回で「コミット規約は最終的にCIで検査するのが堅実」と書きました。それをここで実現します。push と Pull Request のたびに、静的解析（Lint）とテストを自動で走らせる構成です。

yaml

name: CI

on:
  push:
    branches: [main, develop]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0          # commitlintで履歴を見るため全履歴を取得

      - name: Node.js をセットアップ
        uses: actions/setup-node@v4
        with:
          node-version: "20"

      - name: 依存をインストール
        run: npm ci

      - name: 静的解析（Lint）
        run: npm run lint

      - name: テスト
        run: npm test

どれか1つでも失敗するとジョブが赤くなり、Pull Request 上で「失敗」が一目で分かります。これで「テストを通さないと取り込めない」流れを仕組みとして作れます。

✨ コミットメッセージそのものを検査するなら

第3回で導入した commitlint を、ここにnpx commitlint --from origin/main --to HEAD のようなステップとして追加すれば、規約に反するコミットを含むPRをCIで弾けます。手元のhuskyフックは各自が無効化できますが、CIでの検査はすり抜けられません。

実用編②：main への push で自動デプロイする

仕上げは自動デプロイです。main に push されたら、本番サーバーへ SSH で入ってdeploy.sh （git pull → ビルド → 再起動）を実行する、という流れを組みます。これはBunシリーズ・第1回で手作業していたデプロイを、CIに肩代わりさせる形です。

yaml

name: Deploy

on:
  push:
    branches: [main]        # mainへのpushだけが対象

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 本番サーバーへSSHしてデプロイ
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.DEPLOY_HOST }}
          username: ${{ secrets.DEPLOY_USER }}
          key: ${{ secrets.DEPLOY_SSH_KEY }}
          script: |
            cd /var/www/my-app
            ./deploy.sh

⚠️ ️ 認証情報は必ず Secrets に入れる

サーバーのホスト名・ユーザー名・SSH秘密鍵を YAML に直書きするのは厳禁です。漏洩すれば本番サーバーが乗っ取られます。次に説明する Secrets を使い、${{ secrets.名前 }} で参照してください。

Secrets と Variables を設定する

機密情報は Secrets 、機密でない設定値は Variables に分けて登録します。どちらもリポジトリのSettings → Actions から設定できます。

種類	用途	参照方法
Secrets	SSH鍵・APIキー・パスワードなど秘密情報（表示されない）	`${{ secrets.NAME }}`
Variables	デプロイ先パス・環境名など秘密でない値	`${{ vars.NAME }}`

🎯 ここまでで完成する自動化

「PRを出す → CIがテストと規約を検査 → mainにマージ → 自動でデプロイ」という流れが完成しました。人が手でやっていた確認とデプロイが、push をきっかけに全自動で回ります。

GitHub Actions との違い・注意点

「ほぼ互換」ですが、自前運用ならではの違いがいくつかあります。移行時やトラブル時に効いてくるポイントです。

項目	GitHub Actions	Gitea Actions
ランナー	GitHubがホストを提供	自前のact_runnerが必要
ワークフロー置き場	`.github/workflows/`	`.gitea/workflows/` （`.github/` も可）
アクションの取得元	github.com	既定はgithub.com（設定で自インスタンスも可）
コンテキスト変数	`${{ github.* }}`	`${{ github.* }}` /`${{ gitea.* }}` 両対応
料金	無料枠＋従量課金	自前インフラのみ・人数で増えない

✨ アクションのバージョンは固定すると安心

uses: actions/checkout@v4 のようにメジャータグで指定するのが一般的ですが、より厳密にするならコミットハッシュで固定する方法もあります。外部アクションは中身が変わりうるため、本番運用では固定を検討してください。

トラブルシュート

❓ ワークフローが起動しない／Actionsタブがない

インスタンス側（app.ini ）とリポジトリ側（Settings → Actions ）の両方で有効化されているか確認してください。両方オンでないとタブ自体が出ません。

❓ ジョブが「待機中（pending）」のまま動かない

ジョブを拾えるランナーがいない状態です。act_runner が起動しているか、そしてruns-on の値がランナーのラベルと一致しているかを確認します。ubuntu-latest と書いたなら、その名前のラベルでランナーを登録しておく必要があります。

❓ actions/checkout が失敗する

ジョブ用コンテナから Gitea に到達できていない可能性があります。ランナー登録時の--instance にlocalhost を使っていないか確認してください。LAN内IPか正式ドメインを指定します。

❓ 絵文字を含むワークフローでDBエラーが出る

MySQLを使っている場合、文字セットがutf8mb4 でないと絵文字でエラーになることがあります。ワークフロー名やステップ名から絵文字を外すか、DBの文字セットを見直してください。

クイックリファレンス

コード	コード説明
`.gitea/workflows/*.yaml`	ワークフローの置き場所。1ファイル＝1ワークフロー。
`on: [push, pull_request]`	起動のきっかけ。手動は workflow_dispatch。
`runs-on: ubuntu-latest`	ランナーのラベルを指定。登録ラベルと一致が必須。
`uses: actions/checkout@v4`	リポジトリを取得する定番アクション。
`${{ secrets.NAME }}`	機密情報を安全に参照する。直書きしない。
`./act_runner daemon`	ランナーを起動し、ジョブを拾えるようにする。