JetBrains Space ヘルプ

GitHub アクションから

このセクションでは、GitHub アクションと Space Automation の主な違いを要約し、移行プロセスに役立つサンプルスクリプトを提供します。

免責事項: GitHub アクションに関するすべての情報は、公式 GitHub Web サイトから取得されており、このドキュメントを投稿した時点でのみ有効です。どの製品も時間の経過とともに進化するため、この情報はすでに古くなっている可能性があります。

主な概念

GitHub アクション

Space Automation

ワークフローは、構成可能な自動プロセスです。

  • 相互に依存できるジョブで構成されます。

  • .yml ファイルに保存されます。

  • .github ディレクトリには、必要な数のワークフローを含めることができます。

(まだ利用できません) パイプラインは、構成可能な自動プロセスです。

  • 相互に依存できるステージで構成されます。

ジョブは、ステップで構成される定義されたタスクです。

  • ジョブは、runs-on キーワードを使用して実行環境を指定します。

  • ジョブは並行して実行することも、前のジョブのステータスに依存して順次実行することもできます。

ジョブは、ステップで構成される定義されたタスクです。

  • GitHub Action のジョブとは異なり、Automation のジョブは実行環境を設定しません。

  • スクリプト内のすべてのジョブは常に並行して実行されます。

ステップはジョブの構成要素です。

  • ジョブ内のすべてのステップは同じ仮想マシン上で実行されます。

  • ステップではコマンドまたはアクションを実行できます。

  • ステップは順番に実行されます。

ステップはジョブの構成要素です。

  • ステップでは、container("image_name") キーワードを使用して実行環境を指定します。ジョブ内の各ステップは別のコンテナーで実行されます。

  • ステップでは、コマンド、.sh ファイル、または任意の Kotlin コードを実行できます。

  • デフォルトでは、ステップは並行して実行されますが、順番に実行することもできます。

Action は、ステップとして実行できるポータブルなビルドブロックです。

  • アクションには入力変数と出力変数があります。

  • スクリプト内でアクションを参照することで、アクションを使用できます。

  • アクションでは、Docker コンテナーまたは JavaScript コードを実行できます。

  • アクションは npm パッケージとして配布されます。

一致するエンティティがありません。

Hello World!

name: Hello World on: push jobs: hello-world: name: Hello world job runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Hello from vm run: echo Hello World!

Hello World!

job("Hello world") { container(displayName = "Say Hello", image = "ubuntu") { shellScript { content = "echo Hello World!" } } }

コードとしての構成

どちらの製品も、ビルドを構成するための UI を提供しません。設定はスクリプトファイルを使用して実行されます。

GitHub アクション

Space Automation

宣言型スクリプト用の YAML ベースの DSL。実行フローを変更するスクリプトが必要な場合は、JavaScript に基づいてカスタムアクションを作成できます。

Kotlin ベースの DSL。純粋な Kotlin を使用して、複雑な実行ロジックを適切に実装できます。

スクリプトのロケーション

GitHub アクション

Space Automation

ワークフローは、.github ディレクトリ内の別のファイルにあります。カスタムアクションは別のディレクトリにあります。

/ project root ├─── .github │ ├─── action1 // custom action │ │ ├─── action.yml │ │ └─── ... │ ├─── action2 // custom action │ │ ├─── action.yml │ │ └─── ... │ ├─── myworkflow1.yml // workflow file │ ├─── myworkflow2.yml // workflow file ...

すべての構成は、単一の .space.kts ファイルを使用して行われます。

/ project root ├─── .space.kts ...

実行環境

GitHub アクション

Space Automation

  • ランナーはクラウドでホストされ、2 コア、7 GB RAM、14 GB SSD 構成の仮想マシンに基づいています。これらの仮想マシン内で Docker コンテナーを実行することもできます。

  • OS: Windows Server 2019、Ubuntu、macOS Catalina を含む定義済み OS のリスト。

  • クラウドランナーを使用する代わりに、自己ホスト型ランナーを使用できます。

  • ランナーはクラウドでホストされ、カスタマイズ可能な構成 (最大 4 つの vCPU、16 GB RAM、30 GB SSD) を備えた Docker コンテナーに基づいています。

  • OS: Linux ベースのコンテナーイメージ。

  • 自己ホスト型ランナーはまだサポートされていませんが、計画されています。

