手順

1. Red Hat CodeReady Workspaces URL に移動し、Red Hat CodeReady Workspaces ログインページを表示します。
2. OpenShift OAuth オプションを選択します。
3. Authorize Access ページが表示されます。
4. Allow selected permissions ボタンをクリックします。
5. アカウント情報を更新します。Username、Email、First name、および Last name フィールドを指定し、Submit ボタンをクリックします。

手順

1. Red Hat CodeReady Workspaces URL に移動し、Red Hat CodeReady Workspaces ログインページを表示します。
2. Register as a new user オプションを選択します。
3. アカウント情報を更新します。Username、Email、First name、および Last name フィールドを指定し、Submit ボタンをクリックします。

手順

1. Dashboard の右上隅を使用して、ユーザーのポップアップメニューを開きます。
2. Copy crwctl login コマンド オプションを選択します。
3. 通知メッセージThe login command copied to clipboardが表示されるのを待ちます。

4. login コマンドをターミナルに貼り付け、ログインが正常に実行されることを確認します。

   $ crwctl auth:login ...
   Successfully logged into <server> as <user>

手順

1. checluster CR (カスタムリソース) から CodeReady Workspaces クラスター URL を取得するには、以下を実行します。

   $ oc get checluster --output jsonpath='{.items[0].status.cheURL}'

2. または、OpenShift ログから CodeReady Workspaces クラスター URL を取得するには、以下を実行します。

   $ oc logs --tail=10 `(oc get pods -o name | grep operator)` | \
     grep "available at" | \
     awk -F'available at: ' '{print $2}' | sed 's/"//'

手順

1. CodeReady Workspaces がデプロイされている URL に移動します。

2. 証明書を保存します。

   1. アドレスバーの左側にある警告または開いたロックアイコンをクリックします。
   2. Certificates をクリックし、Details タブに移動します。

   3. 必要な Root 認証局である最上位の証明書を選択し（下位から古い証明書をエクスポートしないでください）、エクスポートします。

      • Linux の場合は、Export ボタンをクリックします。
      • Windows の場合は、Save to file ボタンをクリックします。
3. Privacy and security セクションで Google Chrome Certificates settings に移動し、Authorities タブに移動します。
4. Import ボタンをクリックし、保存された証明書ファイルを開きます。
5. Trust this certificate for identifying websites を選択し、OK ボタンをクリックします。
6. CodeReady Workspaces 証明書をブラウザーに追加すると、アドレスバーの URL の横に閉じたロックアイコンが表示され、セキュアな接続であることが示唆されます。

手順

1. CodeReady Workspaces がデプロイされている URL に移動します。

2. 証明書を保存します。

   1. アドレスバーの左側にあるロックアイコンをクリックします。
   2. Certificates をクリックします。
   3. 使用する証明書を選択し、表示される大きなアイコンをデスクトップにドラッグします。
3. Keychain Access アプリケーションを開きます。
4. System キーチェーンを選択し、保存された証明書ファイルをこれにドラッグします。
5. インポートした CA をダブルクリックして Trust に移動し、When using this certificate: Always Trust を選択します。
6. 追加した証明書を有効にするためにブラウザーを再起動します。

手順

1. CodeReady Workspaces がデプロイされている URL に移動します。

2. 証明書を保存します。

   1. アドレスバーの左側にあるロックアイコンをクリックします。
   2. Connection not secure という警告の横にある > ボタンをクリックします。
   3. More information ボタンをクリックします。
   4. Security タブの View Certificate ボタンをクリックします。
   5. 2 番目の証明書タブを選択します。証明書の Common Name は ingress-operator で開始する必要があります。
   6. PEM(cert) リンクをクリックし、証明書を保存します。
3. about:preferences に移動し、certificates を検索して View Certificates をクリックします。
4. Authorities タブに移動し、Import ボタンをクリックしてから、保存した証明書ファイルを開きます。
5. Trust this CA to identify websites にチェックマークを付け、OK をクリックします。
6. 追加した証明書を有効にするために Firefox を再起動します。
7. CodeReady Workspaces 証明書をブラウザーに追加すると、アドレスバーの URL の横に閉じたロックアイコンが表示され、セキュアな接続であることが示唆されます。

手順

1. Topology ビューを開き、すべてのプロジェクトを一覧表示します。
2. Select an Application 検索フィールドに workspace と入力してすべてのワークスペースを一覧表示します。

3. ワークスペースをクリックして編集します。

   デプロイメントは、円形のボタンで囲まれたグラフィカルな円で表示されます。これらのボタンの 1 つは Edit Source Code です。

   
4. CodeReady Workspaces を使用してアプリケーションのコードを編集するには、Edit Source Code ボタンをクリックします。これにより、アプリケーションコンポーネントのクローン作成されたソースコードのあるワークスペースにリダイレクトされます。

手順

1. メイン画面の右上にある 3 x 3 マトリックスアイコンを使用して、Red Hat Applications メニューを開きます。

   ドロップダウンメニューには、利用可能なアプリケーションが表示されます。

   
2. CodeReady Workspaces リンクをクリックして、CodeReady Workspaces Dashboard を開きます。

1. Debug → Add Configuration をクリックして、launch 設定のデバッグまたはプロジェクトへの追加を行います。

   

2. ポップアップメニューから、デバッグするアプリケーションの適切な設定を選択します。

   

3. 属性を変更または追加して、設定を更新します。

   

4. ブレークポイントは、エディターのマージンを選択して切り替えることができます。

   

5. ブレークポイントメニューを開いたら、Edit Breakpoint コマンドを使用して条件を追加します。

   

   IDE に Expresion 入力フィールドが表示されます。

   

6. デバッグを開始するには、View→Debug をクリックします。

   

7. Debug ビューで設定を選択し、F5 を押してアプリケーションをデバッグします。または、Ctrl+F5 を押してデバッグせずにアプリケーションを起動します。

   

1. tasks.json または launch.json 設定ファイルを編集します。

2. 設定ファイルに新規の定義を追加するか、既存の定義を変更します。

   注記

   変更内容は設定ファイルに保存されます。

3. プラグインで提供されるタスク設定をカスタマイズするには、Terminal → Configure Tasks メニューオプションを選択して、設定するタスクを選択します。設定は tasks.json ファイルにコピーされ、編集に利用できます。

