web-dev-qa-db-ja.com

コンコース：ジョブの出力を別のジョブに渡す方法

ドキュメント から、あるジョブの出力を別のジョブに渡すことが可能かどうかは明確ではありません（タスク間ではなく、ジョブ間）。

概念的に私が正しいことをしているのかどうかはわかりませんが、それはConcourseで別の方法でモデル化する必要があるかもしれませんが、私が達成しようとしているのはJavaプロジェクトをいくつかに分割することです並列実行可能な細かいジョブ。ジョブを再実行する必要がある場合は、独立してトリガーされます。

パイプラインの見方：

  1. 最初の仕事：
    • githubリポジトリからコードをプルします
    • mavenでプロジェクトをビルドします
    • アーティファクトをMavenリポジトリー（mvn deploy）
    • mavenプロジェクトサブモジュールのSNAPSHOTバージョンを更新します
    • アーティファクト（jarファイル）を出力ディレクトリ（outputのtask）にコピーします
  2. 2番目の仕事：
    • jarからoutputをピックアップします
    • それらすべてのDockerコンテナーを（並行して）ビルドします
  3. パイプラインが続く

outputをジョブ1からジョブ2に渡すことができませんでした。また、元のgit repoリソースに加えた変更が次のジョブ（ジョブ1からジョブ2）にあるかどうか知りたいです。 。

だから質問は：

  1. ビルド状態をジョブからジョブに渡す適切な方法は何ですか（ジョブは異なるノードで、そして確かに異なるコンテナーでスケジュールされる可能性があることを知っています）？
  2. 状態をリソース（S3/gitなど）に保存する必要がありますか？
  3. コンコースは（このコンテキストでは）設計上ステートレスですか？
  4. 詳細情報を入手するのに最適な場所はどこですか？私はマニュアルを試しましたが、それはそれほど詳細ではありません。

これまでに見つけたもの：

  1. outputsはジョブからジョブに渡されません
  2. リソースへの変更（putからgithubリポジトリへ）は次のジョブでフェッチされますが、作業コピーの変更はフェッチされません

最小限の例（コメント付きの行がエラーでコメント解除されている場合は失敗します：missing inputs: Gist-upd, Gist-out）：

---
resources:
  - name: Gist
    type: git
    source:
      uri: "[email protected]:snippets/foo/bar.git"
      branch: master
      private_key: {{private_git_key}}

jobs:
  - name: update
    plan:
      - get: Gist
        trigger: true

      - task: update-Gist
        config:
          platform: linux
          image_resource:
            type: docker-image
            source: {repository: concourse/bosh-cli}

          inputs:
            - name: Gist

          outputs:
            - name: Gist-upd
            - name: Gist-out

          run:
            path: sh
            args:
              - -exc
              - |
                git config --global user.email "[email protected]"
                git config --global user.name "Concourse"
                git clone Gist gist-upd
                cd Gist-upd
                echo `date` > test
                git commit -am "upd"
                cd ../Gist
                echo "foo" > test
                cd ../Gist-out
                echo "out" > test

      - put: Gist
        params: {repository: Gist-upd}

  - name: fetch-updated
    plan:
      - get: Gist
        passed: [update]
        trigger: true

      - task: check-Gist
        config:
          platform: linux
          image_resource:
            type: docker-image
            source: {repository: Alpine}

          inputs:
            - name: Gist
            #- name: Gist-upd
            #- name: Gist-out

          run:
            path: sh
            args:
              - -exc
              - |
                ls -l Gist
                cat Gist/test
                #ls -l Gist-upd
                #cat Gist-upd/test
                #ls -l Gist-out
                #cat Gist-out/test
concourse
12
Max Romanovsky

一つ一つの質問に答えること。

  1. すべてのビルド状態は、何らかの外部ストアに保存する必要がある resource の形式でジョブからジョブに渡される必要があります。
  2. なんらかの外部ストアに保管する必要があります。各リソースタイプはこのアップロードとダウンロード自体を処理するため、特定のケースでは、これを確認します maven custom resource type 、これはあなたが望んでいることを実行しているようです。
  3. はい、この無国籍はコンコースの背後にある決定的な特徴です。コンコース内の唯一のステートフルな要素はリソースであり、厳密にバージョン管理され、外部データストアに格納される必要があります。タスクのコンテナ化とリソースの外部ストアを組み合わせると、コンコースが提供する再現性が保証されます。リソースの各バージョンは、ある種のデータストアにバックアップされるため、ciが稼働しているデータセンターが完全に故障する場合でも、各ciビルドの厳密な再現性を維持できます。
  4. より多くの情報を得るために、私はあなたの手を汚し、パイプラインを自分で構築するための何らかのチュートリアルを行うことをお勧めします。スタークとウェインには tutorial があり、便利かもしれません。リソースの理解を助けるために resources tutorial もあります。これは特に役立つでしょう。

また、特定のエラーを取得するために、missing inputsが表示されるのは、コンコースがそれらの各入力に名前が付けられたディレクトリ（リソースgetsによって作成された）を探すためです。したがって、タスクを開始する前に、Gist-updおよびGist-outという名前のgetリソースインスタンスを作成する必要があります。

12
Josh Zarrabi