実行制限

GitHub アクション

Space Automation

  • ジョブの実行時間は最大 6 時間です。

  • ワークフローの実行時間は最大 72 時間です。

  • セルフホストランナーのジョブキュー時間は最大 24 時間です。

  • リポジトリ内のすべてのアクションにわたって、1 時間に最大 1000 件の API リクエストが発生します。

  • 同時ジョブ数はプランによって異なります。Free では 20、Enterprise では最大 180 (macOS の場合は 5 と 50)。

  • ワークフロー実行ごとに最大 256 個のジョブマトリックス。

  • 詳細 (英語)

  • ジョブの実行時間は最大 2 時間です。

  • ジョブのキュー時間: なし。

  • API リクエスト: 制限なし。

  • ジョブ数 (同時または順次): スクリプト内で最大 100、ジョブごとに最大 50 のコンテナー。

コマンドの実行

GitHub アクション

Space Automation

name: A workflow for showing project dir on: push jobs: show: name: Show dir content runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Show dir run: | echo Project dir: ls ./
job("Show dir content") { container(image = "ubuntu:latest") { shellScript { content = """ echo Project dir: ls ./ """ } } }

実行コード

GitHub アクション

Space Automation

命令型コードを実行するには、カスタムアクションを作成する必要があります。例: 次のスクリプトは icanhazdadjoke.com(英語) からランダムなジョークを取得します。

./github/myworkflow.yml のワークフロー:

name: Get a joke on: push jobs: action: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: ha-ha uses: ./.github/actions/joke-action

.github/actions/joke-action/action.yml でのアクション:

name: "Get a joke action" description: "Use an external API to get a joke" outputs: joke-output: description: The resulting joke from the icanhazdadjokes API runs: using: "node12" main: "main.js"

.github/actions/joke-action/main.js :

const getJoke = require("./joke"); const core = require("@actions/core"); async function run() { const joke = await getJoke(); console.log(joke); core.setOutput("joke-output", joke); } run();

.github/actions/joke-action/joke.js :

const request = require("request-promise"); const options = { method: "GET", uri: "https://icanhazdadjoke.com/", headers: { Accept: "application/json" }, json: true }; async function getJoke() { const res = await request(options); return res.joke; } module.exports = getJoke;

どのステップでも、任意の Kotlin コードを適切な場所で実行できます。例: 次のスクリプトは、OkHttp クライアントを使用して icanhazdadjoke.com(英語) からランダムなジョークを取得します。

./.space.kts :

@file:DependsOn("com.squareup.okhttp:okhttp:2.7.4", "org.json:json:20200518") import com.squareup.okhttp.* import org.json.JSONObject job("Get random joke") { container(image = "amazoncorretto:17-alpine") { kotlinScript { val client = OkHttpClient() val request = Request.Builder() .url("http://icanhazdadjoke.com") .addHeader("Accept", "application/json") .build() val response = client.newCall(request).execute() val jData = response.body().string() val jObject = JSONObject(jData) val joke = jObject.get("joke").toString() println(joke) } } }

トリガーイベント

GitHub アクション

Space Automation

ジョブの実行トリガーを設定するには、on キーワードを使用する必要があります。次のトリガーがサポートされています。

  • Git プッシュ。

  • スケジュール(メインブランチのみ)。

  • Webhook イベント: 基本的に、プルリクエスト、課題へのコメントなどのシステム内のイベント。Webook にはペイロードがあるため、さまざまなトリガーフィルターを作成できます。

  • 手動 (英語): workflow_dispatch イベントを使用すると、REST API を使用して、または UI からワークフローを手動で実行できます。

schedule を除くすべてのトリガーでは、branches キーワードを使用してブランチによるフィルターを指定できます。

name: My workflow on: schedule: - cron: '0 8 * * *' push: branches: - main pull_request: branches: - mybranch

