End-user Guide

Procedure

1. Navigate to the Red Hat CodeReady Workspaces URL to display the Red Hat CodeReady Workspaces login page.
2. Choose the OpenShift OAuth option.
3. The Authorize Access page is displayed.
4. Click on the Allow selected permissions button.
5. Update the account information: specify the Username, Email, First name and Last name fields and click the Submit button.

Procedure

1. Navigate to the Red Hat CodeReady Workspaces URL to display the Red Hat CodeReady Workspaces login page.
2. Choose the Register as a new user option.
3. Update the account information: specify the Username, Email, First name and Last name field and click the Submit button.

Procedure

1. Using the upper-right corner of Dashboard, open the user’s pop-up menu.
2. Select the Copy crwctl login command option.
3. Wait for the notification message The login command copied to clipboard to display.

4. Paste the login command into a terminal and observe a successful login:

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

Procedure

1. To retrieve the CodeReady Workspaces cluster URL from the checluster CR (Custom Resource), run:

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

2. Alternatively, to retrieve the CodeReady Workspaces cluster URL from the OpenShift logs, run:

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

Procedure

1. Navigate to URL where CodeReady Workspaces is deployed.

2. Save the certificate:

   1. Click the warning or open lock icon on the left of the address bar.
   2. Click Certificates and navigate to the Details tab.

   3. Select the top-level certificate which is the Root certificate authority and export it:

      • On Linux, click the Export button.
      • On Windows, click the Save to file button.
3. Go to Google Chrome Settings, then to the Authorities tab
4. In the left panel, select Advanced and continue to Privacy and security.
5. At the center of the screen, click Manage certificates and navigate to Authorities tab.
6. Click the Import button and open the saved certificate file.
7. Select Trust this certificate for identifying websites and click the OK button.
8. After adding the CodeReady Workspaces certificate to the browser, the address bar displays the closed lock icon next to the URL, indicating a secure connection.

Procedure

1. Navigate to URL where CodeReady Workspaces is deployed.

2. Save the certificate:

   1. Click the lock icon on the left of the address bar.
   2. Click Certificates.
   3. Select the certificate to use and drag its displayed large icon to the desktop.
3. Open the Keychain Access application.
4. Select the System keychain and drag the saved certificate file to it.
5. Double-click the imported CA, then go to Trust and select When using this certificate: Always Trust.
6. Restart the browser for the added certificated to take effect.

Procedure

1. Navigate to URL where CodeReady Workspaces is deployed.

2. Save the certificate:

   1. Click the lock icon on the left of the address bar.
   2. Click the > button next to the Connection not secure warning.
   3. Click the More information button.
   4. Click the View Certificate button on the Security tab.
   5. Select the second certificate tab. The certificate Common Name should start with ingress-operator
   6. Click the PEM (cert) link and save the certificate.
3. Navigate to about:preferences, search for certificates, and click View Certificates.
4. Go to the Authorities tab, click the Import button, and open the saved certificate file.
5. Check Trust this CA to identify websites and click OK.
6. Restart Firefox for the added certificated to take effect.
7. After adding the CodeReady Workspaces certificate to the browser, the address bar displays the closed lock icon next to the URL, indicating a secure connection.

Procedure

1. Open the Topology view to list all projects.
2. In the Select an Application search field, type workspace to list all workspaces.

3. Click the workspace to edit.

   The deployments are displayed as graphical circles surrounded by circular buttons. One of these buttons is Edit Source Code.

   
4. To edit the code of an application using CodeReady Workspaces, click the Edit Source Code button. This redirects to a workspace with the cloned source code of the application component.

Procedure

1. Open the Red Hat Applications menu by using the three-by-three matrix icon in the upper right corner of the main screen.

   The drop-down menu displays the available applications.

   
2. Click the CodeReady Workspaces link to open the CodeReady Workspaces Dashboard.

1. Click Debug → Add Configuration for debugging or adding of a launch configuration to the project.

   

2. From the pop-up menu, select the appropriate configuration for the application that you are about to debug.

   

3. Update the configuration by modifying or adding attributes.

   

4. Breakpoints can be toggled by selecting the editor margin.

   

