Defunct: Filtering and enabling prebuilds via the .gitpod.yml file is no longer supported. Please see Configuring prebuilds instead. You can find the original documentation below.
The github namespace in the .gitpod.yml file defines when prebuilds should be executed. By default, prebuilds are run on push to the default branch and for each pull request coming from the same repository.
.gitpod.yml
github:
    prebuilds:
        # enable for the default branch (defaults to true)
        master: true
        # enable for all branches in this repo (defaults to false)
        branches: false
        # enable for pull requests coming from this repo (defaults to true)
        pullRequests: true
        # enable for pull requests coming from forks (defaults to false)
        pullRequestsFromForks: false
        # add a check to pull requests (defaults to true)
        addCheck: true
        # add a "Review in Gitpod" button as a comment to pull requests (defaults to false)
        addComment: false
        # add a "Review in Gitpod" button to the pull request's description (defaults to false)
        addBadge: false

​
Additional GitHub integration

Once the GitHub app is installed, Gitpod can add helpful annotations to your pull requests.

​
Checks

By default, Gitpod registers itself as a check to pull requests - much like a continuous integration system would do. The default behavior, however, would not make the checks fail when the prebuild failed. This can be enabled with the following snippet: 
github:
    prebuilds:
        addCheck: prevent-merge-on-error
You can disable this behaviour in the .gitpod.yml file in your default branch: 
github:
    prebuilds:
        addCheck: false

​
Comment

Gitpod can add a comment with an “Open in Gitpod” button to your pull requests. You can enable this behaviour in the .gitpod.yml file in your default branch: 
github:
    prebuilds:
        addComment: true

​
Badge

Instead of adding a comment, Gitpod can also modify the description of a pull request to add the “Open in Gitpod” button. This approach produces fewer GitHub notifications, but can also create a concurrent editing conflict when the bot and a user try to edit the description of a pull request at the same time. You can enable this behaviour in the .gitpod.yml file in your default branch: 
github:
    prebuilds:
        addBadge: true
The addComment and addBadge behaviours are not mutually exclusive (i.e. enabling one does not disable the other). If you don’t want the comments to be added, disable them using addComment: false.