1. Visual Studio Code Git 拡張で提供される clone コマンドを使用します。

1. cd コマンドを使用して、宛先フォルダーに移動します。

2. git clone を使用して、リポジトリーのクローンを作成します。

   $ git clone <link>

   Red Hat CodeReady Workspaces は Git の自己署名された TLS 証明書をサポートします。詳細は、自己署名証明書を使用した Git リポジトリーをサポートする CodeReady Workspaces のデプロイを参照してください。

手順

1. CodeReady Workspaces Dashboard に移動します。「Dashboard を使用した CodeReady Workspaces のナビゲーション」 を参照してください。
2. 左側のナビゲーションパネルで Create Workspace に移動します。

3. Quick Add タブをクリックします。

   ギャラリーには、ビルドして実行するサンプルプロジェクトを一覧表示しています。

4. ワークスペースを起動するには、事前に作成した devfile のセットからサンプルプロジェクトを選択します。

手順

1. CodeReady Workspaces Dashboard に移動します。「Dashboard を使用した CodeReady Workspaces のナビゲーション」 を参照してください。
2. 左側のナビゲーションパネルで Create Workspace に移動します。
3. Custom Workspace タブをクリックします。

4. ワークスペースの Name を定義します。

   新規ワークスペース名

   ワークスペース名は、スタックの基礎となる devfile に基づいて自動生成できます。生成される名前は、常にプレフィックスおよび 4 つのランダムな文字としての devfile metadata.generateName のプロパティーで構成されます。

5. Devfile セクションで、プロジェクトのビルドおよび実行に使用される devfile テンプレートを選択します。

   
6. ワークスペースを起動します。フォームの下部にある Create & Open ボタンをクリックします。

手順

1. URL \https://codeready-<openshift_deployment_name>.<domain_name>/#https://<yourhosturl>/devfile.yaml を開いてワークスペースを実行します。

手順

1. URL \https://codeready-<openshift_deployment_name>.<domain_name>/f?url=https://<hostURL>/devfile.yaml&override.<parameter.path>=<value> に移動してワークスペースを開きます。

検証手順

1. CodeReady Workspaces ダッシュボードで、新たに作成されたワークスペースの Devfile タブに移動し、コンテンツを検査します。

手順

1. URL \https://codeready-<openshift_deployment_name>.<domain_name>/f?url=https://<hostURL>/devfile.yaml&workspaceDeploymentLabels=<url_encoded_comma_separated_key_values>&workspaceDeploymentAnnotations=<url_encoded_comma_separated_key_values override> に移動してワークスペースを開きます。

1. ユーザーの namespace の名前を取得します。

1. CodeReady Workspaces Dashboard を使用して、Workspaces タブに移動し、OpenShift namespace フィールドの名前を読み取ります。

1. クラスターにログインします。

   1. checluster CR (カスタムリソース) から CodeReady Workspaces クラスター URL を取得するには、以下を実行します。

      $ oc get checluster --output jsonpath='{.items[0].status.cheURL}'

   2. ログイン:

      $ oc login -u <username> -p <password> <cluster_URL>

1. 最初の手順の OpenShift namespace 名を使用して、プロジェクトのすべてのデプロイメントのデプロイメントラベルとアノテーションを表示します。

   $ oc get deployment -n <NAMESPACE> -o=custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,LABELS:.metadata.labels,ANNOTATIONS:.metadata.annotations"

1. ワークスペースを起動してから、コマンドパレットまたは Welcome 画面で Git: Clone コマンドを使用して、プロジェクトを実行中のワークスペースにインポートします。

   

2. F1、CTRL-SHIFT-P、または Welcome 画面に表示されるリンクを使用して、コマンドパレットを開きます。

   

3. クローンを作成するプロジェクトのパスを入力します。

   

手順

1. CodeReady Workspaces Dashboard に移動します。「Dashboard を使用した CodeReady Workspaces のナビゲーション」 を参照してください。
2. 左側のナビゲーションパネルで Workspaces に移動します。
3. ワークスペースの名前をクリックして、設定の概要ページに移動します。

4. Overview タブをクリックし、以下の操作を実行します。

   • Workspace name を変更します。
   • Storage Type を選択します。
   • プロジェクト を確認します。
5. Devfile タブで、ワークスペースの YAML 設定を編集します。「devfile バージョン 2のオーサリング」 を参照してください。

1. Workspaces ページに移動し、更新されるワークスペースをクリックします。
2. Devfile タブを開きます。

3. Devfile editor で、必要なプロジェクトを指定して projects セクションを追加します。

   

4. プロジェクトを追加したら、Save ボタンをクリックしてこのワークスペース設定を保存します。

   デモの例は、以下を参照してください。

   例: devfile を使用したワークスペースへの .git プロジェクトの追加

   以下のインスタンスでは、プロジェクト crw はユーザーのプロジェクトのサンプルとして機能します。ユーザーは、devfile の name 属性を使用してこのプロジェクトを指定します。location 属性は、Git リポジトリーまたは ZIP アーカイブへの URL で表されるソースリポジトリーを定義します。

   プロジェクトをワークスペースに追加するには、以下のセクションを追加または編集します。

   projects:
     - name: <crw>
       source:
         type: git
         location: 'https://github.com/<github-organization>/<crw>.git'

   詳細は、「devfile リファレンス」 のセクションを参照してください。

手順

1. CodeReady Workspaces Dashboard に移動します。「Dashboard を使用した CodeReady Workspaces のナビゲーション」 を参照してください。
2. 左側のナビゲーションパネルで Workspaces に移動します。
3. 実行していないワークスペースの名前をクリックし、概要ページに移動します。

4. ページ右上の Run ボタンをクリックします。

   ワークスペースが起動し、ブラウザーはワークスペースに移動しません。

手順

1. CodeReady Workspaces Dashboard に移動します。「Dashboard を使用した CodeReady Workspaces のナビゲーション」 を参照してください。
2. 左側のナビゲーションパネルで Workspaces に移動します。
3. 実行していないワークスペースの名前をクリックし、概要ページに移動します。

4. ページ右上にある Open ボタンをクリックします。

   ワークスペースが起動し、ブラウザーはワークスペースに移動します。

手順

1. CodeReady Workspaces Dashboard に移動します。「Dashboard を使用した CodeReady Workspaces のナビゲーション」 を参照してください。
2. 左側のナビゲーションパネルの Recent Workspaces セクションで、実行していないワークスペースの名前を右クリックし、コンテキストメニューで Run をクリックしてこれを起動します。