5. After opening the breakpoint menu, use the Edit Breakpoint command to add conditions.

   

   The IDE then displays the Expresion input field.

   

6. To start debugging, click View→Debug.

   

7. In the Debug view, select the configuration and press F5 to debug the application. Or, start the application without debugging by pressing Ctrl+F5.

   

1. Edit the tasks.json or launch.json configuration files.

2. Add new definitions to the configuration file or modify the existing ones.

   Note

   The changes are stored in the configuration file.

3. To customize the task configuration provided by plug-ins, select the Terminal → Configure Tasks menu option, and choose the task to configure. The configuration is then copied to the tasks.json file and is available for editing.

1. Use the clone command provided by the Visual Studio Code Git extension.

1. Navigate to destination folder using the cd command.

2. Use git clone to clone a repository:

   $ git clone <link>

   Red Hat CodeReady Workspaces supports Git self-signed TLS certificates. See Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates to learn more.

Procedure

1. Navigate to the CodeReady Workspaces Dashboard. See Section 1.1, “Navigating CodeReady Workspaces using the Dashboard”.
2. In the left navigation panel, go to Get Started.
3. Click the Get Started tab.

4. In the gallery, there is list of samples that may be used to build and run projects.

   

5. Start the workspace: click the chosen stack card.

   

Procedure

1. Navigate to the CodeReady Workspaces Dashboard. See Section 1.1, “Navigating CodeReady Workspaces using the Dashboard”.
2. In the left navigation panel, go to Get Started.
3. Click the Custom Workspace tab.

4. Define a Name for the workspace.

   New workspace name

   Workspace name can be auto-generated based on the underlying devfile of the stack. Generated names always consist of the devfile metadata.generateName property as the prefix and four random characters.

5. In the Devfile section, select the devfile template that will be used to build and run projects.

   
6. Start the workspace: click the Create & Open button at the bottom of the form:

Procedure

1. Execute the workspace by opening the following URL: \https://codeready-<openshift_deployment_name>.<domain_name>/#https://<yourhosturl>/devfile.yaml

Procedure

1. Open the workspace by navigating to the following URL: \https://codeready-<openshift_deployment_name>.<domain_name>/f?url=https://<hostURL>/devfile.yaml&override.<parameter.path>=<value>

Procedure

1. Open the workspace by navigating to the following 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. Start a workspace, then use the Git: Clone command from the command palette or the Welcome screen to import a project to a running workspace.

   

2. Open the command palette by using F1, CTRL-SHIFT-P, or the link displayed on the Welcome screen.

   

3. Enter the path to the project that is about to be cloned.

   

Procedure

1. Navigate to the CodeReady Workspaces Dashboard. See Section 1.1, “Navigating CodeReady Workspaces using the Dashboard”.
2. In the left navigation panel, go to Workspaces.
3. Click the name of a workspace to navigate to the configuration overview page.

4. Click the Overview tab and execute following actions:

   • Change the Workspace name.
   • Select Storage Type.
   • Review OpenShift project.
5. From the Devfile tab, edit YAML configuration of the workspace. See Section 3.6, “Configuring a workspace using a devfile”.

1. Navigate to the Workspaces page and click the workspace, which is about to be updated.
2. Open the Devfile tab.

3. In the Devfile editor, add a projects section with desired project.

   

4. Once the project is added, click the Save button to save this workspace configuration.

   For demonstration example, see below:

   Example - Adding a .git project into a workspace using a devfile

   In the following instance, the project crw acts as the example of a user’s project. A user specifies this project using the name attribute of a devfile. The location attribute defines the source repository represented by an URL to a Git repository or ZIP archive.

   To add a project into the workspace, add or edit the following section:

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

   For additional information, see the Section 3.6.5, “Devfile reference” section.

Procedure

1. Navigate to the CodeReady Workspaces Dashboard. See Section 1.1, “Navigating CodeReady Workspaces using the Dashboard”.
2. In the left navigation panel, navigate to Workspaces.
3. Click on the name of a non-running workspace to navigate to the overview page.

4. Click on the Run button in the top right corner of the page.

   The workspace is started, and a browser does not navigates to the workspace.

Procedure

