<commit_before>---
title: Getting Set Up
subtitle: Getting Set Up
order: 1
---

ruby:
  require 'json'
  ci_sources = JSON.parse(File.read('json_data/ci_docs.json'))
  

.clearfix
section.guide
  article
    markdown:
      There are 5 steps invovled in getting Danger running:

      * [Include Danger](#including-danger)
      * [Creating a Dangerfile](#creating-a-dangerfile) and adding a few simple rules.
      * [Creating a GitHub account for Danger to use](#creating-a-github-account-for-danger-to-use).
      * Setting up [an access token for Danger](#setting-up-an-access-token) with that account.
      * Setting up [Danger to run on your CI](#setting-up-danger-to-run-on-your-ci).

      ### Including Danger

      We recommend you install Danger via [Bundler][bundler] + a Gemfile. This means that your version of Danger, and your plugins are all versioned correctly. You are in control of how and when your dependencies are updated then. If you'd like to learn more about Bundler, check out [this guide][cp_bundler].

      ##### Installation

      If you have an existing Gemfile, add `gem 'danger'` to it. If you don't run `bundle init` in your project root, and edit the freshly minted Gemfile.

      ##### Bundler 101

      Bundler is a dependey manager for Ruby, it uses a Gemfile to define all of the Ruby projects you want to use. To get started type in `bundler init` in your project folder.
      This creates your `Gemfile`. Open this up in your editor, then replace the ` #gem 'rails'` with `gem 'danger'`. Then run `bundle install` inside your project folder.

      ### Easy Mode

      *Easy mode* - run: `bundle exec danger init` - this will guide you through the next four steps, offering useful advice specific to your setup. If you would like to understand how all of the pieces come together, read on:

      ### Creating a Dangerfile

      Create an empty file, named `Dangerfile`. This is the file that contains ruby code. Your text editor won't highlight as ruby, so you may need to set the syntax highlighting. Unless you're [using VS Code][vs_code]. To get started, we would recommend a simple "Hello World."

      <code>
        <pre>
      message("Hello, this worked")
        </pre>
      <code>

      ### Creating a GitHub account for Danger to use

      This is optional. Pragmatically, you want to do this though.

      In order to get the most out of Danger, we recommend giving her the ability to post comments in your code review. This is a regular GitHub account, depending on whether you are working on a private or public project you will want to give different levels of access to this bot. You are allowed to have [one bot per GitHub account][github_bots].

      To get started, open [https://github.com](https://github.com) in a private browser session.

      ##### OSS Projects

      Do not add the bot to repo, or to your organization.

      ##### Closed Source Projects

      Add the bot to repo, or to your organization. The bot requires permission level "Write" to be able to set a PR's status. Note that you _should not_ re-use this bot for OSS projects.

      ### Setting up an Access Token

      [Here's the link][github_token], you should open this in the private session where you just created the new GitHub account. Again, the rights that you give to the token depend on the openness of your projects.

      ##### Tokens for OSS Projects

       We recommend giving the token the smallest scope possible. This means just `public_repo`, this scopes limits Danger's abilities to just writing comments on OSS projects. Because the token can be quite easily be extracted from the CI environment, this minimalises the chance for bad actors causing chaos with it.

      ##### Tokens for Closed Source Projects

      We recommend giving access to the whole `repo` scope, and it's children.

      ### Continuous Integration

      Continuous Integration is the process of regularly running tests, and generating metrics for a project. It is where you can ensure that the code you are submitting for review is passing on all of the tests. You commonly see this as green, or red dots inside GitHub pull requests.

      Danger is built to run as a part of this process, so you will need to have this set up as a pre-requisite.

      ### Setting up Danger to run on your CI

      [bundler]: http://bundler.io
      [cp_bundler]: https://guides.cocoapods.org/using/a-gemfile.html
      [without_bundler]: #installation-without-bundler<commit_msg>Fixed some typos in the Getting Started guide<commit_after>---
title: Getting Set Up
subtitle: Getting Set Up
order: 1
---

ruby:
  require 'json'
  ci_sources = JSON.parse(File.read('json_data/ci_docs.json'))
  

.clearfix
section.guide
  article
    markdown:
      There are 5 steps involved in getting Danger running:

      * [Include Danger](#including-danger).
      * [Creating a Dangerfile](#creating-a-dangerfile) and adding a few simple rules.
      * [Creating a GitHub account for Danger to use](#creating-a-github-account-for-danger-to-use).
      * Setting up [an access token for Danger](#setting-up-an-access-token) with that account.
      * Setting up [Danger to run on your CI](#setting-up-danger-to-run-on-your-ci).

      ### Including Danger

      We recommend you install Danger via [Bundler][bundler] + a Gemfile. This means that your version of Danger and your plugins are all versioned correctly. You are in control of how and when your dependencies are updated. If you'd like to learn more about Bundler, check out [this guide][cp_bundler].

      ##### Installation

      If you have an existing Gemfile, add `gem 'danger'` to it. If you don't, run `bundle init` in your project root, and edit the freshly-minted Gemfile.

      ##### Bundler 101

      Bundler is a dependency manager for Ruby which uses a Gemfile to define all of the Ruby projects you want to use. To get started type in `bundler init` in your project folder.
      This creates your `Gemfile`. Open this up in your editor, then replace the ` #gem 'rails'` with `gem 'danger'`. Then run `bundle install` inside your project folder.

      ### Easy Mode

      *Easy mode* - run: `bundle exec danger init` - this will guide you through the next four steps, offering useful advice specific to your setup. If you would like to understand how all of the pieces come together, read on:

      ### Creating a Dangerfile

      Create an empty file named `Dangerfile`. The file is written in Ruby, but your text editor might not recognize it as such, so you may need to set the syntax highlighting manually (unless you're [using VS Code][vs_code]). To get started, we would recommend a simple "Hello World."

      <code>
        <pre>
      message("Hello, this worked")
        </pre>
      <code>

      ### Creating a GitHub account for Danger to use

      This is optional. Pragmatically, you want to do this though.

      In order to get the most out of Danger, we recommend giving her the ability to post comments in your code review. This is a regular GitHub account, but depending on whether you are working on a private or public project, you will want to give different levels of access to this bot. You are allowed to have [one bot per GitHub account][github_bots].

      To get started, open [https://github.com](https://github.com) in a private browser session.

      ##### OSS Projects

      Do not add the bot to your repo or to your organization.

      ##### Closed Source Projects

      Add the bot to repo or to your organization. The bot requires permission level "Write" to be able to set a PR's status. Note that you _should not_ re-use this bot for OSS projects.

      ### Setting up an Access Token

      [Here's the link][github_token], you should open this in the private session where you just created the new GitHub account. Again, the rights that you give to the token depend on the openness of your projects.

      ##### Tokens for OSS Projects

      We recommend giving the token the smallest scope possible. This means just `public_repo`, this scopes limits Danger's abilities to just writing comments on OSS projects. Because the token can be quite easily be extracted from the CI environment, this minimizes the chance for bad actors causing chaos with it.

      ##### Tokens for Closed Source Projects

      We recommend giving access to the whole `repo` scope, and its children.

      ### Continuous Integration

      Continuous Integration is the process of regularly running tests and generating metrics for a project. It is where you can ensure that the code you are submitting for review is passing on all of the tests. You commonly see this as green or red dots inside GitHub pull requests.

      Danger is built to run as a part of this process, so you will need to have this set up as a pre-requisite.

      ### Setting up Danger to run on your CI

      [bundler]: http://bundler.io
      [cp_bundler]: https://guides.cocoapods.org/using/a-gemfile.html
      [without_bundler]: #installation-without-bundler
{'fraction_non_alphanumeric': 0.06980072663216999, 'fraction_numerical': 0.0011009578333149841, 'mean_word_length': 3.234965034965035, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4255806', 'n_tokens_mistral': 2443, 'n_tokens_neox': 2238, 'n_words': 1284}