ジョブの実行トリガーを設定するには、 startOn キーワードを使用する必要があります。次のトリガーがサポートされています。

  • Git プッシュ (デフォルトで有効)。

  • スケジュール(メインブランチのみ)。

  • Git ブランチは削除されます。

  • コードレビューはオープンまたはクローズされます (メインブランチのみ)。

ブランチでフィルターを明示的に指定することはできません。自動化は、すべてのブランチで .space.kts のトリガーのリストを調べます。特定のブランチでトリガーを無効にしたい場合は、.space.kts で実行する必要があります。

job("My job") { startOn { schedule { cron("0 8 * * *") } codeReviewOpened {} } }

ファイルの共有

GitHub アクション

Space Automation

upload-artifact(英語) および download-artifact(英語) アクションを使用して、ジョブ間でファイルを共有できます。例:

jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: ... - uses: actions/upload-artifact@main with: name: step-artifacts path: public/ test: needs: build runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/download-artifact@main with: name: step-artifacts path: public - name: ...

特別な API を使用するか、コンテナーの /mnt/space/share ディレクトリを介して直接ジョブ間でファイルを共有できます。

job("Example shell scripts") { container(image = "ubuntu") { shellScript { content = """ ./gradlew build cp -R ./output /mnt/space/share/output """ } } container(image = "ubuntu") { shellScript { content = """ echo Ouput content ls /mnt/space/share/output """ } } }

パラメーターの共有

GitHub アクション

Space Automation

1 つのアクションの出力を次のアクションの入力として指定できます。以下の例では、joke-action には出力 joke-output があります。

name: JS Actions on: push jobs: action: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: ha-ha uses: ./.github/actions/joke-action id: jokes - name: create-issue uses: ./.github/actions/issue-maker with: repo-token: ${{secrets.GITHUB_TOKEN}} joke: ${{steps.jokes.outputs.joke-output}}

ジョブ内のすべてのステップはパラメーターストレージを共有します。ストレージにアクセスするには、parameters API を使用する必要があります。

job("Reuse params") { container(displayName = "Set param", image = "amazoncorretto:17-alpine") { kotlinScript { api -> api.parameters["joke"] = "funny" } } container(displayName = "Use param", image = "amazoncorretto:17-alpine") { kotlinScript { api -> println("Here's the joke: ${api.parameters["joke"]}!") } } }

パッケージの公開

GitHub アクション

Space Automation

GitHub は、独自のパッケージリポジトリマネージャー GitHub パッケージを提供します。ワークフローはこれを使用してパッケージを取得および公開できます。これを行うには、特別なアクションを使用します (または、対応する外部ツールを使用する独自のアクションを作成します)。GitHub パッケージで認証するには、github.actor パラメーターと GITHUB_TOKEN シークレットを使用する必要があります。例: Docker イメージを公開する方法は次のとおりです。

- name: Build container image uses: docker/build-push-action@v1 with: username: ${{github.actor}} password: ${{secrets.GITHUB_TOKEN}} registry: docker.pkg.github.com repository: UserName/my_project/my_package tag_with_sha: true

Space のパッケージリポジトリマネージャーは、Space Packages と呼ばれます。一部の自動化シナリオでは認証が必要ありません。例: Docker の場合、オートメーションは特別な API を提供し、パッケージでの認証は必要ありません。

job("Build and push Docker") { docker { build { args["HTTP_PROXY"] = "http://10.20.30.2:1234" labels["vendor"] = "mycompany" } push("mycompany.registry.jetbrains.space/p/prj/mydocker/myimage") { tag = "version1.0" } } }

ただし、認証資格情報の提供が必要な場合があります。例: Gradle では、資格情報を build.gradle で指定する必要があります。これは、環境変数 JB_SPACE_CLIENT_ID および JB_SPACE_CLIENT_SECRET を使用して行うことができます。たとえば、build.gradle :

publishing { repositories { maven { credentials { username = "$System.env.JB_SPACE_CLIENT_ID" password = "$System.env.JB_SPACE_CLIENT_SECRET" } url = "https://maven.pkg.jetbrains.space/mycompany/p/projectkey/my-maven-repo" } } }