1. Navigate to the CodeReady Workspaces Dashboard. See Section 1.1, “Navigating CodeReady Workspaces using the Dashboard”.
2. In the left navigation panel, navigate to Workspaces.
3. Click on the name of a non-running workspace to navigate to the overview page.

4. Click on the Open button in the top right corner of the page.

   The workspace is started, and a browser navigates to the workspace.

Procedure

1. Navigate to the CodeReady Workspaces Dashboard. See Section 1.1, “Navigating CodeReady Workspaces using the Dashboard”.
2. In the left navigation panel, in the Recent Workspaces section, right-click the name of a non-running workspace and click Run in the contextual menu to start it.

Procedure

1. Create the simplest devfile:

   apiVersion: 1.0.0
   metadata:
    name: minimal-workspace 1

   1

   Only the name minimal-workspace is specified. After the CodeReady Workspaces server processes this devfile, the devfile is converted to a minimal CodeReady Workspaces workspace that only has the default editor (Che-Theia) and the default editor plug-ins, including, for example, the terminal.

2. To add OpenShift applications to a workspace, modify the devfile and add the Kubernetes component type.

   For example, to embed the NodeJS-Mongo application in the 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

   The sleep infinity command is added as the entrypoint of the Node.js application. The command prevents the application from starting at the workspace start phase. This configuration allows the user to start the application when needed for testing or debugging purposes.

3. Add the commands in the devfile to make it easier for a developer to test the application:

   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

   The run command added to the devfile is available as a task in Che-Theia from the command palette. When executed, the command starts the Node.js application.

4. Use the devfile to create and start a workspace:

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

Procedure

1. After the creation of a workspace, use the Workspace menu and then click on the desired workspace.
2. Modify the workspace devfile, use the Devfile tab.
3. Add a OpenShift component.
4. For the changes to take effect, save the devfile and restart the CodeReady Workspaces workspace.

Procedure

1. To generate a devfile, use:

   $ crwctl devfile:generate

   • It is also possible to generate a devfile from, for example, the NodeJS-MongoDB application that includes the NodeJS component, using the crwctl devfile:generate command:

     Example:

     $ 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
     (...)

     The Node.js application YAML definition is available in the devfile, inline, using the referenceContent attribute.

   • To include support for a language, use the --language parameter:

     $ 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. Use the generated devfile to start a CodeReady Workspaces workspace with crwctl.

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

Procedure

1. Create a new OpenShift secret in the OpenShift project where a CodeReady Workspaces workspace will be created.

   • The labels of the secret that is about to be created must match the set of labels configured in che.workspace.provision.secret.labels property of CodeReady Workspaces. The default labels are:
   • app.kubernetes.io/part-of: che.eclipse.org

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

     Note

     Note that the following example describes variations in the usage of the target-container annotation in versions 2.1 and 2.2 of Red Hat CodeReady Workspaces.

     Example:

     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 must indicate the given secret is mounted as a file, provide the mount path, and, optionally, specify the name of the container in which the secret is mounted. If there is no target-container annotation, the secret will be mounted into all user containers of the CodeReady Workspaces workspace, but this is applicable only for the CodeReady Workspaces version 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:
     ...

     Since the CodeReady Workspaces version 2.2, the target-container annotation is deprecated and automount-workspace-secret annotation with Boolean values is introduced. Its purpose is to define the default secret mounting behavior, with the ability to be overridden in a devfile. The true value enables the automatic mounting into all workspace containers. In contrast, the false value disables the mounting process until it is explicitly requested in a devfile component using the automountWorkspaceSecrets:true property.

     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:
     ...

     Data of the OpenShift secret may contain several items, whose names must match the desired file name mounted into the 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
       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>

     This results in a file named settings.xml being mounted at the /home/jboss/.m2/ path of all workspace containers.

     The secret-s mount path can be overridden for specific components of the workspace using devfile. To change mount path, an additional volume should be declared in a component of the devfile, with name matching overridden secret name, and desired mount path.

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

     Note that for this kind of overrides, components must declare an alias to be able to distinguish containers which belong to them and apply override path exclusively for those containers.

Procedure

