Skip to main content

このバージョンの GitHub Enterprise サーバーはこの日付をもって終了となりました: 2024-07-09. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise サーバーにアップグレードしてください。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

Organization のスターター ワークフローを作成する

Team 内のユーザーがより簡単に新しいワークフローを追加できるように、スタート ワークフローを作成する方法について学びます。

注: GitHub ホステッド ランナーは、現在 GitHub Enterprise Server でサポートされていません。 GitHub public roadmap で、今後の計画的なサポートの詳細を確認できます。

概要

スターター ワークフローを使用すると、ワークフローを作成するアクセス許可を持つ Organization 内のすべての人が、より迅速かつ簡単にワークフローを作成できます。 新しいワークフローを作成する場合は、スターター ワークフローを選択すると、ワークフローを作成する作業の一部またはすべてを自動的に行うことができます。 スターター ワークフローは、カスタム ワークフローの構築の出発点として利用することも、そのまま利用することもできます。 これにより、時間を節約できるだけでなく、Organization 全体の一貫性とベスト プラクティスが促進されます。

GitHub には、次の高レベルのカテゴリにすぐに使用できるスターター ワークフローが用意されています。

  • デプロイ (CD) 。 詳しくは、「継続的デプロイについて」を参照してください。

  • 継続的インテグレーション (CI) 。 詳しくは、「継続的インテグレーションについて」を参照してください。

  • オートメーション。 Automation スターター ワークフローには、pull request のトリアージや、pull request で変更されたパスに基づくラベルの適用、リポジトリに初めて投稿する人へのあいさつなど、ワークフローを自動化するためのソリューションが用意されています。

Note

スターター ワークフローにはパブリック .github リポジトリが必要であるため、Enterprise Managed Users では使用できません。

スターター ワークフローを作成する

Organization の パブリック .github リポジトリへの書き込みアクセス権限を持つユーザーは、スターター ワークフローを作成できます。 その後、ワークフローを作成するアクセス許可を持つ Organization のメンバーはそれを使用できます。

注: スターター ワークフロー間の重複を避けるには、ワークフロー内から再利用可能なワークフローを呼び出すことができます。 これにより、ワークフローの管理を容易にできます。 詳しくは、「ワークフローの再利用」を参照してください。

この手順では、スターター ワークフローとメタデータ ファイルを作成する方法を示します。 メタデータ ファイルには、ユーザーが新しいワークフローを作成するときに、スターター ワークフローがどのように表示されるかが記述されています。

  1. それがまだない場合は、Organization で .github という名前の新しい_パブリック_ リポジトリを作成します。

  2. workflow-templates という名前のディレクトリを作成します。

  3. workflow-templates ディレクトリ内に新しいワークフロー ファイルを作成します。

    リポジトリの既定のブランチを参照する必要がある場合は、$default-branch プレースホルダーを使用できます。 ワークフローが作成されるとき、プレースホルダーはリポジトリの既定のブランチの名前に自動的に置き換えられます。

注: runs-on キーの次の値もプレースホルダーとして扱われます。

  • "ubuntu-latest" は "[ self-hosted ]" に置き換えられます
  • "windows-latest" は "[ self-hosted, windows ]" に置き換えられます
  • "macos-latest" は "[ self-hosted, macOS ]" に置き換えられます

たとえば、octo-organization-ci.yml という名前のこのファイルは、基本的なワークフローを示しています。

YAML
name: Octo Organization CI

on:
  push:
    branches: [ $default-branch ]
  pull_request:
    branches: [ $default-branch ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Run a one-line script
        run: echo Hello from Octo Organization
  1. workflow-templates ディレクトリ内にメタデータ ファイルを作成します。 メタデータ ファイルは、ワークフロー ファイルと同じ名前にする必要がありますが、.yml 拡張子の代わりに、.properties.json を付ける必要があります。 たとえば、octo-organization-ci.properties.json という名前のこのファイルには、octo-organization-ci.yml という名前のワークフロー ファイルのメタデータが含まれます。

    JSON
    {
        "name": "Octo Organization Workflow",
        "description": "Octo Organization CI starter workflow.",
        "iconName": "example-icon",
        "categories": [
            "Go"
        ],
        "filePatterns": [
            "package.json$",
            "^Dockerfile",
            ".*\\.md$"
        ]
    }
    
    • name - 必須。 ワークフローの名前。 これは、使用可能なワークフローの一覧に表示されます。

    • description - 必須。 ワークフローの説明。 これは、使用可能なワークフローの一覧に表示されます。

    • iconName - 省略可能。 ワークフローの一覧に表示されるワークフローのアイコンを指定します。 iconName には次のいずれかの種類を指定できます。

      • workflow-templates ディレクトリに格納されている SVG ファイル。 ファイルを参照するには、その値がファイル拡張子のないファイル名である必要があります。 たとえば、example-icon.svg という名前の SVG ファイルは example-icon として参照されます。
      • GitHub の Octicons セットからのアイコン。 octicon を参照するには、値を octicon <icon name> にする必要があります。 たとえば、「 octicon smiley 」のように入力します。
    • categories - 省略可能。 ワークフローが表示されるカテゴリを定義します。 次の一覧からのカテゴリ名を使用できます。

      • starter-workflows リポジトリの一般的なカテゴリ名。
      • linguist リポジトリの一覧からの Linguist 言語。
      • starter-workflows リポジトリの一覧からのサポートされている技術スタック。
    • filePatterns - 省略可能。 ユーザーのリポジトリのルート ディレクトリに、定義された正規表現に一致するファイルがある場合、そのワークフローを使用できるようにします。

別のスターター ワークフローを追加するには、同じ workflow-templates ディレクトリにファイルを追加します。

次の手順

GitHub Actions についてさらに学ぶには、「スターター ワークフローの使用」をご覧ください。