他の製品サブシステムの使用

GitHub と JetBrains Space には、プロジェクトリポジトリ、課題追跡、CI/CD などの複数のサブシステムが含まれています。GitHub アクションと Space Automation の両方を使用すると、ビルドスクリプトからこれらのサブシステムにアクセスできます。

GitHub アクション

Space Automation

JavaScript コードを使用したカスタムアクションでは、他のサブシステムと連携できます。GitHub アクションは、アクションで参照する必要がある別の npm モジュールでサブシステム API を提供します。例: コア機能は @actions/core パッケージで利用できます。アクションを作成した後、npm install --save @actions/core @actions/github を実行して依存関係をインストールする必要があります。アクションの .js ファイルで、パッケージを参照します。

const core = require("@actions/core"); const github = require("@actions/github");

GitHub サブシステムを操作できる公式クライアント oktokit もあります。例: これを使用してカスタムデータで新しい課題を作成する方法は次のとおりです。

const core = require("@actions/core"); const github = require("@actions/github"); async function run() { try { const issueTitle = core.getInput("issue-title"); const jokeBody = core.getInput("joke"); const token = core.getInput("repo-token"); const octokit = github.getOctokit(token); const newIssue = await octokit.issues.create({ repo: github.context.repo.repo, owner: github.context.repo.owner, title: issueTitle, body: jokeBody }); } catch (err) { core.setFailed(err.message); } } run()

Space では、各サブシステムにアクセスするための API が提供されます。.space.kts では、Kotlin HTTP API クライアントにアクセスして、任意のサブシステムを呼び出すことができます。例: チャットにメッセージを送信するには:

job("build and publish") { container(image = "gradle") { kotlinScript { api -> try { api.gradle("build") } catch (ex: Exception) { val recipient = MessageRecipient.Channel(ChatChannel.FromName("CI-channel")) val content = ChatMessage.Text("Build failed") api.space().chats.messages.sendMessage(recipient, content) } } } }

サービスの利用

GitHub アクション

Space Automation

例: PostgreSQL でサービスコンテナーを実行する方法は次のとおりです。

jobs: container-job: runs-on: ubuntu-latest container: node:10.18-jessie services: # Label used to access the service container postgres: image: postgres env: POSTGRES_PASSWORD: 1234

サービス(英語)は、ジョブを実行するコンテナー内の別のコンテナーで実行されます。ネットワークリソースはコンテナー間で共有されます。サービスコンテナーのホスト名はラベルによって定義されます (この例では postgres)。

例: PostgreSQL でサービスコンテナーを実行する方法は次のとおりです。

job("service") { container(image = "node:10.18-jessie") { service("postgres") { env["POSTGRES_PASSWORD"] = "1234" } } }

サービスは、ステップを実行するコンテナー内の別のコンテナーで実行されます。ネットワークリソースはコンテナー間で共有されます。サービスコンテナーのホスト名はイメージ名によって定義されます (この例では postgres)。

シークレットとパラメーター

GitHub アクション

Space Automation

プロジェクトまたは組織レベルでシークレット(英語)を作成できます。アクションでシークレットを使用できるようにするには、ワークフローファイルの入力変数または環境変数としてシークレットを設定する必要があります。

name: Secrets on: push jobs: use_secrets: runs-on: ubuntu-latest steps: - shell: bash env: MY_SECRET: ${{ secrets.MySecret }} run: | echo My secret is "$MY_SECRET"

シークレットとパラメーターはプロジェクトレベルでのみ作成できます。シークレットとパラメーターにアクセスするには、環境変数と特別な API を使用する必要があります。

job("Use secrets") { container(image = "ubuntu:latest") { env["MY_SECRET"] = Secrets("my-secret") shellScript { content = "echo My secret is ${'$'}MY_SECRET" } } }

カスタムワークフロー

GitHub アクション

Space Automation