1. In the Kubernetes project where a CodeReady Workspaces workspace will be created, generate a new OpenShift secret .

   • The labels of the secret that is about to be generated must match the set of labels configured in che.workspace.provision.secret.labels property of CodeReady Workspaces. By default, it is a set of two labels:
   • app.kubernetes.io/part-of: che.eclipse.org

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

     Note

     Note that the following example describes variations in the usage of the target-container annotation in versions 2.1 and 2.2 of Red Hat CodeReady Workspaces.

     Example:

     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 must indicate that the given secret is mounted as an environment variable, provides variable names, and optionally, specifies the container name where this mount will be applied. If there is no target-container annotation defined, the secret will be mounted into all user containers of the CodeReady Workspaces workspace, but this is applicable only for the CodeReady Workspaces version 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

     This results in the environment variable named FOO_ENV and the value myvalue being provisioned into the container named maven.

     Since the CodeReady Workspaces version 2.2, the target-container annotation is deprecated and automount-workspace-secret annotation with Boolean values is introduced. Its purpose is to define the default secret mounting behavior, with the ability to be overridden in a devfile. The true value enables the automatic mounting into all workspace containers. In contrast, the false value disables the mounting process until it is explicitly requested in a devfile component using the automountWorkspaceSecrets:true property.

     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

     This results in the environment variable named FOO_ENV and the value myvalue being provisioned into all workspace containers.

     If the secret provides more than one data item, the environment variable name must be provided for each of the data keys as follows:

     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

     This results in two environment variables with names FOO_ENV, OTHER_ENV, and values myvalue and othervalue, being provisioned into all workpsace containers.

     Note

     The maximum length of annotation names in a OpenShift secret is 63 characters, where 9 characters are reserved for a prefix that ends with /. This acts as a restriction for the maximum length of the key that can be used for the secret.

Procedure

1. Prepare git credential file in the Storage format.
2. Encode content of the file to the base64 format.

3. Create a new OpenShift secret in the OpenShift project where a CodeReady Workspaces workspace will be created.

   • The labels of the secret that is about to be created must match the set of labels configured in che.workspace.provision.secret.labels property of CodeReady Workspaces. The default labels are:
   • app.kubernetes.io/part-of: che.eclipse.org
   • app.kubernetes.io/component: workspace-secret:

1. To obtain a user ID from a secret using a call to a REST API URL:

   • For Bitbucket:

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

   • For CodeReady Workspaces

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

   • With the token credentials obtained from a secret, another secret is automatically created, allowing authorization to Git operations. This secret is mounted into a workspace container as a Git credentials file, and any additional configurations are not required to work with private Git repositories.
   • When a remote Git repository uses a self-signed certificate, add an additional server configuration. See Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates.

1. To obtain a user ID from a secret, take a look into user profile page on GitLab web UI or make a call to a REST API URL:

   • For GitLab:

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

   • For CodeReady Workspaces

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

   • With the token credentials obtained from a secret, another secret is automatically created, allowing authorization to Git operations. This secret is mounted into a workspace container as a Git credentials file, and any additional configurations are not required to work with private Git repositories.
   • When a remote Git repository uses a self-signed certificate, add an additional server configuration. See: Deploying CodeReady Workspaces with support for Git repositories with self-signed certificates.

1. CodeReady Workspaces server checks for plug-ins to start from the workspace definition.
2. CodeReady Workspaces server retrieves plug-in metadata, recognizes each plug-in type, and stores them in memory.
3. CodeReady Workspaces server selects a broker according to the plug-in type.
4. The broker processes the installation and deployment of the plug-in. The installation process of the plug-in differs for each specific broker.

1. The Che-Theia plug-in broker extracts the information about sidecar containers that a particular plug-in needs from the .theia file.
2. The broker sends the appropriate container information to CodeReady Workspaces server.
3. The broker copies the Che-Theia plug-in to a volume to have it available for the Che-Theia editor container.
4. CodeReady Workspaces server then starts all the containers of the workspace.
5. Che-Theia starts in its container and checks the correct folder to load the plug-ins.

A user experience with Che-Theia plug-in lifecycle

1. When a user opens a browser tab with Che-Theia, Che-Theia starts a new plug-in session with:

   • Web Worker for frontend
   • Node.js for backend