手順

1. 最も簡単な devfile を作成します。

   apiVersion: 1.0.0
   metadata:
    name: minimal-workspace 1

   1

   minimal-workspace の名前を指定します。CodeReady Workspaces サーバーがこの devfile を処理すると、devfile はデフォルトのエディター (Che-Theia) とデフォルトのエディタープラグイン (ターミナルなど) のみを持つ最小の CodeReady Workspaces ワークスペースに変換されます。

2. OpenShift アプリケーションをワークスペースに追加するには、devfile を変更して Kubernetes コンポーネントタイプを追加します。

   たとえば、NodeJS-Mongo アプリケーションを minimal-workspace に組み込むには、以下を実行します。

   apiVersion: 1.0.0
   metadata:
    name: minimal-workspace
   components:
    - type: openshift
      reference: https://raw.githubusercontent.com/.../mongo-db.yaml
    - alias: nodejs-app
      type: openshift
      reference: https://raw.githubusercontent.com/.../nodejs-app.yaml
      entrypoints:
        - command: ['sleep']  1
          args: ['infinity']

   1

   sleep infinity コマンドは、Node.js アプリケーションのエントリーポイントとして追加されます。このコマンドは、ワークスペースの開始フェーズでアプリケーションが起動しないようにします。この設定により、ユーザーはテストまたはデバッグ目的で必要に応じてアプリケーションを起動できます。

3. devfile にコマンドを追加して、開発者のアプリケーションのテストをより容易にします。

   apiVersion: 1.0.0
   metadata:
     name: nodejs-with-db
   projects:
     - name: nodejs-mongo-app
       source:
         type: git
         location: 'https://github.com/ijason/NodeJS-Sample-App.git'
         commitId: 187d468 # refers to the last commitId the project compiles (with express3)
   components:
     - type: openshift
       reference: https://raw.githubusercontent.com/redhat-developer/devfile/master/samples/web-nodejs-with-db-sample/mongo-db.yaml
     - alias: nodejs-app
       type: openshift
       reference: https://raw.githubusercontent.com/redhat-developer/devfile/master/samples/web-nodejs-with-db-sample/nodejs-app.yaml
   commands:
     - name: run 1
       actions:
         - type: exec
           component: nodejs-app
           command: cd ${CHE_PROJECTS_ROOT}/nodejs-mongo-app/EmployeeDB/ && npm install && sed -i -- ''s/localhost/mongo/g'' app.js && node app.js

   1

   devfile に追加された run コマンドは、コマンドパレットから Che-Theia のタスクとして利用できます。実行すると、コマンドは Node.js アプリケーションを起動します。

4. devfile を使用してワークスペースを作成し、起動します。

   $ crwctl workspace:start --devfile <devfile-path>

手順

1. ワークスペースの作成後に、Workspace メニューを使用して必要なワークスペースをクリックします。
2. ワークスペース devfile を変更し、Devfile タブを使用します。
3. OpenShift コンポーネントを追加します。
4. 変更を有効にするには、devfile を保存して、CodeReady Workspaces ワークスペースを再起動します。

手順

1. devfile を生成するには、以下を使用します。

   $ crwctl devfile:generate

   • crwctl devfile:generate コマンドを使用して、NodeJS コンポーネントが含まれる NodeJS-MongoDB アプリケーションなどから devfile を生成することもできます。

     例:

     $ crwctl devfile:generate --selector="app=nodejs"
     apiVersion: 1.0.0
     metadata:
       name: crwctl-generated
     components:
       - type: kubernetes
         alias: app=nodejs
         referenceContent: |
           kind: List
           apiVersion: v1
           metadata:
             name: app=nodejs
           items:
             - apiVersion: apps/v1
               kind: Deployment
               metadata:
                 labels:
                   app: nodejs
                 name: web
     (...)

     Node.js アプリケーションの YAML 定義は、referenceContent 属性を使用し、devfile のインラインで利用できます。

   • 言語のサポートを追加するには、--language パラメーターを使用します。

     $ crwctl devfile:generate --selector="app=nodejs" --language="typescript"
     apiVersion: 1.0.0
     metadata:
       name: crwctl-generated
     components:
       - type: kubernetes
         alias: app=nodejs
         referenceContent: |
           kind: List
           apiVersion: v1
     (...)
       - type: chePlugin
         alias: typescript-ls
         id: che-incubator/typescript/latest

2. 生成された devfile を使用して、crwctl で CodeReady Workspaces ワークスペースを起動します。

   $ crwctl workspace:start --devfile=devfile​.yaml

手順

1. CodeReady Workspaces ワークスペースが作成される OpenShift プロジェクトで新規の OpenShift シークレットを作成します。

   • 作成されるシークレットのラベルは、CodeReady Workspaces の che.workspace.provision.secret.labels プロパティーに設定されるラベルのセットと一致する必要があります。デフォルトのラベルは以下の通りです。
   • app.kubernetes.io/part-of: che.eclipse.org

   • app.kubernetes.io/component: workspace-secret:

     注記

     以下の例では、Red Hat CodeReady Workspaces のバージョン 2.1 と 2.2 での target-container アノテーションの使用法の違いについて説明します。

     例:

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: workspace-secret
     ...

     アノテーションは指定のシークレットがファイルとしてマウントされていることを示し、オプションで、シークレットがマウントされるコンテナーの名前を指定します。target-container アノテーションがない場合、シークレットは CodeReady Workspaces ワークスペースのすべてのユーザーコンテナーにマウントされますが、これは CodeReady Workspaces バージョン 2.1 についてのみ 適用されます。

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       annotations:
         che.eclipse.org/target-container: maven
         che.eclipse.org/mount-path: {prod-home}/.m2/
         che.eclipse.org/mount-as: file
       labels:
     ...

     CodeReady Workspaces バージョン 2.2 以降、target-container アノテーションは非推奨となり、ブール値が含まれる automount-workspace-secret アノテーションが導入されました。これは、devfile で上書きされる機能を使用して、デフォルトのシークレットのマウント動作を定義することを目的としています。true の値により、すべてのワークスペースコンテナーへの自動マウントが有効になります。これとは対照的に、false の値は、automountWorkspaceSecrets:true プロパティーを使用して devfile コンポーネントで明示的に要求されるまでマウントプロセスを無効にします。

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       annotations:
         che.eclipse.org/automount-workspace-secret: "true"
         che.eclipse.org/mount-path: {prod-home}/.m2/
         che.eclipse.org/mount-as: file
       labels:
     ...

     OpenShift シークレットのデータには複数の項目が含まれる可能性があり、その名前はコンテナーにマウントされる必要なファイル名と一致する必要があります。

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: workspace-secret
       annotations:
         che.eclipse.org/automount-workspace-secret: "true"
         che.eclipse.org/mount-path: {prod-home}/.m2/
         che.eclipse.org/mount-as: file
     data:
       settings.xml: <base64 encoded data content here>

     これにより、settings.xml という名前のファイルが、すべてのワークスペースコンテナーの /home/jboss/.m2/ パスにマウントされます。

     secret-s マウントパスは、devfile を使用するワークスペースの特定のコンポーネントに対して上書きできます。マウントパスを変更するには、devfile のコンポーネントで、上書きされたシークレット名と必要なマウントパスと一致する名前を使用して追加のボリュームを宣言する必要があります。

     apiVersion: 1.0.0
     metadata:
       ...
     components:
      - type: dockerimage
        alias: maven
        image: maven:3.11
        volumes:
          - name: <secret-name>
            containerPath: /my/new/path
        ...

     このような上書きの場合、コンポーネントはそれらに属するコンテナーを区別するためにエイリアスを宣言し、上書きパスをこれらのコンテナーについてのみに適用する必要があります。

