First and foremost, we must provide our Jenkins server with permissions to access our repository, as well as to set up service hooks. There are several ways to do this:

1. Create a Personal Access (OAuth) Token on GitHub, which essentially allows your Jenkins server to masquerade as you. The benefits of this approach are that you can have one token that can be used everywhere to access all repositories under your control. However, although the scope of the token can be restricted, these permissions are applicable for all repositories under your account. Thus, this approach does not allow you to set granular permissions for each repository.
2. Create a new user on GitHub that represents the Jenkins server, and add that user as a collaborator into your repository. After creating the account, you'll need to create a new SSH key pair on your Jenkins host machine, and add the public key to GitHub (just as you would for a normal user). Then, configure your Jenkins server to use this SSH key to communicate with GitHub.
   The benefits of this approach are that it allows you to separate your identity from the Jenkin servers, and you can simply add the Jenkin GitHub user to any other repository that you wish to grant access to the Jenkins server.
3. As in Step 2, create a new user on GitHub that represents the Jenkin server, and set up a new SSH key pair. Then, go to your repository and click on the Settings tab. In the sidebar, click Deploy Keys, then click Add deploy key. Now, paste your SSH key into the text area and save.
   The benefits of this approach are that you can grant access to only a single repository. They are called Deploy keys precisely because this method is used a lot for automated deployments. You can set the permission for the deploy key to be read-only (so they only clone, build, and deploy), or both read and write permissions (so they can also push changes back to the repository).

To keep it simple, we are going to use the Personal Access Token method, as outlined in the next section.