1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@GL_TsukasainGitLab合同会社

GitLab実践ハンズオン: Issue → MR → Release を体験する

1
Last updated at Posted at 2026-07-06

GitLab実践ハンズオン: Issue → MR → Release を体験する

前提バージョン: GitLab 19.0以上 / 必要プラン: Ultimate

この文書は、新しくグループを1つ作り、その下に小さなプロジェクトを1つ実際に作り、Issue作成からMR、マージ、タグ、Releaseまでの一連の流れを実際に手を動かして体験する構成になっています。上から順番に進めてください。

イシュー参照の必須化にはネイティブな「MRタイトル検証」機能(Premium以上)を、Secret Detectionの検知結果の一元管理にはVulnerability Report(Ultimate専用)を使います。本チュートリアルはUltimateプランを前提とします。

1. ゴールとプラン早見表

このハンズオンを最後まで実施すると、以下のワークフローが体験・確認できます。

  1. 新しく グループ を作り、その下にプロジェクトを作る
  2. 大きな単位の計画は Epic で作り、Roadmap でタイムライン表示を確認する
  3. コードを変更する前に、必ず イシュー を作成する(Scoped Label でイシューの種別を分類し、イシューボード のアサインリストで着手状況を追跡する)
  4. イシューに紐づく ブランチ で作業する
  5. 変更は必ず マージリクエスト(MR) 経由で提出する
  6. MRには必ず対象イシューへの参照が含まれていないと、mainへのマージがブロックされる
  7. MRの変更は Secret Detection で自動スキャンされ、検知結果を Vulnerability Report でトリアージする
  8. main ブランチへの直接プッシュは一切できない
  9. main へのマージ後、タグ付けは手動で行い、GitLab Release作成(Changelogの自動生成を含む)はCIジョブで自動化する

必要な権限: グループの Owner、プロジェクトの Maintainer または Owner ロール

以下は、実際の手順の順番に並べたプラン早見表です。

機能 対応する手順
グループ作成 3-1
Scoped Label(key::value形式、イシュー種別の分類用) 4-1
イシューボード(Assigneeリスト) 4-2
Epic / Roadmap 7(手順1〜2)
イシュー/MRテンプレート 5-1, 5-2
Secret Detection(パイプライン診断) 5-3
GitLab Releases(タグpushでCIジョブが自動作成) 5-4, 7
Changelog API(リリースノートの自動生成) 5-4, 9-1
Protected branches(ロールベースの保護) 6-1
Protected branches(ユーザー/グループ単位の指定) 6-1(任意)
MRタイトルテンプレート 6-2
MRタイトル検証(正規表現でブロック) 6-3
Protected tags(ロールベース) 6-4, 補足
Protected tags(ユーザー/グループ単位) 補足
Secret Detectionの結果をVulnerability Reportで管理 7
Push rules(コミットメッセージ正規表現) 補足で言及
Merge request承認ルール(必須承認・Code Owners) 補足で言及

このチュートリアルで使う機能はすべてUltimateプランに含まれています。