手順

1. CodeReady Workspaces ワークスペースが作成される OpenShift プロジェクトで新規の OpenShift シークレットを作成します。

   • 生成されるシークレットのラベルは、CodeReady Workspaces の che.workspace.provision.secret.labels プロパティーに設定されるラベルのセットと一致する必要があります。デフォルトでは、これは 2 つのラベルのセットになります。
   • app.kubernetes.io/part-of: che.eclipse.org

   • app.kubernetes.io/component: workspace-secret:

     注記

     以下の例では、Red Hat CodeReady Workspaces のバージョン 2.1 と 2.2 での target-container アノテーションの使用法の違いについて説明します。

     例:

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       labels:
         app.kubernetes.io/part-of: che.eclipse.org
         app.kubernetes.io/component: workspace-secret
     ...

     アノテーションは、指定のシークレットが環境変数としてマウントされていることを示す必要があり、オプションでこのマウントが適用されるコンテナー名を指定します。target-container アノテーションが定義されていない場合、シークレットは CodeReady Workspaces ワークスペースのすべてのユーザーコンテナーにマウントされますが、これは CodeReady Workspaces バージョン 2.1 についてのみ 適用されます。

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       annotations:
         che.eclipse.org/target-container: maven
         che.eclipse.org/env-name: FOO_ENV
         che.eclipse.org/mount-as: env
       labels:
        ...
     data:
       mykey: myvalue

     これにより、FOO_ENV という名前の環境変数と値 myvalue が、maven という名前のコンテナーにプロビジョニングされます。

     CodeReady Workspaces バージョン 2.2 以降、target-container アノテーションは非推奨となり、ブール値が含まれる automount-workspace-secret アノテーションが導入されました。これは、devfile で上書きされる機能を使用して、デフォルトのシークレットのマウント動作を定義することを目的としています。true の値により、すべてのワークスペースコンテナーへの自動マウントが有効になります。これとは対照的に、false の値は、automountWorkspaceSecrets:true プロパティーを使用して devfile コンポーネントで明示的に要求されるまでマウントプロセスを無効にします。

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       annotations:
         che.eclipse.org/automount-workspace-secret: "true"
         che.eclipse.org/env-name: FOO_ENV
         che.eclipse.org/mount-as: env
       labels:
        ...
     data:
       mykey: myvalue

     これにより、FOO_ENV という名前の環境変数、および値 myvalue がすべてのワークスペースコンテナーにプロビジョニングされます。

     シークレットに複数のデータ項目がある場合、環境変数の名前は以下のようにそれぞれのデータキーについて指定される必要があります。

     apiVersion: v1
     kind: Secret
     metadata:
       name: mvn-settings-secret
       annotations:
         che.eclipse.org/automount-workspace-secret: "true"
         che.eclipse.org/mount-as: env
         che.eclipse.org/mykey_env-name: FOO_ENV
         che.eclipse.org/otherkey_env-name: OTHER_ENV
       labels:
        ...
     data:
       mykey: myvalue
       otherkey: othervalue

     これにより、FOO_ENV、OTHER_ENV という名前の、myvalue および othervalue の値を持つ 2 つの環境変数がワークスペースコンテナーにプロビジョニングされます。

     注記

     OpenShift シークレットのアノテーション名の最大長さは 63 文字です。ここで、9 文字は、/ で終わるプレフィックス用に予約されます。これは、シークレットに使用できるキーの最大長さの制限として機能します。

手順

1. ストレージフォーマットで git 認証情報ファイルを準備します。
2. ファイルのコンテンツを base64 形式にエンコードします。

3. CodeReady Workspaces ワークスペースが作成される OpenShift プロジェクトで新規の OpenShift シークレットを作成します。

   • 作成されるシークレットのラベルは、CodeReady Workspaces の che.workspace.provision.secret.labels プロパティーに設定されるラベルのセットと一致する必要があります。デフォルトのラベルは以下の通りです。
   • app.kubernetes.io/part-of: che.eclipse.org
   • app.kubernetes.io/component: workspace-secret:

1. REST API URL への呼び出しを使用してシークレットからユーザー ID を取得するには、以下を実行します。

   • Bitbucket の場合:

     https://<bitbucket-hostname>/rest/api/1.0/users/<username>

   • CodeReady Workspaces の場合

     \https://codeready-<openshift_deployment_name>.<domain_name>/api/user

   • シークレットから取得したトークン認証情報に関して、別のシークレットが自動的に作成され、Git 操作に対する認証が可能になります。このシークレットは Git 認証情報ファイルとしてワークスペースコンテナーにマウントされ、プライベート Git リポジトリーと連携するために追加の設定は不要になります。
   • リモート Git リポジトリーが自己署名証明書を使用する場合は、サーバー設定を追加します。自己署名証明書を使用した Git リポジトリーをサポートする CodeReady Workspaces のデプロイを参照してください。