2. Che-Theia notifies all Che-Theia plug-ins with the start of the new session by calling the start() function for each triggered plug-in.
3. A Che-Theia plug-in session runs and interacts with the Che-Theia backend and frontend.
4. When the user closes the Che-Theia browser tab, or the session ended on a timeout limit, Che-Theia notifies all plug-ins with the stop() function for each triggered plug-in.

1. Click the Workspaces tab on the Dashboard and select the plug-in destination workspace.

   The Workspace <workspace-name> window is opened showing the details of the workspace.

2. Click the devfile tab.

3. Locate the components section, and add a new entry with the following structure:

    - type: chePlugin
      id:              1

   1

   ID format: <publisher>/<plug-inName>/<plug-inVersion>

   CodeReady Workspaces automatically adds the other fields to the new component.

   Alternatively, you can link to a meta.yaml file hosted on GitHub, using the dedicated reference field.

    - type: chePlugin
      reference:              1

   1

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

4. Restart the workspace for the changes to take effect.

Procedure

1. Go to the gist webpage and create a README.md file with the following description: Try Bracket Pair Colorizer extension in Red Hat CodeReady Workspaces and content: Example VS Code extension. (Bracket Pair Colorizer is a popular VS Code extension.)
2. Click the Create secret gist button.

3. Clone the gist repository by using the URL from the navigation bar of the browser:

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

   Example of the output of the git clone command

   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

   Each gist has a unique ID.

4. Change the directory:

   $ cd <gist-directory-name> 1

   1

   Directory name matching the gist ID.

5. Download the plug-in from the VS Code marketplace or from its GitHub page, and store the plug-in file in the cloned directory.

6. Create a plugin.yaml file in the cloned directory to add the definition of this plug-in.

   Example of the plugin.yaml file referencing the .vsix binary file extension

   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/master/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

   This extension requires a basic Node.js runtime, so it is not necessary to add a custom runtime image in plugin.yaml.

   2

   {{REPOSITORY}} is a macro for a pre-commit hook.

7. Define a memory limit and volumes:

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

8. Create a devfile.yaml that references the plugin.yaml file:

   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

   Any other devfile definition is also accepted. The important information in this devfile are the lines defining this external component. It means that an external reference defines the plug-in and not an ID, which pointing to a definition in the default plug-in registry.

9. Verify there are 4 files in the current Git directory:

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

10. Before committing the files, add a pre-commit hook to update the {{REPOSITORY}} variable to the public external raw gist link:

    1. Create a .git/hooks/pre-commit file with this content:

       #!/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

       The hook replaces the {{REPOSITORY}} macro and adds the external raw link to the gist.

    2. Make the script executable:

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

