Local Development Setup

Table of Contents

• Table of Contents
• Step 1: Build from Source
• Step 2: Configuring Git and GitHub for Development
  • Create your fork
  • Configure remotes
  • Authenticating with GitHub
• Guidelines

Step 1: Build from Source

To work on raydar, you are going to need to build it from source. See Build from Source for detailed build instructions.

Once you've built raydar from a git clone, you will also need to configure git and your GitHub account for raydar development.

Step 2: Configuring Git and GitHub for Development

Create your fork

The first step is to create a personal fork of raydar. To do so, click the "fork" button at https://github.com/Point72/raydar, or just navigate here in your browser. Set the owner of the repository to your personal GitHub account if it is not already set that way and click "Create fork".

Configure remotes

Next, you should set some names for the git remotes corresponding to main Point72 repository and your fork. See the GitHub Docs for more information.

Authenticating with GitHub

If you have not already configured ssh access to GitHub, you can find instructions to do so here, including instructions to create an SSH key if you have not done so. Authenticating with SSH is usually the easiest route. If you are working in an environment that does not allow SSH connections to GitHub, you can look into configuring a hardware passkey or adding a personal access token to avoid the need to type in your password every time you push to your fork.

Guidelines

After developing a change locally, ensure that both lints and tests pass. Commits should be squashed into logical units, and all commits must be signed (e.g. with the -s git flag). We require Developer Certificate of Origin for all contributions.

If your work is still in-progress, open a draft pull request. Otherwise, open a normal pull request. It might take a few days for a maintainer to review and provide feedback, so please be patient. If a maintainer asks for changes, please make said changes and squash your commits if necessary. If everything looks good to go, a maintainer will approve and merge your changes for inclusion in the next release.

Please note that non substantive changes, large changes without prior discussion, etc, are not accepted and pull requests may be closed.