1. シークレットからユーザー ID を取得するには、GitLab Web UI の ユーザープロファイルページを確認するか、REST API URL を呼び出します。

   • GitLab の場合:

     https://<gitlab-hostname>/api/v4/users?username=<username>

   • CodeReady Workspaces の場合

     \https://codeready-<openshift_deployment_name>.<domain_name>/api/user

   • シークレットから取得したトークン認証情報に関して、別のシークレットが自動的に作成され、Git 操作に対する認証が可能になります。このシークレットは Git 認証情報ファイルとしてワークスペースコンテナーにマウントされ、プライベート Git リポジトリーと連携するために追加の設定は不要になります。
   • リモート Git リポジトリーが自己署名証明書を使用する場合は、サーバー設定を追加します。自己署名証明書を使用した Git リポジトリーをサポートする CodeReady Workspaces のデプロイを参照してください。

1. シークレットからユーザー ID を取得するには、REST API URL を呼び出します。

   https://api.github.com/user

   • CodeReady Workspaces の場合

     \https://codeready-<openshift_deployment_name>.<domain_name>/api/user

   • シークレットから取得したトークン認証情報に関して、別のシークレットが自動的に作成され、Git 操作に対する認証が可能になります。このシークレットは Git 認証情報ファイルとしてワークスペースコンテナーにマウントされ、プライベート Git リポジトリーと連携するために追加の設定は不要になります。
   • リモート Git リポジトリーが自己署名証明書を使用する場合は、サーバー設定を追加します。自己署名証明書を使用した Git リポジトリーをサポートする CodeReady Workspaces のデプロイを参照してください。

1. CodeReady Workspaces サーバーは、プラグインがワークスペース定義から起動するかどうかを確認します。
2. CodeReady Workspaces サーバーはプラグインメタデータを取得し、各プラグインタイプを認識し、それらをメモリーに保存します。
3. CodeReady Workspaces サーバーは、プラグインタイプに応じてブローカーを選択します。
4. ブローカーはプラグインのインストールおよびデプロイメントを処理します。プラグインのインストールプロセスは、特定のブローカーごとに異なります。

1. Che-Theia プラグインブローカーは、特定のプラグインが .theia ファイルから必要とするサイドカーコンテナーについての情報を抽出します。
2. ブローカーは、適切なコンテナー情報を CodeReady Workspaces サーバーに送信します。
3. ブローカーは Che-Theia プラグインをボリュームにコピーし、これを Che-Theia エディターコンテナーで利用できるようにします。
4. 次に、CodeReady Workspaces サーバーはワークスペースのすべてのコンテナーを起動します。
5. Che-Theia はそのコンテナーで起動し、プラグインをロードするための適切なフォルダーをチェックします。

Che-Theia プラグインのライフサイクルにおけるユーザーエクスペリエンス

1. ユーザーが Che-Theia のブラウザータブを開くと、Che-Theia は、以下で新しいプラグインセッションを開始します。

   • Web Worker (フロントエンド)
   • Node.js (バックエンド)
2. Che-Theia は、トリガーされたそれぞれのプラグインの start() 関数を呼び出して、すべての Che-Theia プラグインに対して新規セッションの開始を通知します。
3. Che-Theia プラグインセッションが実行され、Che-Theia バックエンドおよびフロントエンドと対話します。
4. ユーザーが Che-Theia ブラウザータブを閉じるか、またはセッションがタイムアウトの制限で終了すると、Che-Theia はすべてのプラグインに対して、トリガーされたそれぞれのプラグインの stop() 関数で通知します。

1. Dashboard の Workspace タブをクリックして、プラグインの宛先ワークスペースを選択します。

   Workspace <workspace-name> ウィンドウが開き、ワークスペースの詳細が表示されます。

2. devfile タブをクリックします。

3. components セクションを見つけ、以下の構造で新規エントリーを追加します。

    - type: chePlugin
      id:              1

   1

   ID フォーマット: <publisher>/<plug-inName>/<plug-inVersion>

   CodeReady Workspaces は、他のフィールドを新規コンポーネントに自動的に追加します。

   または、専用の参照フィールドを使用して、GitHub でホストされる meta.yaml ファイルにリンクできます。

    - type: chePlugin
      reference:              1

   1

   https://raw.githubusercontent.com/<username>/<registryRepository>/v3/plugins/<publisher>/<plug-inName>/<plug-inVersion>/meta.yaml

4. 変更を有効にするには、ワークスペースを再起動します。

手順

1. gist Webページに移動し、README.md ファイルを作成します。これには、説明 Try Bracket Pair Colorizer extension in Red Hat CodeReady Workspaces およびコンテンツ Example VS Code extension を含みます。(Bracket Pair Colorizer はよく使用される VS Code 拡張機能です。)
2. Create secret gist ボタンをクリックします。

3. ブラウザーのナビゲーションバーの URL を使用して、gist リポジトリーのクローンを作成します。

   $ git clone https://gist.github.com/<your-github-username>/<gist-id>

   git clone コマンドの出力例

   git clone https://gist.github.com/benoitf/85c60c8c439177ac50141d527729b9d9 1
   Cloning into '85c60c8c439177ac50141d527729b9d9'...
   remote: Enumerating objects: 3, done.
   remote: Counting objects: 100% (3/3), done.
   remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
   Unpacking objects: 100% (3/3), done.

   1

   各 gist には固有の ID があります。

4. ディレクトリーを変更します。

   $ cd <gist-directory-name> 1

   1

   gist ID に一致するディレクトリー名。

5. VS Code marketplace または GitHub ページ からプラグインをダウンロードし、プラグインファイルをクローン作成されたディレクトリーに保存します。

6. クローン作成されたディレクトリーに plugin.yaml ファイルを作成し、このプラグインの定義を追加します。

   .vsix バイナリーファイルの拡張を参照する plugin.yaml ファイルの例

   apiVersion: v2
   publisher: CoenraadS
   name: bracket-pair-colorizer
   version: 1.0.61
   type: VS Code extension
   displayName: Bracket Pair Colorizer
   title: Bracket Pair Colorizer
   description: Bracket Pair Colorizer
   icon: https://raw.githubusercontent.com/redhat-developer/codeready-workspaces/crw-2-rhel-8/dependencies/che-plugin-registry/resources/images/default.svg?sanitize=true
   repository: https://github.com/CoenraadS/BracketPair
   category: Language
   firstPublicationDate: '2020-07-30'
   spec:                                                             1
     extensions:
     - "{{REPOSITORY}}/CoenraadS.bracket-pair-colorizer-1.0.61.vsix" 2
   latestUpdateDate: "2020-07-30"

   1

   この拡張には基本的な Node.js ランタイムが必要であるため、plugin.yaml にカスタムのランタイムイメージを追加する必要はありません。

   2

   {{REPOSITORY}} は pre-commit フックのマクロです。