11. Commit and push the files:

    # Add files
    $ git add *
    
    # Commit
    $ git commit -m "Initial Commit for the test of our extension"
    [master 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. Visit the gist website and verify that all links have the correct public URL and do not contain any {{REPOSITORY}} variables. To reach the devfile:

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

    or:

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

1. Clone the vscode-theia-comparator repository, and build it using the yarn command.
2. Set the GITHUB_TOKEN environment variable to your token.
3. Execute the yarn run generate command to generate a report.
4. Open the out/status.html file to view the report.

Procedure

1. Clone the che-editor-intellij-community repository, which is needed to build IntelliJ Idea Community Edition located under the che-incubator organization.

2. Build IntelliJ Idea Community Edition by calling the following command inside the repository folder:

   $ podman build -t idea-ic --build-arg PRODUCT_NAME=ideaIC .

   This command builds an image with a 2020.2.3 version by default.

3. Tag and push the built image to a user repository:

   $ podman tag idea-ic:latest <username>/idea-ic:latest
   $ podman push <username>/idea-ic:latest

4. Use this image as the CodeReady Workspaces editor. To achieve this, create two YAML configuration files:

   • workspace.yaml – workspace configuration. Do not forget to provide a correct URL to the meta.yaml file:

     metadata:
       name: che-ideaic
     components:
       - type: cheEditor
         reference: '<URL to the meta.yaml>'
         alias: ideaic-editor
     apiVersion: 1.0.0

   • meta.yaml – CodeReady Workspaces editor configuration. Do not forget to replace <username> with the user name of the repository to which the image is pushed:

     apiVersion: v2
     publisher: <username>
     name: ideaic-NOVNC
     version: 2020.2.3
     type: Che Editor
     displayName:  IntelliJ IDEA Community Edition
     title:  IntelliJ IDEA Community Edition (in browser using noVNC) as editor for Red Hat CodeReady Workspaces
     description:  IntelliJ IDEA Community Edition running on the Web with noVNC
     icon: https://resources.jetbrains.com/storage/products/intellij-idea/img/meta/intellij-idea_logo_300x300.png
     category: Editor
     repository: https://github.com/che-incubator/che-editor-intellij-community
     firstPublicationDate: "2020-10-27"
     spec:
       endpoints:
        - name: "intellij"
          public: true
          targetPort: 8080
          attributes:
            protocol: http
            type: ide
            path: /vnc.html?resize=remote&autoconnect=true&reconnect=true
       containers:
        - name: ideaic-novnc
          image: "<username>/idea-ic:latest"
          mountSources: true
          volumes:
           - mountPath: "/JetBrains/ideaIC"
             name: ideaic-configuration
          ports:
           - exposedPort: 8080
          memoryLimit: "2048M"

Procedure

1. Clone the che-editor-intellij-community repository, which is needed to build IntelliJ Idea Community Edition located under the che-incubator organization.

2. Build IntelliJ Idea Ultimate Edition by calling the following command inside the repository folder:

   $ podman build -t idea-iu --build-arg PRODUCT_NAME=ideaIU .

   This command builds an image with a 2020.2.3 version by default.

3. Tag and push the built image to a user repository:

   $ podman tag idea-iu:latest <username>/idea-iu:latest
   $ podman push <username>/idea-iu:latest

4. Provision the activation code for offline use to be able to use WebStorm with a registered license. See section Section 4.6.4, “Provisioning JetBrains activation code for offline use”.

5. Create a workspace with the following workspace.yaml and meta.yaml files:

   • workspace.yaml – workspace configuration. Do not forget to provide a correct URL to the meta.yaml file:

     metadata:
       name: che-ideaiu
     components:
       - type: cheEditor
         reference: '<URL to the meta.yaml>'
         alias: ideaiu-editor
         automountWorkspaceSecrets: true
     apiVersion: 1.0.0

     Note

     In the current workspace definition, there is a new property: automountWorkspaceSecrets: true. This property instructs Red Hat CodeReady Workspaces to provision secrets into a specific component. In this case, it provisions it into the CodeReady Workspaces editor based on IntelliJ Idea Ultimate Edition. This parameter is mandatory to successfully register the IDE with an activation code for offline use.

   • meta.yaml – CodeReady Workspaces editor configuration. Do not forget to replace <username> with the user name of the repository to which the image is pushed:

     apiVersion: v2
     publisher: <username>
     name: ideaIU-NOVNC
     version: 2020.2.3
     type: Che Editor
     displayName:  IntelliJ IDEA Ultimate Edition
     title:  IntelliJ IDEA Ultimate Edition (in browser using noVNC) as editor for Red Hat CodeReady Workspaces
     description:  IntelliJ IDEA Ultimate Edition running on the Web with noVNC
     icon: https://resources.jetbrains.com/storage/products/intellij-idea/img/meta/intellij-idea_logo_300x300.png
     category: Editor
     repository: https://github.com/che-incubator/che-editor-intellij-community
     firstPublicationDate: "2020-10-27"
     spec:
       endpoints:
        -  name: "intellij"
           public: true
           targetPort: 8080
           attributes:
             protocol: http
             type: ide
             path: /vnc.html?resize=remote&autoconnect=true&reconnect=true
       containers:
        - name: ideaiu-novnc
          image: "<username>/idea-iu:latest"
          mountSources: true
          volumes:
              - mountPath: "/JetBrains/ideaIU"
                name: ideaiu-configuration
          ports:
              - exposedPort: 8080
          memoryLimit: "2048M"

Procedure

1. Clone the che-editor-intellij-community repository, which is needed to build IntelliJ Idea Community Edition located under the che-incubator organization.

2. Build the image:

   $ podman build -t webstorm --build-arg PRODUCT_NAME=WebStorm .

   This command builds an image with a 2020.2.3 version by default.

3. Tag and push the built image to a user repository:

   $ podman tag webstorm:latest <username>/webstorm:latest
   $ podman push <username>/webstorm:latest

4. Provision the activation code for offline use to be able to use WebStorm with a registered license. See section Section 4.6.4, “Provisioning JetBrains activation code for offline use”.

5. Create a workspace with the following workspace.yaml and meta.yaml files:

   • workspace.yaml – workspace configuration. Do not forget to provide a correct URL to the meta.yaml file:

     metadata:
       name: che-webstorm
     components:
       - type: cheEditor
         reference: '<URL to meta.yaml>'
         alias: webstorm-editor
         automountWorkspaceSecrets: true
     apiVersion: 1.0.0

     Note

     In the current workspace definition, there is a new property: automountWorkspaceSecrets: true. This property instructs Red Hat CodeReady Workspaces to provision secrets into a specific component. In this case, it provisions it into the CodeReady Workspaces editor based on IntelliJ Idea Ultimate Edition. This parameter is mandatory to successfully register the IDE with an activation code for offline use.

   • meta.yaml – CodeReady Workspaces editor configuration. Do not forget to replace <username> with the user name of the repository to which the image is pushed:

     apiVersion: v2
     publisher: <username>
     name: webstorm-NOVNC
     version: 2020.2.3
     type: Che Editor
     displayName:  WebStorm
     title:  WebStorm (in browser using noVNC) as editor for Red Hat CodeReady Workspaces
     description:  WebStorm running on the Web with noVNC
     icon: https://resources.jetbrains.com/storage/products/webstorm/img/meta/webstorm_logo_300x300.png
     category: Editor
     repository: https://github.com/che-incubator/che-editor-intellij-community
     firstPublicationDate: "2020-10-27"
     spec:
       endpoints:
        - name: "intellij"
          public: true
          targetPort: 8080
          attributes:
            protocol: http
            type: ide
            path: /vnc.html?resize=remote&autoconnect=true&reconnect=true
       containers:
        - name: webstorm-novnc
          image: "<username>/webstorm:latest"
          mountSources: true
          volumes:
           - mountPath: "/JetBrains/WebStorm"
             name: webstorm-configuration
          ports:
           - exposedPort: 8080
          memoryLimit: "2048M"

Procedure

1. Retrieve the activation code from the JetBrains account:

   

   JetBrains provides a zip archive with two types of the activation code. Use the <License ID> - for 2018.1 or later.txt file:

   
2. Provision the activation code for offline use with Che. This procedure is performed through the OpenShift Secrets.

3. Create a OpenShift Secret to instruct CodeReady Workspaces to mount the activation code into a container based on JetBrains specific product:

   apiVersion: v1
   kind: Secret
   metadata:
     name: <secret name> 1
     labels:
       app.kubernetes.io/component: workspace-secret
       app.kubernetes.io/part-of: che.eclipse.org
     annotations:
       che.eclipse.org/automount-workspace-secret: 'false'
       che.eclipse.org/mount-path: /tmp/
       che.eclipse.org/mount-as: file
   data:
     <product name (ideaIU or WebStorm)>.key: <base64-encoded data content> 2

   1

   <secret name> – The section that specifies the secret name. It may have a different name, for example, ideaiu-offline-activation-code. Provide the secret name in lowercase.

   2

   Product name and activation code:

   • <product name (ideaIU or WebStorm)> – Replace with the JetBrains product name. See section Section 4.6.4.1, “JetBrains product-name mapping”.
   • <base64-encoded data content> – The activation code content encoded in base64.

Procedure

1. Configure your settings.xml file to use artifact repositories at example.server.org:

   <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>

Procedure

1. Convert settings.xml to base64:

   $ cat settings.xml | base64

2. Copy the output to a new file, secret.yaml, which also defines needed annotations and labels:

   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. Create this secret in the cluster:

   $ oc  apply -f secret.yaml

4. Start a new workspace. The maven container contains a file /home/jboss/.m2/settings.xml with your original content.

Procedure

1. Obtain a server certificate file from the repository server. It is customary for administrators to provide certificates of internal artifact servers as OpenShift secrets (see Importing untrusted TLS certificates to CodeReady Workspaces). The relevant server certificates will be mounted in /public-certs in every container in the workspace.

   1. Copy the original Java truststore file:

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

   2. Import the certificate into the Java truststore file

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

2. Add the truststore file.

   • In the Maven container:

     1. Add the javax.net.ssl system property to the MAVEN_OPTS environment variable:

          - 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. Restart the workspace.

   • In the Java plug-in container:

     In the devfile, add the javax.net.ssl system property for the Java language server:

     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
     [...]

Procedure

1. Obtain a server certificate file from the repository server. It is customary for administrators to provide certificates of internal artifact servers as OpenShift secrets (see Importing untrusted TLS certificates to CodeReady Workspaces). The relevant server certificates will be mounted in /public-certs in every container in the workspace.

   1. Copy the original Java truststore file:

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

   2. Import the certificate into the Java truststore file

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

   3. Upload the truststore file to /projects/gradle/truststore.jks to make it available for all containers.

2. Add the truststore file in the Gradle container.

   1. Add the javax.net.ssl system property to the JAVA_OPTS environment variable:

        - 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

Procedure

1. Obtain the certificate used by the pip server in the Privacy-Enhanced Mail (PEM) format. It is customary for administrators to provide certificates of internal artifact servers as OpenShift secrets (see Importing untrusted TLS certificates to CodeReady Workspaces). The relevant server certificates will be mounted in /public-certs in every container in the workspace.

   Note

   pip accepts certificates in the Privacy-Enhanced Mail (PEM) format only. Convert the certificate to the PEM format using OpenSSL if necessary.

2. Configure the 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'

Procedure

1. Obtain the certificate used by the Athens server in the Privacy-Enhanced Mail (PEM) format. It is customary for administrators to provide certificates of internal artifact servers as OpenShift secrets (see Importing untrusted TLS certificates to CodeReady Workspaces). The relevant server certificates will be mounted in /public-certs in every container in the workspace.

2. Add the appropriate environment variables to your 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

Procedure

1. Obtain the certificate used by the .NET server in the Privacy-Enhanced Mail (PEM) format. It is customary for administrators to provide certificates of internal artifact servers as OpenShift secrets (see Importing untrusted TLS certificates to CodeReady Workspaces). The relevant server certificates will be mounted in /public-certs in every container in the workspace.

2. Specify the location of the certificate file in the SSL_CERT_FILE environment variable in your devfile for the OmniSharp plug-in and for the .NET container.

   Example of the 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

Procedure

1. Using Dashboard, try to start a workspace.
2. When it fails to start, click on the displayed Restart in Verbose Mode link.
3. Check the Logs tab to find a reason for the workspace failure.

Procedure

1. Open the Workspaces tab.
2. On the left side of a row dedicated to the workspace, access the drop-down menu displayed as three horizontal dots and select the Open in Verbose Mode option. Alternatively, this option is also available in the workspace details, under the Actions drop-down menu.
3. Check the Logs tab to find a reason for the workspace failure.

1. Creating a server process that receives events
2. Extending CodeReady Workspaces libraries to create a back-end that send events to the server
3. Packaging the telemetry back-end in a container and deploying it to an image registry
4. Adding a plug-in for your back-end and instructing CodeReady Workspaces to load the plug-in in your workspaces

1. Create a new Maven Quarkus project scaffolding:

   $ 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. Add a dependency to org.eclipse.che.incubator.workspace-telemetry.back-end-base in your pom.xml:

   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. Add the Apache HTTP components library to send HTTP requests.
4. Consult the GitHub packages for the latest version and Maven coordinates of back-end-base. GitHub packages require a personal access token with read:packages permissions to download the CodeReady Workspaces telemetry libraries. Create a personal access token and copy the token value.

5. Create a settings.xml file in the repository root and add the coordinates and token to the che-incubator packages:

   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>

   This file is used when packaging the application in a container. When running locally, add the information to your personal settings.xml file.