2. 最初に確認すること

  1. GitLabのアカウントを持っていること(https://gitlab.com、または会社・学校のGitLabインスタンス)
  2. 新しくグループを作成できること(セクション3-1で作成します)。作成後、そのグループにUltimateプランを適用できること(トライアルで構いません)
  3. グループを作成できるロール(通常は誰でも作成可能)、または既存グループでの Owner ロールを持っていること

Ultimateの契約がまだない場合は、無料トライアル(30日間)でも本チュートリアルの内容は一通り試せます。

3. グループとプロジェクトを作る

Epic・Roadmap・グループレベルのラベルをこのハンズオンで使うため、新しくグループを1つ作るところから始めます。

3-1. グループを作る

  1. Create group または Create Sub groupを選択します。
  2. Group name に hello-gitlab-group のような分かりやすい名前を入力します(URLも自動で決まります)。
  3. Visibility Level はお好みで(Private推奨)。
  4. 画面下部の Create group ボタンを選択します。
  5. 作成したグループにUltimateプランが適用されていることを確認します(トライアルの場合はSettings > Billingから開始できます)。

3-2. グループの下にプロジェクトを作る

  1. 画面右上の 「+」アイコン(Create new) を選択し、New project/repository を選択します。
  2. Create blank project を選択します。
  3. Project name に hello-gitlab のような分かりやすい名前を入力します。
  4. Project URL の左側にあるプルダウンから、3-1で作ったグループを選びます。
  5. Visibility Level はお好みで(Private推奨)。
  6. Initialize repository with a README のチェックボックスに必ずチェックを入れます。これを忘れるとmainブランチが存在せず、後の手順(ブランチ保護など)が行えません。
  7. 画面下部の Create project ボタンを選択します。

これで、README.mdだけが入った小さなプロジェクトができました。これから、このプロジェクトに実際に機能を1つ追加する体験をしていきます。

4. ラベルとイシューボードを作る

4-1. イシュー種別のScoped Labelを作る

key::value 形式のラベル(Scoped Label)を使うと、同じスコープ内のラベルは同時に付けられなくなります(例: type::bug を付けると type::doc は自動的に外れる)。ここでは進行状況の追跡には使わず、イシューの種別を分類するためだけに使います。厳密な運用ルールは設けず、作成時に当てはまるものを1つ、とりあえず付けておく程度でかまいません。

  1. 画面上部の Search or go to で、3-1で作ったグループを開きます。
  2. グループの Manage > Labels を開き、New label を選択します。
  3. Title に type::bug と入力し、色を選んで Create label を選択します。
  4. 同じ手順で type::doc、type::feature も作成します。

ポイント:

  • ここでラベルをプロジェクトではなくグループに作っているのには理由があります。
  • セクション7で、プロジェクトのイシューにラベルを付けようとすると、ここで作ったtype::*がプロジェクト側で何も設定しなくても選択肢に表示されます。グループのラベルは配下のすべてのプロジェクトに自動的に「降ってくる」ためです。
  • 実際にその様子はセクション7の手順2で確認します。

4-2. イシューボードにアサインリストを作る

進行状況の追跡には、Assigneeリスト(特定のユーザーにアサインされたイシューを表示するリスト)を使います。カードをこのリストにドラッグするだけでイシューが自分にアサインされます。

  1. プロジェクトの Plan > Issue boards を開きます。
  2. New list を選択します。
  3. リストタイプで Assignee を選び、ドロップダウンから自分自身を選択して Add to board を選択します。
  4. 新しいリストが Open と Closed の間に追加されます(両端のOpen・Closedは常に固定されます)。

デフォルトの Open リストはそのまま残します。イシュー作成時はOpenリストに入り、着手を宣言するタイミングで自分のアサインリストへドラッグする、という流れになります。

5. 最初に必要なファイルを追加する

プロジェクトを保護する前に、必要なファイルを先に追加しておきます(保護後だとファイル追加自体がMR経由になり手間が増えるため)。

ファイルの追加方法: プロジェクトのトップページで、ファイル一覧の近くにある 「+」アイコン → New file を選択し、パスとファイル内容を入力して、下部の Commit changes でmainに直接コミットします。

5-1. イシューテンプレート

.gitlab/issue_templates/Default.md を作成します。

## 概要
<!-- 何を実施したいか、なぜ必要かを記述してください -->

## 完了条件
- [ ]
- [ ]

## 関連情報
<!-- 参考リンクやスクリーンショットなど -->

これで、以降 New issue 作成時に自動でこのテンプレートが適用されます。ラベルの/labelクイックアクションは入れていません。4-1で作ったtype::bug / type::doc / type::featureは種別分類用なので、当てはまるものがあればイシュー作成後に手動で1つ付けておく程度で十分です(必須ではありません)。

5-2. MRの説明文テンプレート

.gitlab/merge_request_templates/Default.md を作成します。

## 関連イシュー
Closes #

## 変更内容


## 動作確認方法

Closes #123 のように書くと、MRがマージされた際に対象イシューが自動でクローズされる副次効果もあります。

5-3. .gitlab-ci.yml(Secret Detection用)

コミットに紛れ込んだAPIキーやトークンなどを検知する Pipeline secret detection を追加します。

variables:
  AST_ENABLE_MR_PIPELINES: "true"

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

AST_ENABLE_MR_PIPELINESは、後でセクション7で作るMRのパイプラインとしてこのジョブを確実に実行させるための変数です。これだけで、以降のパイプラインに secret_detection というジョブが追加され、push・MR作成のたびに自動でスキャンされます。

includeは、GitLabが公式に用意・保守しているテンプレート(ジョブ定義一式)を、自分の.gitlab-ci.ymlに取り込む機能です。ジョブの中身(イメージやスクリプト)を自分で書かずに再利用できるのが利点で、実際に実行される際は、この1行が展開されてsecret_detectionジョブの完全な定義(イメージ指定・スクリプトなど)に置き換わった状態でパイプラインが動きます。

Ultimateプランでは、検知結果はパイプラインの成果物(gl-secret-detection-report.json)としてダウンロードできるだけでなく、MRのReportsタブやSecure > Vulnerability reportにも表示され、一元管理できます(セクション7で実際に確認します)。

初めて有効化した場合、今回のスキャンでは既存のコミット履歴は対象外(現在のツリー状態のみ)です。過去のコミットも含めて検査したい場合は、Build > Pipelines > New pipeline から、変数 SECRET_DETECTION_HISTORIC_SCAN を true にして1回だけ実行してください。

このファイルをコミットすると、mainブランチで最初のパイプラインが走ります。Build > Jobs を開いてsecret_detectionジョブのログを確認すると、no leaks foundと表示されているはずです(セクション7で、実際に漏えいを検知させる体験をします)。

5-4. .gitlab-ci.yml(Release自動作成用)

タグがpushされたら、Changelog APIで生成したリリースノートを添えて、GitLab Releaseを自動作成するジョブを追加します。5-3のファイルに以下を追記してください。

stages:
  - test
  - release

create-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: '$CI_COMMIT_TAG'
  before_script:
    - apk add --no-cache curl jq git
    - git fetch --tags
  script:
    - |
      PREV_TAG=$(git tag --sort=-v:refname | sed -n '2p')
      if [ -n "$PREV_TAG" ]; then
        FROM_REF="$PREV_TAG"
      else
        FROM_REF=$(git rev-list --max-parents=0 HEAD | tail -n 1)
      fi
      echo "PREV_TAG=${PREV_TAG:-(none)}"
      echo "FROM_REF=${FROM_REF}"
      echo "--- commits in range ${FROM_REF}..HEAD ---"
      git log --oneline "${FROM_REF}..HEAD"
      RESPONSE=$(curl --silent --header "JOB-TOKEN: ${CI_JOB_TOKEN}" \
        --get \
        --data-urlencode "version=${CI_COMMIT_TAG}" \
        --data-urlencode "from=${FROM_REF}" \
        "${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/repository/changelog")
      echo "--- raw API response ---"
      echo "$RESPONSE"
      NOTES=$(echo "$RESPONSE" | jq -r '.notes')
      if [ -z "$NOTES" ] || [ "$NOTES" = "null" ]; then
        echo "Changelog APIから内容を取得できませんでした(対象コミットにtrailerが無いか、API呼び出しに失敗しています)。" > release_notes.md
      else
        echo "$NOTES" > release_notes.md
      fi
  release:
    tag_name: '$CI_COMMIT_TAG'
    name: 'Release $CI_COMMIT_TAG'
    description: './release_notes.md'

stagesを明示的に宣言しているのは、releaseステージがGitLabの既定のステージ一覧に含まれていないためです(secret_detectionジョブが使うtestステージは既定に含まれているので、そのまま動きます)。

このジョブは、GitLabのChangelog APIをGETで呼び出して(リポジトリを変更しない読み取り専用の呼び出しです)、直前のタグからの変更点をカテゴリ別にまとめたテキストを取得し、そのままReleaseの説明文として使います。対象になるのは、9-1で説明する形式のコミットだけです。

なぜfromを毎回明示的に指定するのか:

  • Changelog APIは、fromを省略すると「直前のバージョンタグ」を自動的に探します。
  • しかし、最初のリリース(直前タグが存在しない場合)にfromを省略するとAPIがエラーを返します。
  • このエラーレスポンスにはnotesフィールドが無いため、jq -r '.notes'が文字列"null"を出力し、それがそのままリリースの説明文になってしまいます。
  • これを避けるため、直前のタグが無い場合はリポジトリの最初のコミット(git rev-list --max-parents=0 HEAD)をfromとして明示的に渡しています。

6. 画面設定

6-1. main ブランチを保護する

  1. 対象プロジェクトを開く

  2. 左サイドバーから Settings > Repository を選択

  3. Branch rules セクションを展開

  4. main ブランチを選択

  5. 以下のように設定する

    項目 設定値
    Allowed to merge Developers + Maintainers
    Allowed to push and merge No one

  6. Save changes をクリック

これで、Developer・Maintainerロールのユーザーであってもmainへの直接プッシュができなくなり、必ずMRを作成してマージする必要があります。

ポイント: 「Allowed to push and merge」を明示的に「No one」に設定しないと、直接プッシュ自体は制限されません。デフォルトのままにしないよう注意してください。

6-2. MRタイトルテンプレートを設定する

  1. Settings > Merge requests を開く
  2. Merge request title template の欄に以下のように入力
Resolve #%{issue_id} "%{issue_title}"
  1. Save changes

イシューの詳細画面から「Create merge request」を選択すると、ブランチ名とMRタイトルが自動生成されます。タイトルは Resolve #123 "READMEにセットアップ手順を追記" のような形式で埋まります。

%{issue_id} が空になってしまう場合:

  • この変数は、ブランチ名がイシュー番号を含む形式(例: 123-readme)になっているときだけ値が入ります。
  • ブランチをゼロから手動で作った場合は空欄になることがあります。
  • 必ずイシューの詳細画面にある「Create merge request」ボタンから作成してください(セクション7の手順4で実際に行います)。このボタンから進むと、ポップアップでブランチが作られた直後に、そのブランチ名を引き継いだMR作成画面に遷移します。

これはあくまで「デフォルト値」であり、それ自体には強制力はありません。次の6-3で実際にブロックする仕組みを作ります。

6-3. MRにイシュー参照がなければマージをブロックする

ここが今回のワークフローの核心です。MRのタイトルを正規表現でチェックし、パターンに一致しないと物理的にマージボタンが押せなくなる、ネイティブの「MRタイトル検証」機能を使います。

  1. Settings > Merge requests を開く

  2. タイトルは指定されたパターンに一致する必要があります チェックボックスをオンにすると、Title pattern と Title example の入力欄が表示されます

  3. Title pattern に正規表現を入力

    ^(Draft: )?.*#\d+.*

  4. Title example に、期待するタイトルの例を入力(例: Resolve #123 "READMEにセットアップ手順を追記")

  5. Save changes

これで、タイトルにイシュー番号を含まないMRは、マージリクエストのマージチェック欄に検証失敗が表示され、マージボタンがブロックされます。6-2の「MRタイトルテンプレート」と組み合わせれば、ユーザーが何もしなくても最初からパターンを満たしたタイトルになるため、実質的に運用の手間はほぼゼロになります。

正規表現はRE2構文です。PCRE(多くのオンライン正規表現テスターで使われる構文)とは一部異なるので、後読み(lookahead)や後方参照は使えません。

このタイトル検証はMRのタイトルのみを対象とし、説明文(description)は見ません。「Closes #123」を説明文だけに書く運用にしていると、タイトル検証と食い違うので、6-2のタイトルテンプレートと必ずセットで使ってください。

6-4. タグを保護しておく(推奨)

  1. 対象プロジェクトを開く
  2. 左サイドバーから Settings > Repository を選択
  3. Protected tags セクションを展開
  4. Add new を選択
  5. Tag を選択し、入力欄に *(すべてのタグにマッチするワイルドカード)を入力
  6. Create wildcard を選択
  7. Allowed to create で Maintainers を選択
  8. Protect を選択

これで、タグの作成をMaintainer以上に限定でき、意図しないタグが誰でも作成できてしまう事態を防げます。

7. 実際に体験する: Issue → MR → Release

ここまでの設定ができたら、実際に一連の流れを体験してみましょう。「READMEにセットアップ手順を追記する」という架空の変更を例にします。

手順1: Epicを作る

  1. 画面上部の Search or go to で、3-1で作ったグループを選びます。
  2. 左サイドバーの Plan > Work items を選択します。
  3. New item を選択します。
  4. Type ドロップダウンから Epic を選択します。
  5. Title に READMEドキュメント整備 のような分かりやすい名前を入力します。
  6. Labels を開き、4-1で作った type::doc を選択します(README更新の計画なので)。
  7. Start date を開き、Fixed(固定)を選択して今日から3日前の日付を入力します。
  8. Due date にも同様に、Fixed を選択して今日から7日後の日付を入力します。
  9. Create epic を選択します。
  10. 作成後、左サイドバーの Plan > Roadmap を開きます。
  11. デフォルトの表示設定(Weeksプリセット)のまま、作成したEpicのバーが「今日」を示す赤い縦線を跨いで表示されていることを確認します。
  12. この画面はガントチャート形式で、期間を横棒(バー)として表示するため、WBS(作業分解構成図)のような見え方になっていることを確認してください。

手順2: イシューを作成する(Epicから)

  1. 手順1で開いたRoadmap画面から、作成したEpicのバーまたはタイトルを選択して、Epicの詳細画面を開きます。
  2. Child items セクションの Add を選択します。
  3. Add a new issue を選びます。
  4. Title に READMEにセットアップ手順を追記 と入力します。
  5. Project のドロップダウンから3-2で作ったプロジェクトを選びます。
  6. Create issue を選択します。作成されたイシューは自動的にこのEpicの子アイテムになります。
  7. Child items の一覧に追加されたイシューを選択して詳細画面を開きます。5-1のイシューテンプレートが自動適用されていることを確認できます。
  8. 右サイドバーのLabelsからEditを選択し、ラベル選択画面を開きます。プロジェクト側では何も設定していないのに、4-1でグループに作ったtype::bug・type::doc・type::featureがそのまま選択肢に表示されていることを確認します(グループラベルがプロジェクトに「降ってきている」体験です)。
  9. type::docを選んで付けておきます(必須ではありません)。

手順3: 着手を宣言する(ボードでカードを移動する)

  1. プロジェクトの Plan > Issue boards を開きます。
  2. 手順2で作成したイシューは、ボード上ではまだOpenリストに表示されています(Epicの子アイテムであることはボードのリスト分けには影響しません)。
  3. このカードをOpenのリストから4-2で作った自分のAssigneeリストへドラッグします。これでイシューが自分にアサインされ、着手したことがチームに分かるようになります。

手順4: ブランチを作成する

  1. イシューの詳細画面で Create merge request を選択します。
  2. ポップアップが表示され、作成するフィーチャーブランチの名前(例: 1-readme)を確認・編集できます。
  3. ポップアップ内の Create merge request ボタンを選択します。この操作をした瞬間に、初めてフィーチャーブランチが作られます(それまではブランチはまだ存在しません)。

手順5: MRを作成する

  1. ブランチ作成後、MRタイトルが6-2のテンプレートに従って自動で埋まった状態の、まだ中身が空のMR作成画面に遷移します。説明文には5-2のテンプレートが入っています。
  2. プロジェクトにMR説明文テンプレート(5-2)が設定されている場合、Closes #の後ろにイシュー番号は自動で入りません(テンプレートが無ければブランチ名から自動挿入されますが、テンプレートがあるとその挙動が上書きされます)。
  3. 説明文の Closes # の行を見つけ、#の後ろに手動で対象イシューの番号(例: Closes #1)を書き加えます。
  4. 画面下部の Create merge request を選択してMRを作成します。

手順6: ファイルを編集する

  1. 画面左上のブランチ選択は、MRを作成した時点で対象のフィーチャーブランチ(例: 1-readme)に自動で切り替わっています。

  2. 画面右上の Code → Web IDEで開く を選びます。

  3. README.mdを開いて編集します。適当な1行(例: ## セットアップ手順 の見出しと簡単な説明)を追記します。

  4. さらに、Secret Detectionの動作を実際に確認するため、以下の1行も追記します(ハイフンの前後のスペースを削除して、個人アクセストークンの見た目に合わせます)。

    glpat - 12345678901234567890

手順7: コミットする

  1. 左側のアクティビティバーで Source Control アイコンを選択します(またはCtrl+Shift+G / Control+Shift+G)。

  2. コミットメッセージの入力欄に、次のように1行目にタイトル、1行空けてからChangelog: addedを入力します(9-1で詳しく説明します)。

    READMEにセットアップ手順を追記

Changelog: added

  3. ブランチは手順4で作られたフィーチャーブランチが選択された状態のままなので、そのまま Commit を選択します(新しいブランチを作る必要はありません)。すでにMRが存在するため、このコミットは自動的に手順5のMRに追加されます。

手順8: 検知結果を確認する

  1. MRの詳細画面で Reports タブを開きます。
  2. Security scan を選択し、「Secret detection detected 1 new potential vulnerability」のように表示されていることを確認します(View all pipeline findings で詳細一覧も見られます)。
  3. Build > Jobs からsecret_detectionジョブのログを開き、leaks found: 1 と表示されていることを確認します。
  4. Job artifactsから成果物をダウンロードすると、検知されたシークレットの種類(GitLab personal access token)、重大度(Critical)、ファイル内の行番号などの詳細も確認できます。

手順9: マージチェックを確認する

  1. イシューから作成したMRは初期状態でDraftになっているため、まず画面上部の Mark as ready(準備済みとしてマーク)を選択してDraft状態を解除します。
  2. マージチェック欄にタイトル検証の結果が表示され、問題なければ緑色になっていることを確認します。
  3. Secret Detectionの検知結果はマージ自体をブロックしません(検知はあくまで警告で、マージ判断は人が行う設計です)。

手順10: マージする

  1. Merge ボタンを選択します。
  2. MR説明文のCloses #パターンにより、対象イシューも自動でクローズされることを確認します。
  3. 手順6の偽のシークレットがmainにマージされたことで、この「finding」は「vulnerability」に変わります。

手順11: 脆弱性を確認する

  1. 左サイドバーの Secure > Vulnerability report を開きます。
  2. 手順8で検知された脆弱性(Secret type: GitLab personal access token)を選択します。
  3. Descriptionから詳細(シークレットの種類、対処方法、検知日時・場所)を確認します。

手順12: ステータスを変更する(トリアージ)

  1. 脆弱性の一覧で、ステータスの選択肢(トリアージが必要・確認済み・却下済み・解決済み)から 却下済み を選びます。
  2. 却下理由を選択 のドロップダウンから テストで使用 を選びます。
  3. コメントを追加(必須) に「デモ用の偽のトークンのため」のような理由を記入します。
  4. Vulnerability Reportのトップ画面から、この脆弱性が表示されなくなることを確認します。トリアージはあくまで「今は対応不要」という記録であり、コード自体は変わりません。
  5. きれいにしておきたい場合は、新しいイシューを1つ作り(例: README.mdの偽トークンを削除)、手順2〜10と同じ手順(Create merge request → 編集 → コミット → マージ)でglpat - ...の行を削除してください。本物の漏えいが起きた場合は、トリアージや削除だけでなく、該当のトークンを直ちに無効化(revoke)する必要があります。 Gitの履歴には削除前のコミットが残るため、削除だけでは漏えいのリスクが完全には消えません。

手順13: タグを作成する

  1. 左サイドバーの Code(またはRepository) → Tags を開きます。
  2. New tag を選択します。
  3. Tag name に v0.1.0 のようなバージョン番号を入力し、Create from は main のままにします。
  4. Release notes は空欄のままにしてください(5-4のCIジョブが自動生成するため、ここで書いた内容とは別にReleaseが作られて重複してしまいます)。
  5. Create tag を選択します。

手順14: Releaseを確認する

  1. タグのpushをトリガーにパイプラインが走ります。
  2. Build > Jobs でcreate-releaseジョブが成功していることを確認します。
  3. 左サイドバーの Deploy > Releases を開きます。
  4. 手順7でtrailerを付けたコミットの内容が、リリースノートとして自動的に反映されていることを確認します。

これで、Issue作成からReleaseまでの一連の流れを一通り体験できました。

9. バージョン番号の決め方(参考)

タグを作るたびに毎回悩まないよう、目安を決めておきます。

  • patch(例: v1.2.0 → v1.2.1): バグ修正のみ
  • minor(例: v1.2.1 → v1.3.0): 後方互換性のある新機能追加
  • major(例: v1.3.0 → v2.0.0): 後方互換性を壊す変更

9-1. コミットメッセージにtrailerを付ける

リリースノートを自動生成するには、コミットメッセージの末尾に専用のGit trailerを1行加えます。

READMEにセットアップ手順を追記

Changelog: added

なぜChangelog: addedという文字列なのか:

  • これはGitLab独自の記法ではなく、Gitの世界で昔から使われている「trailer」という標準的な仕組みに乗っかったものです。
  • コミットメッセージの末尾にKey: Valueの行を1つ追加する書き方で、Signed-off-by: 名前 <email>やCo-authored-by: 名前 <email>と同じ仲間です(Gitにはgit interpret-trailersというtrailerを扱う専用コマンドもあります)。
  • コミットの1行目(subject)の書き方を変える必要がないのが利点です。
  • 5-4のジョブが呼び出すChangelog APIは、このChangelogというキー名を(デフォルトの設定として)探しに来ます。
  • 値のadded/fixed/changed/removed/securityという語彙も、GitLabの独自発明ではなく、OSSでよく使われるKeep a Changelogという慣習の分類(Added/Changed/Removed/Fixed/Securityなど)をほぼそのまま使っています。

使えるカテゴリは主に added / fixed / changed / removed / security です。このtrailerが付いたコミットだけが、5-4のcreate-releaseジョブが呼び出すChangelog APIの対象になります(trailerがないコミットは無視されます)。

出力フォーマットをカスタマイズしたい場合は、.gitlab/changelog_config.ymlというデフォルトの設定ファイルを作成し、日付フォーマットやテンプレートを定義できます。

Dockerイメージやビルド成果物をパッケージレジストリに公開している場合は、パッケージバージョンとリリースタグが一致していれば、GitLabが自動でそのパッケージをリリースエビデンスに含めてくれます。追加の設定は不要です。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?