Our GitHub Projects integration allows you to complement our existing GitHub integration with project-level information (such as Iterations and custom fields).

The GitHub Projects integration is supplemental and requires you to import the related repositories to Keypup.

Related repositories are not automatically imported into Keypup since each repository incurs an additional monthly cost. You are in control of which repositories you track through your GitHub Projects.

GitHub Projects are project management layers on top of GitHub repositories belonging to the same user or organization.

An Issue or Pull Request can belong to multiple GitHub Projects. Typically, this means that an Issue or Pull Request can be in multiple advancement statuses, depending on which GitHub Project you consider.

This is why each GitHub Project on Keypup maintains its own set of issues and pull requests, on top (but separate) from repository data.

Each GitHub Project you connect to Keypup creates duplicates, in Keypup, of Issues and Pull Requests imported from repositories. Each duplicate gets augmented with additional fields (status, iteration, custom field) coming from the GitHub Project.

Because each GitHub Project creates duplicates of existing Issues and Pull Requests imported from repositories, it is important to use Project-level or App-level filtering in Keypup to ensure your reporting focuses on the right project.

Let's assume Issue 123 from repository doecorp/ui has been added to GitHub Project A and GitHub Project B.

After connecting doecop/ui to Keypup, we will have the following data:

If you now connect GitHub Project A and GitHub Project B to Keypup, we will have the following data:

Our GitHub integration fetches the following entities:

Project items are fetched and exposed on the Issues & Pull Request dataset. Each project item adopts the attributes of the underlying issue or PR, plus the following attributes:

Project iterations from the Iteration field in GitHub Projects are captured and exposed as Sprints in Keypup. Sprint attributes allow you to filter issues and pull requests based on Sprint Name, Sprint End Date, Sprint Start Date, etc.

On the Iteration field is retrieved as Sprints. Other iteration fields are not picked up by Keypup. If you renamed the Iteration field in GitHub Project to something else, Keypup will not pick it up as Sprint.

The Status field in GitHub Projects is a mandatory non-editable system field. This field is mapped to the Workflow status field in Keypup.

You can define a custom list of statuses in your GitHub Project, and Keypup will automatically pick up the status names.

All date, number, single select and text fields are captured as custom fields in Keypup. Custom fields can be used for filtering, reporting, and in formulas (they are prefixed with cf_github_).

Status transition events (e.g., transition from "Todo" to "In Progress") are not currently exposed on the GitHub API.

The consequences are the following:

Updates on Issues and Pull Requests are received in real time via webhooks when available, or via long-polling (every 20 mins) if the connecting user does not have permissions to set webhooks on the repositories.

Updates on Project Items (status, iterations, custom fields) are received via long-polling (every 20 mins). Webhooks are not available since they require org-level administrative permissions.

If you have IP whitelisting enabled on GitHub, please authorize the IPs to make Keypup work: