Collect GitHub data in AWS Redshift
Load repository details, contributors and daily star counts from GitHub into your own AWS Redshift schema with OWOX Data Marts, then report engineering activity beside the orders and sign-ups already stored in your Redshift schema.
GitHubConnectedRepository Contr…Repository Infor…Repository Stati…
AWS RedshiftLoginIdNodeDaily 09:00Engineering activity lives on GitHub and orders live in AWS Redshift, so the two are only compared on slides.
Paste this into your AI assistant. It loads GitHub repository details, contributors and daily star counts into AWS Redshift with OWOX Data Marts, next to the orders and sign-ups already stored there.
The prompt
Read https://www.owox.com/ai-agent-setup.md and follow it to set up OWOX Data Marts for me, starting from /connectors/github-connector-to-aws-redshift.md. The task: load GitHub repository stats into AWS Redshift and give me a monthly table per repository: stars, forks, open issues and contributors next to sign-ups and orders for the same month. Tag the links you give me with utm_campaign=ai-task and utm_term=data-foundation. Use what you know about my context and goals
GitHub Endpoints
3 GitHub endpoints you can import. Each lands in its own table in your data warehouse.
Why GitHub data belongs in your AWS Redshift data warehouse
A star count on GitHub is a fact about a day. Kept in your warehouse on AWS Redshift, it can be joined by date to sign-ups and orders, so a release and what followed it are two columns of one result.
- Join the daily star count to sign-ups and orders by date
- Keep the star trend that GitHub shows only as a current total
- Report delivery next to orders without a spreadsheet in between
GitHubRepository activityYour data warehouseRepositorySign-upsRevenueJoined by idYour release dateSign-ups and revenue afterOne Redshift query lines up the release date with what came next.Step 1: Connect GitHub and pick the fields
Create a Data Mart, choose GitHub as the source, enter owner/repo for the repository, add an access token and tick the fields you need.
- Repository Information, Repository Contributors and Repository Statistics are the endpoints on offer
- You authenticate once with an access token
Google AdsGitHub
Facebook AdsAuthorizeConnectedEndpointRepository Inform…Repository Contri…Repository Statis…Repository Inform…full_namestargazers_countforks_countopen_issues_countlanguagepushed_atStep 2: Load GitHub into a Redshift table
Pick the schema in your storage; the names are pre-filled and you can change them. Run it and the first load lands in your own AWS account.
- The tables are github_repository, github_contributors and github_repository_stats, in the schema you pick
- The statistics table holds one row per run date, so stars and contributors filter by date like any other table
DestinationSchemagithubTablerepositoryRunTablegithub.repositoryStep 3: Get a readable output schema
After the first run the output schema shows every field with a plain description, and your quality checks can read it too.
- created_at, updated_at and pushed_at are dates, ready for date arithmetic
- login identifies a contributor and contributions counts their work on the repository
github.repositoryOutput schemaFieldDescriptionfull_nameFull repository name (owner/repo)stargazers_countNumber of starsforks_countNumber of forksopen_issues_countNumber of open issueslanguagePrimary programming languagepushed_atRepository last push dateStep 4: Link GitHub tables to orders and sign-ups in Redshift
Redshift can join the GitHub tables to yours as soon as they land: repository name to your release records, date to orders and sign-ups, with each join described once in your model.
- full_name matches the repository name in your own release table
- The statistics date joins to orders and sign-ups by day
Repository Inform…full_namestargazers_countlanguageRepository Statis…datestarsStep 5: Schedule the refresh and begin the history
Set it once. A scheduled refresh adds today's row to the statistics table and updates the repository and contributor rows in your Redshift schema.
- A daily run adds one row per day to the statistics table
- GitHub returns today's counts only, so there is nothing to backfill: your Redshift history starts with the first run
Step 6: Reuse the same Redshift tables everywhere
One Redshift schema feeds your model, , , assistants like Claude and ChatGPT, and scheduled AI insights in Slack or email.
- Every report reads the same tables, so the figures agree
- Ask an AI assistant how many stars the repository gained last month, from your Redshift tables
GitHubData MartPublished
Google Sheets
Data Studio dashboards
Claude, ChatGPT
Slack, email
- 0.41.0Rotating a warehouse key is one change: Storages share reusable Credentials
- 0.41.0Shared SQL logic stays in one place: build a Data Mart on top of another
- 0.41.0Rotating a connector key is one change: Sources share reusable Credentials
- 0.39.0Reload a year of history in one backfill, not twelve
- 0.37.0Clearer connector errors, and custom connectors that handle more APIs
Why OWOX for GitHub data in Redshift
A script that calls the GitHub API, or a weekly export to a spreadsheet, gets you numbers. OWOX keeps them in your Redshift schema, beside your orders and sign-ups.
- You own the data. The data lands in your own AWS account, in a Redshift schema you control and can join to anything.
- History you keep. GitHub's repository page shows the current count. In Redshift the statistics table adds a row for every day you run it, so the trend stays.
- Ready for a data model. full_name and date join to orders and sign-ups in the same schema.
- Maintained for you. No script to fix when the GitHub API changes.
You are booked. The invitation is on its way to , with the calendar invite and the meeting link.