【Ansible】GitHub CopilotのinstructionsでAnsibleの自動コーディング・レビューを実現したい

はじめに

チームで開発を進める上で、コーディングルールをどのように共有し、徹底するかは悩ましい問題です。
ドキュメントを作成しても読まれなかったり、レビューで毎回指摘するのも手間がかかります。そんな中、GitHub Copilotの.github/instructionsにコーディングルールを記述することで、ルールの管理とGitHub Copilotによるコーディング支援・自動レビューを両立できるのではないかと考えました。
この記事では、Ansibleを例に、GitHub Copilotのinstructionsを活用して開発ルールを徹底させる方法について解説します。

TL;DR

この記事を読めば、以下のことができるようになります

• GitHub CopilotのinstructionsにAnsibleのコーディングルールを定義する方法
• instructionsに定義したルールにもとづいて、GitHub CopilotにAnsible Playbookを生成させる方法
• GitHub CopilotにPull Requestを自動レビューさせ、ルール違反を指摘させる方法

前提条件

• GitHubアカウントを所持していること
• GitHub Copilotのコードレビューが有効化されていること

実行環境

• VSCode: 1.128.0

詳細

1. 開発フォルダ構成・ファイル説明

フォルダ構成

初期状態としては、インベントリ・Playbook作成前なのでinstructionsのファイルのみがある状態です。

.github/
  └── instructions/
        ├── base.instructions.md                   # 基本ルール
        └── variable_naming.instructions.md        # 変数の命名に関するルール

ファイル説明（base.instructions.md ）

このファイルに今回は、Ansible開発でよくある基本ルールの一部を書いてみました。

---
applyTo: "**/*.yml"
---

# Ansible開発時の基本ルール

## コメントについて

- 返答、コード内のコメントは日本語で記述してください

## Playbookについて

- モジュールを指定する際は、省略形を使わず、必ずFQCN（例: `ansible.builtin.copy`）で記述する
- 原則として `gather_facts: false` を明示する
  - 対象機器のFact情報が必要な場合、`ansible.builtin.setup`モジュールなどの専用モジュールを使用する
- 原則として`ansible.builtin.command` および `ansible.builtin.shell` モジュールは使用しない
- タスク名は処理内容がわかるように、英語で記述する。フォーマットは下記の通り
  - フォーマット
    - <どうする（動詞）> <何を> <どこに対して>
  - 例
    - Create file to target node

## フォルダ構成・ファイルの中身について

以下の構成とし、hosts.ymlはグループとホストの親子関係のみを記載する（変数はhost_varsまたはgroup_varsに定義）。
また、サンプル出力する場合のホスト名は`host01`とする。

### フォルダ構造

- .github
- roles
- inventory
  - group_vars
    - <group_name>.yml
  - host_vars
    - <host_name>.yml
  - hosts.yml
- <playbook_name>.yml

### ホスト用のファイル

host_vars/<host_name>.yml には、Ansibleがリモートホストへ接続するための以下の接続情報も必ず含めること。（以下は対象がlinuxの場合）

- `ansible_host`: <リモートホストのIPアドレスまたはFQDN>
- `ansible_user`: <ユーザー名>
- `ansible_password`: <パスワード>

ファイル説明（variable_naming.instructions.md）

このファイルについて今回は、変数名についてのシンプルなルールを定義してみました。

---
applyTo: "**/*.yml"
---

# Ansible変数定義のルール

## ルール

変数の用途ごとに以下のような接頭語をつける

- register変数
  - 接頭語: reg_
  - 定義例: reg_file_name
- Playbook変数
  - 接頭語: play_
  - 定義例: play_file_name
  - 補足: Playbookのvarsに定義する変数のこと

2. Playbookを作ってもらう

実行したプロンプト

VSCodeで開発フォルダを開き、GitHub Copilotのチャットで以下のような質問をしてみます。

Ansibleで、リモートのLinuxサーバーに対して以下の処理をするインベントリとPlaybookを作成してください
1. ホスト名を取得して表示する
2. 指定したファイルが存在しない場合はエラーになる

作成されたファイル