7. メモリー制限およびボリュームを定義します。

   spec:
     containers:
       - image: "quay.io/eclipse/che-sidecar-java:8-0cfbacb"
         name: vscode-java
         memoryLimit: "1500Mi"
         volumes:
         - mountPath: "/home/theia/.m2"
           name: m2

8. plugin.yaml ファイルを参照する devfile.yaml を作成します。

   apiVersion: 1.0.0
   metadata:
     generateName: java-maven-
   projects:
     -
       name: console-java-simple
       source:
         type: git
         location: "https://github.com/che-samples/console-java-simple.git"
         branch: java1.11
   components:
     -
       type: chePlugin
       id: redhat/java11/latest
     -
       type: chePlugin 1
       reference: "{{REPOSITORY}}/plugin.yaml"
     -
       type: dockerimage
       alias: maven
       image: quay.io/eclipse/che-java11-maven:nightly
       memoryLimit: 512Mi
       mountSources: true
       volumes:
         - name: m2
           containerPath: /home/user/.m2
   commands:
     -
       name: maven build
       actions:
         -
           type: exec
           component: maven
           command: "mvn clean install"
           workdir: ${CHE_PROJECTS_ROOT}/console-java-simple
     -
       name: maven build and run
       actions:
         -
           type: exec
           component: maven
           command: "mvn clean install && java -jar ./target/*.jar"
           workdir: ${CHE_PROJECTS_ROOT}/console-java-simple

   1

   その他の devfile 定義も使用できます。この devfile の重要な情報は、この外部コンポーネントを定義する行になります。これは、外部参照が (デフォルトプラグインレジストリーの定義を参照する ID ではなく) プラグインを定義することを意味します。

9. 現在の Git ディレクトリーに 4 つのファイルがあることを確認します。

   $ ls -la
   .git
   CoenraadS.bracket-pair-colorizer-1.0.61.vsix
   README.md
   devfile.yaml
   plugin.yaml

10. ファイルをコミットする前に、pre-commit フックを追加して、{{REPOSITORY}} 変数を公開されている外部の未加工 gist リンクに対して更新します。

    1. 以下の内容で .git/hooks/pre-commit ファイルを作成します。

       #!/bin/sh
       
       # get modified files
       FILES=$(git diff --cached --name-only --diff-filter=ACMR "*.yaml" | sed 's| |\\ |g')
       
       # exit fast if no files found
       [ -z "$FILES" ] && exit 0
       
       # grab remote origin
       origin=$(git config --get remote.origin.url)
       url="${origin}/raw"
       
       # iterate on files and add the good prefix pattern
       for FILE in ${FILES}; do
        sed -e "s#{{REPOSITORY}}#${url}#g" "${FILE}" > "${FILE}.back"
        mv "${FILE}.back" "${FILE}"
       done
       
       # Add back to staging
       echo "$FILES" | xargs git add
       
       exit 0

       フックは {{REPOSITORY}} マクロを置き換え、外部の未加工リンクを gist に追加します。

    2. スクリプトを実行可能にします。

       $ chmod u+x .git/hooks/pre-commit

11. ファイルをコミットし、プッシュします。

    # Add files
    $ git add *
    
    # Commit
    $ git commit -m "Initial Commit for the test of our extension"
    [main 98dd370] Initial Commit for the test of our extension
     3 files changed, 61 insertions(+)
     create mode 100644 CoenraadS.bracket-pair-colorizer-1.0.61.vsix
     create mode 100644 devfile.yaml
     create mode 100644 plugin.yaml
    
    # and push the files to the main branch
    $ git push origin

12. gist の Web サイトにアクセスし、すべてのリンクに正しい公開 URL があり、{{REPOSITORY}} 変数が含まれていないことを確認します。devfile に到達するには、以下を実行します。

    $ echo "$(git config --get remote.origin.url)/raw/devfile.yaml"

    または

    $ echo "https://<che-server>/#$(git config --get remote.origin.url)/raw/devfile.yaml"

1. vscode-theia-comparator リポジトリーをクローン作成し、yarn コマンドを使用してこれをビルドします。
2. GITHUB_TOKEN 環境変数をトークンに設定します。
3. yarn run generate コマンドを実行してレポートを生成します。
4. out/status.html ファイルを開き、レポートを表示します。

手順

1. example.server.org でアーティファクトリポジトリーを指定するには、settings.xml ファイルを使用します。

   <settings>
     <profiles>
       <profile>
         <id>my-nexus</id>
         <pluginRepositories>
           <pluginRepository>
              <id>my-nexus-snapshots</id>
              <releases>
                <enabled>false</enabled>
              </releases>
              <snapshots>
                <enabled>true</enabled>
              </snapshots>
              <url>http://example.server.org/repository/maven-snapshots/</url>
           </pluginRepository>
           <pluginRepository>
              <id>my-nexus-releases</id>
              <releases>
                <enabled>true</enabled>
              </releases>
              <snapshots>
                <enabled>false</enabled>
              </snapshots>
              <url>http://example.server.org/repository/maven-releases/</url>
           </pluginRepository>
         </pluginRepositories>
         <repositories>
           <repository>
              <id>my-nexus-snapshots</id>
              <releases>
                <enabled>false</enabled>
              </releases>
              <snapshots>
                <enabled>true</enabled>
              </snapshots>
              <url>http://example.server.org/repository/maven-snapshots/</url>
           </repository>
           <repository>
              <id>my-nexus-releases</id>
              <releases>
                <enabled>true</enabled>
              </releases>
              <snapshots>
                <enabled>false</enabled>
              </snapshots>
              <url>http://example.server.org/repository/maven-releases/</url>
           </repository>
         </repositories>
       </profile>
     </profiles>
     <activeProfiles>
       <activeProfile>my-nexus</activeProfile>
     </activeProfiles>
   </settings>