CI/CD とは別に、カスタムワークフロー、つまりシステム内のさまざまなイベントによってトリガーされ、システム状態を変更できるカスタムシナリオを作成できます。見た目: カスタムワークフローを含む .yml ファイルをプロジェクトの .github/workflows ディレクトリに配置します。ファイルでは、ワークフローをトリガーする方法を指定します (システム内の任意のイベントにすることができます。トリガーイベントを参照)。例: 事前に設定された数の承認を取得した後、プルリクエストにラベルを追加できます。

まだ利用できません。

計画内容: Space Webhook によってトリガーできるカスタムオートメーションワークフローを作成できます。.space.kts と同様に、Space HTTP API クライアントにアクセスでき、これを使用して Space でのあらゆるアクション (チャットへのメッセージの送信、ドキュメントまたはブログ投稿の作成、コードレビューの作成と終了など) を実行できます。

ビルドマトリックスの実行

GitHub アクション

Space Automation

strategy.matrix を使用すると、さまざまなジョブ構成を実行できます。例: 異なるフレームワークバージョンのビルドを実行します。

strategy: matrix: node: [6, 8, 10] steps: - uses: actions/setup-node@v1 with: # The Node.js version to configure node-version: ${{ matrix.node }}

まだ利用できません。回避策として、バージョンごとに 1 つずつ、多数のジョブを作成できます。

ユーザーインターフェース

GitHub アクション

Space Automation

UI は、特定のプロジェクトのアクションタブで表されます。ここでは、ワークフローログの表示、ワークフロー実行の実行とキャンセル、アーティファクトの表示を行うことができます。テスト結果はログの形式でのみ入手できます。

UI は、特定のプロジェクトのジョブページで表されます。ここでは、ジョブの表示、実行、キャンセル、アーティファクトの表示などを行うことができます。テスト結果は表とともに表示され、失敗したテストをすぐに確認できます。

サンプルスクリプト: Hello World

GitHub アクション

Space Automation

「hello-world」コンテナーの使用:

./.github/workflows/main.yml

name: Hello World on: push jobs: build: name: Hello world action runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - uses: ./action-a

./action-a/action.yml

name: "Hello Actions" description: "Say hello" author: "me@example.com" runs: using: "docker" image: "hello-world"

「hello-world」コンテナーの使用

job("Hello world") { container(image = "hello-world") }

echo コマンドを使用します。

name: Hello World on: push jobs: build: name: Hello world action runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - name: Hello from vm run: echo Hello world!

echo コマンドを使用します。

job("Hello world") { container(image = "ubuntu") { shellScript { content = "echo Hello world!" } } }

サンプルスクリプト: Gradle を使用してテストを構築して実行する

GitHub アクション

Space Automation

まず、setup-java アクションを使用して仮想マシンで Java を構成し、次にプロジェクトの Gradle ラッパーを実行する必要があります。

name: Java CI on: [push] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Set up JDK 1.8 uses: actions/setup-java@v1 with: java-version: 1.8 - name: Build with Gradle run: ./gradlew build

特別な gradlew 構文シュガーを使用して、Java が搭載されたコンテナー内の Gradle ラッパーにビルドコマンドを渡します。

job("Build and run tests") { gradlew("amazoncorretto:17-alpine", "build") }

サンプルスクリプト: Docker イメージを構築して公開する

GitHub アクション

Space Automation

Build-and-Push-Docker-Image: runs-on: ubuntu-latest needs: test name: Docker Build, Tag, Push steps: - name: Checkout uses: actions/checkout@v1 - name: Build container image uses: docker/build-push-action@v1 with: username: ${{github.actor}} password: ${{secrets.GITHUB_TOKEN}} registry: docker.pkg.github.com repository: UserName/myproject/mypackage tag_with_sha: true

特別な docker 構文シュガーを使用します。

job("Build and push Docker") { docker { build { context = "docker" file = "./docker/Dockerfile" args["HTTP_PROXY"] = "http://10.20.30.2:1234" labels["vendor"] = "mycompany" } push("mycompany.registry.jetbrains.space/p/myproject/myrepo/myimage") { tag = "version1.0" } } }