• Playbook（get_hostname_and_check_file.yml）

  • 毎回同じPlaybookが作成されるわけではないですが、今回は以下のようなPlaybookが作成されました。今回に関しては、ルールが一通り守られています
    • もし、守られていないルールがあればプロンプト実行後に念押しすれば修正してくれます（例: ansible.builtin.commandモジュールは使わないでください）

  - name: Get hostname and check file existence
    hosts: linux_servers
    gather_facts: false
  
    vars:
      play_file_path: /tmp/test_file
  
    tasks:
      - name: Gather facts to get hostname
        ansible.builtin.setup:
  
      - name: Display hostname
        ansible.builtin.debug:
          msg: "Hostname is {{ ansible_hostname }}"
  
      - name: Check if specified file exists
        ansible.builtin.stat:
          path: "{{ play_file_path }}"
        register: reg_file_stat
  
      - name: Fail if file does not exist
        ansible.builtin.fail:
          msg: "File not found: {{ play_file_path }}"
        when: not reg_file_stat.stat.exists
  

• インベントリ（inventory/hosts.yml）

  • 対象機器がlinuxサーバーであることを考慮して、ホストをlinux_serversグループ配下に入れてくれました

  ---
  all:
    children:
      linux_servers:
        hosts:
          host01:
  

• インベントリ（inventory/host_vars/host01.yml）

  • 変数の中身は後で実在するサーバーの情報に修正する必要があります

  ---
  ansible_host: 127.0.0.1
  ansible_user: user
  ansible_password: password
  

実行結果

作成されたファイル群をもとに、以下の作業をしてからPlaybookを実行してみます。

• inventory/host_vars/host01.ymlを実在するサーバーの情報に修正
• リモートサーバーに変数play_file_pathで定義したファイルを作成

簡単なPlaybookではありますが修正なしで、CopilotでPlaybookを作成することができました。

$ ansible-navigator run get_hostname_and_check_file.yml -i inventory/

PLAY [Get hostname and check file existence] ***********************************

TASK [Gather facts to get hostname] ********************************************
ok: [host01]

TASK [Display hostname] ********************************************************
ok: [host01] => {
    "msg": "Hostname is testhost"
}

TASK [Check if specified file exists] ******************************************
ok: [host01]

TASK [Fail if file does not exist] *********************************************
skipping: [host01]

PLAY RECAP *********************************************************************
host01                     : ok=3    changed=0    unreachable=0    failed=0    skipped=1    rescued=0    ignored=0   

3. コードレビューしてもらう

レビューしてもらうPlaybook

Pull requestを出してCopilotにレビューしてもらうPlaybookは下記です。あえて以下のようなルールに反した記述があります。

1. モジュール名がFQCN（例: ansible.builtin.copy）の形式になっていない
2. 2つ目のタスク名が日本語
3. 3つ目のタスクのregister変数の接頭語がreg_になっていない

- name: Get hostname and check file existence
  hosts: linux_servers
  gather_facts: false

  vars:
    play_file_path: /tmp/test_file

  tasks:
    - name: Gather facts to get hostname
      setup:

    - name: ホスト名を表示
      debug:
        msg: "Hostname is {{ ansible_hostname }}"

    - name: Check if specified file exists
      stat:
        path: "{{ play_file_path }}"
      register: file_stat

    - name: Fail if file does not exist
      fail:
        msg: "File not found: {{ play_file_path }}"
      when: not file_stat.stat.exists

GitHub Copilotにレビューしてもらう方法

• GitHubでPull requestを出す際に、ReviewerにCopilotを指定します

レビュー結果

Pull requestを出してからしばらく経過すると、自動でレビュー結果がコメントとして追加されます。

1. モジュール名がFQCN（例: ansible.builtin.copy）の形式になっていない

   

2. 2つ目のタスク名が日本語

   

3. 3つ目のタスクのregister変数の接頭語がreg_になっていない

   

さいごに

今回は、GitHub Copilotのinstructions機能を使って、Ansibleのコーディングルールを徹底させる方法を紹介しました。
instructionsにルールを定義しておくことで、Copilotがコーディング規約などの基本的なレビューを自動で行ってくれます。これにより、レビュアーは細かな規約のチェックから解放され、コアな機能やロジックのレビューに集中できます。その結果、レビューの質と開発効率の向上が期待できます。
今回はAnsibleを例にしましたが、この方法は他の言語でも応用できるはずです。ぜひ、みなさんの開発現場でも試してみてください。

参考URL

• GitHubドキュメント > GitHub Copilot を使ったコードレビュー
  • GitHub Copilotを使ったコードレビューの設定方法