手順

1. settings.xml を base64 に変換します。

   $ cat settings.xml | base64

2. 出力を新規ファイル secret.yaml にコピーし、必要なアノテーションおよびラベルも定義します。

   apiVersion: v1
   kind: Secret
   metadata:
     name: maven-settings-secret
     labels:
       app.kubernetes.io/part-of: che.eclipse.org
       app.kubernetes.io/component: workspace-secret
     annotations:
       che.eclipse.org/automount-workspace-secret: "true"
       che.eclipse.org/mount-path: /home/jboss/.m2
       che.eclipse.org/mount-as: file
   type: Opaque
   data:
     settings.xml: PHNldHRpbmdzIHhtbG5zPSJodHRwOi8vbWF2ZW4uYXBhY2hlLm9yZy9TRVRUSU5HUy8xLjAuMCIKICAgICAgICAgIHhtbG5zOnhzaT0iaHR0cDovL3d3dy53My5vcmcvMjAwMS9YTUxTY2hlbWEtaW5zdGFuY2UiCiAgICAgICAgICB4c2k6c2NoZW1hTG9jYXRpb249Imh0dHA6Ly9tYXZlbi5hcGFjaGUub3JnL1NFVFRJTkdTLzEuMC4wCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vbWF2ZW4uYXBhY2hlLm9yZy94c2Qvc2V0dGluZ3MtMS4wLjAueHNkIj4KICA8c2VydmVycz4KICAgIDxzZXJ2ZXI+CiAgICAgIDxpZD5yZXBvc2l0b3J5LWlkPC9pZD4KICAgICAgPHVzZXJuYW1lPnVzZXJuYW1lPC91c2VybmFtZT4KICAgICAgPHBhc3N3b3JkPnBhc3N3b3JkMTIzPC9wYXNzd29yZD4KICAgIDwvc2VydmVyPgogIDwvc2VydmVycz4KPC9zZXR0aW5ncz4K

3. このシークレットをクラスターに作成します。

   $ oc  apply -f secret.yaml

4. 新規ワークスペースを起動します。maven コンテナーには、元の内容を含む /home/jboss/.m2/settings.xml ファイルが含まれます。

手順

1. リポジトリーサーバーからサーバー証明書ファイルを取得します。通常、管理者は内部アーティファクトサーバーの証明書を OpenShift シークレットとして提供する必要があります (信頼できない TLS 証明書の CodeReady Workspaces へのインポート を参照してください)。関連するサーバー証明書は、ワークスペース内のすべてのコンテナーの /public-certs にマウントされます。

   1. 元の Java トラストストアファイルをコピーします。

      $ mkdir /projects/maven
      $ cp $JAVA_HOME/lib/security/cacerts /projects/maven/truststore.jks
      $ chmod +w /projects/maven/truststore.jks

   2. 証明書の Java トラストストアファイルへのインポート

      $ keytool -import -noprompt -file /public-certs/nexus.cer -alias nexus -keystore /projects/maven/truststore.jks -storepass changeit
      Certificate was added to keystore

2. トラストストアファイルを追加します。

   • Maven コンテナーで以下を実行します。

     1. javax.net.ssl システムプロパティーを MAVEN_OPTS 環境変数に追加します。

          - mountSources: true
            alias: maven
            type: dockerimage
            ...
            env:
               -name: MAVEN_OPTS
                value: >-
                  -Duser.home=/projects/maven -Djavax.net.ssl.trustStore=/projects/maven/truststore.jks -Djavax.net.ssl.trustStorePassword=changeit

     2. ワークスペースを再起動します。

   • Java プラグインコンテナーで以下を実行します。

     devfile で、Java 言語サーバーの javax.net.ssl システムプロパティーを追加します。

     components:
       - id: redhat/java11/latest
         type: chePlugin
         preferences:
           java.jdt.ls.vmargs: >-
             -noverify -Xmx1G -XX:+UseG1GC -XX:+UseStringDeduplication
             -Duser.home=/projects/maven
             -Djavax.net.ssl.trustStore=/projects/maven/truststore.jks
             -Djavax.net.ssl.trustStorePassword=changeit
     [...]

手順

1. リポジトリーサーバーからサーバー証明書ファイルを取得します。通常、管理者は内部アーティファクトサーバーの証明書を OpenShift シークレットとして提供する必要があります (信頼できない TLS 証明書の CodeReady Workspaces へのインポート を参照してください)。関連するサーバー証明書は、ワークスペース内のすべてのコンテナーの /public-certs にマウントされます。

   1. 元の Java トラストストアファイルをコピーします。

      $ mkdir /projects/maven
      $ cp $JAVA_HOME/lib/security/cacerts /projects/maven/truststore.jks
      $ chmod +w /projects/maven/truststore.jks

   2. 証明書の Java トラストストアファイルへのインポート

      $ keytool -import -noprompt -file /public-certs/nexus.cer -alias nexus -keystore /projects/maven/truststore.jks -storepass changeit
      Certificate was added to keystore

   3. トラストストアファイルを /projects/gradle/truststore.jks にアップロードし、これをすべてのコンテナーで利用可能にします。

2. Gradle コンテナーにトラストストアファイルを追加します。

   1. javax.net.ssl システムプロパティーを JAVA_OPTS 環境変数に追加します。

        - mountSources: true
          alias: maven
          type: dockerimage
          ...
          env:
             -name: JAVA_OPTS
              value: >-
                -Duser.home=/projects/gradle
                -Djavax.net.ssl.trustStore=/projects/maven/truststore.jks
                -Djavax.net.ssl.trustStorePassword=changeit

手順

1. pip サーバーで使用する証明書を Privacy-Enhanced Mail (PEM) 形式で取得します。通常、管理者は内部アーティファクトサーバーの証明書を OpenShift シークレットとして提供する必要があります (信頼できない TLS 証明書の CodeReady Workspaces へのインポート を参照してください)。関連するサーバー証明書は、ワークスペース内のすべてのコンテナーの /public-certs にマウントされます。

   注記

   pip は、Privacy-Enhanced Mail (PEM) 形式の証明書のみを受け入れます。必要に応じて、OpenSSL を使用して証明書を PEM 形式に変換します。

