Chapter 2. Using Dev Spaces in team workflow

download PDF

Learn about the benefits of using OpenShift Dev Spaces in your organization in the following articles:

2.1. Badge for first-time contributors

To enable a first-time contributor to start a workspace with a project, add a badge with a link to your OpenShift Dev Spaces instance.

Figure 2.1. Factory badge


  1. Substitute your OpenShift Dev Spaces URL (https://<openshift_dev_spaces_fqdn>) and repository URL (<your_repository_url>), and add the link to your repository in the project file.

  2. The file in your Git provider web interface displays the factory badge. Click the badge to open a workspace with your project in your OpenShift Dev Spaces instance.

2.2. Reviewing pull and merge requests

Red Hat OpenShift Dev Spaces workspace contains all tools you need to review pull and merge requests from start to finish. By clicking a OpenShift Dev Spaces link, you get access to Red Hat OpenShift Dev Spaces-supported web IDE with a ready-to-use workspace where you can run a linter, unit tests, the build and more.


  • You have access to the repository hosted by your Git provider.
  • You have access to a OpenShift Dev Spaces instance.


  1. Open the feature branch to review in OpenShift Dev Spaces. A clone of the branch opens in a workspace with tools for debugging and testing.
  2. Check the pull or merge request changes.
  3. Run your desired debugging and testing tools:

    • Run a linter.
    • Run unit tests.
    • Run the build.
    • Run the application to check for problems.
  4. Navigate to UI of your Git provider to leave comment and pull or merge your assigned request.


  • (optional) Open a second workspace using the main branch of the repository to reproduce a problem.

2.3. Try in Web IDE GitHub action

The Try in Web IDE GitHub action can be added to a GitHub repository workflow to help reviewers quickly test pull requests on Eclipse Che hosted by Red Hat. The action achieves this by listening to pull request events and providing a factory URL by creating a comment, a status check, or both. This factory URL creates a new workspace from the pull request branch on Eclipse Che hosted by Red Hat.


The Che documentation repository ( is a real-life example where the Try in Web IDE GitHub action helps reviewers quickly test pull requests. Experience the workflow by navigating to a recent pull request and opening a factory URL.

Figure 2.2. Pull request comment created by the Try in Web IDE GitHub action. Clicking the badge opens a new workspace for reviewers to test the pull request.


Figure 2.3. Pull request status check created by the Try in Web IDE GitHub action. Clicking the "Details" link opens a new workspace for reviewers to test the pull request.


2.3.1. Adding the action to a GitHub repository workflow

This section describes how to integrate the Try in Web IDE GitHub action to a GitHub repository workflow.


  • A GitHub repository
  • A devfile in the root of the GitHub repository.


  1. In the GitHub repository, create a .github/workflows directory if it does not exist already.
  2. Create an example.yml file in the .github/workflows directory with the following content:

    Example 2.1. example.yml

    name: Try in Web IDE example
        types: [opened]
        runs-on: ubuntu-20.04
          - name: Web IDE Pull Request Check
            id: try-in-web-ide
            uses: redhat-actions/try-in-web-ide@v1
              # GitHub action inputs
              # required
              github_token: ${{ secrets.GITHUB_TOKEN }}
              # optional - defaults to true
              add_comment: true
              # optional - defaults to true
              add_status: true

    This code snippet creates a workflow named Try in Web IDE example, with a job that runs the v1 version of the redhat-actions/try-in-web-ide community action. The workflow is triggered on the pull_request_target event, on the opened activity type.

  3. Optionally configure the activity types from the on.pull_request_target.types field to customize when workflow trigger. Activity types such as reopened and synchronize can be useful.

    Example 2.2. Triggering the workflow on both opened and synchronize activity types

        types: [opened, synchronize]
  4. Optionally configure the add_comment and add_status GitHub action inputs within example.yml. These inputs are sent to the Try in Web IDE GitHub action to customize whether comments and status checks are to be made.

2.3.2. Providing a devfile

Providing a devfile in the root directory of the repository is recommended to define the development environment of the workspace created by the factory URL. In this way, the workspace contains everything users need to review pull requests, such as plugins, development commands, and other environment setup.

The Che documentation repository devfile is an example of a well-defined and effective devfile.

Red Hat logoGithubRedditYoutubeTwitter


Try, buy, & sell


About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.