2. devfile を設定します。

    - id: ms-python/python/latest
       memoryLimit: 512Mi
       type: chePlugin
       env:
         - name: 'PIP_INDEX_URL'
           value: 'https://<username>:<password>@pypi.company.com/simple'
         - value: '/projects/tls/rootCA.pem'
           name: 'PIP_CERT'
     - mountSources: true
       memoryLimit: 512Mi
       type: dockerimage
       alias: python
       image: 'registry.redhat.io/codeready-workspaces/plugin-java8-rhel8:2.5'
       env:
         - name: 'PIP_INDEX_URL'
           value: 'https://<username>:<password>@pypi.company.com/simple'
         - value: '/projects/tls/rootCA.pem'
           name: 'PIP_CERT'

手順

1. Privacy-Enhanced Mail (PEM) 形式の Athens サーバーで使用される証明書を取得します。通常、管理者は内部アーティファクトサーバーの証明書を OpenShift シークレットとして提供する必要があります (信頼できない TLS 証明書の CodeReady Workspaces へのインポート を参照してください)。関連するサーバー証明書は、ワークスペース内のすべてのコンテナーの /public-certs にマウントされます。

2. 適切な環境変数を devfile に追加します。

   components:
   - mountSources: true
     type: dockerimage
     alias: go-cli
     image: 'registry.redhat.io/codeready-workspaces/stacks-golang-rhel8:2.5'
     ...
     - value: /tmp/.cache
       name: GOCACHE
     - value: 'http://your.athens.host'
       name: GOPROXY
     - value: '/projects/tls/rootCA.crt'
       name: SSL_CERT_FILE

手順

1. Privacy-Enhanced Mail (PEM) 形式で、.NET サーバーが使用する証明書を取得します。通常、管理者は内部アーティファクトサーバーの証明書を OpenShift シークレットとして提供する必要があります (信頼できない TLS 証明書の CodeReady Workspaces へのインポート を参照してください)。関連するサーバー証明書は、ワークスペース内のすべてのコンテナーの /public-certs にマウントされます。

2. OmniSharp プラグインおよび .NET について、devfile の SSL_CERT_FILE 環境変数で証明書ファイルの場所を指定します。

   devfile の例:

   components:
     - id: redhat-developer/che-omnisharp-plugin/latest
       memoryLimit: 1024Mi
       type: chePlugin
       alias: omnisharp
       env:
        - value: /public-certs/nuget.cer
          name: SSL_CERT_FILE
    - mountSources: true
      endpoints:
        - name: 5000/tcp
          port: 5000
      memoryLimit: 512Mi
      type: dockerimage
      volumes:
        - name: dotnet
          containerPath: /home/jboss
      alias: dotnet
      image: 'quay.io/eclipse/che-dotnet-2.2:7.7.1'
      env:
        - value: /projects/tls/rootCA.crt
          name: SSL_CERT_FILE

手順

1. Dashboard を使用してワークスペースを起動しようとします。
2. 起動に失敗する場合は、表示される Open in Verbose mode リンクをクリックします。
3. Logs タブを確認して、ワークスペースの失敗の理由を見つけます。

手順

1. Workspace タブを開きます。
2. ワークスペース専用の行の左側で、3 つの水平点として表示されるドロップダウンメニューにアクセスし、Open in Verbose mode オプションを選択します。または、このオプションは Actions ドロップダウンメニューでワークスペースの詳細でも利用できます。
3. Logs タブを確認して、ワークスペースの失敗の理由を見つけます。

1. イベントを受信するサーバープロセスの作成
2. CodeReady Workspaces ライブラリーを拡張して、イベントをサーバーに送信するバックエンドを作成する
3. コンテナーでの Telemetry バックエンドのパッケージ化およびイメージレジストリーへのデプロイ
4. バックエンドのプラグインを追加し、CodeReady Workspaces に対してワークスペースにプラグインを読み込むように指示する

1. 新規 Maven Quarkus プロジェクトのスキャフォールディングを作成します。

   $ mvn io.quarkus:quarkus-maven-plugin:1.2.1.Final:create \
     -DprojectGroupId=mygroup -DprojectArtifactId=telemetryback-end \
     -DprojectVersion=my-version -DclassName="org.my.group.MyResource"

2. pom.xmlのorg.eclipse.che.incubator.workspace-telemetry.back-end-baseに依存関係を追加します。

   例9.2 pom.xml

   <dependency>
       <groupId>org.eclipse.che.incubator.workspace-telemetry</groupId>
       <artifactId>backend-base</artifactId>
       <version>0.0.11</version>
   </dependency>
   <dependency>
       <groupId>org.apache.httpcomponents</groupId>
       <artifactId>httpclient</artifactId>
       <version>4.5.12</version>
   </dependency>

3. Apache HTTP コンポーネントライブラリーを追加して、HTTP リクエストを送信します。
4. back-end-base の最新バージョンおよび Maven コーディネートについては、GitHub パッケージを参照してください。GitHub パッケージ には、CodeReady Workspaces Telemetry ライブラリーをダウンロードするために read:packages パーミッションを持つ個人アクセストークンが必要です。個人アクセストークンを作成し、トークンの値をコピーします。

5. リポジトリールートに settings.xml ファイルを作成し、コーディネートとトークンを che-incubator パッケージに追加します。

   例9.3 settings.xml

   <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
   http://maven.apache.org/xsd/settings-1.0.0.xsd">
      <servers>
         <server>
            <id>che-incubator</id>
            <username>${env.GITHUB_USERNAME}</username>
            <password>${env.GITHUB_TOKEN}</password>
         </server>
      </servers>
   
      <profiles>
         <profile>
            <id>github</id>
            <activation>
               <activeByDefault>true</activeByDefault>
            </activation>
            <repositories>
               <repository>
                  <id>central</id>
                  <url>https://repo1.maven.org/maven2</url>
                   <releases><enabled>true</enabled></releases>
                   <snapshots><enabled>false</enabled></snapshots>
                   </repository>
                   <repository>
                   <id>che-incubator</id>
                   <name>GitHub navikt Apache Maven Packages</name>
                   <url>https://maven.pkg.github.com/che-incubator/che-workspace-telemetry-client</url>
                   </repository>
               </repositories>
           </profile>
       </profiles>
       </settings>

   このファイルは、コンテナーでアプリケーションをパッケージ化する際に使用されます。ローカルで実行している場合は、情報を個人の settings.xml ファイルに追加します。