Collect GitHub data in Snowflake
Load repository details, contributors and daily star counts from GitHub into your own Snowflake database with OWOX Data Marts, so engineering activity can be reported beside the commercial tables your team already queries.
GitHubConnectedRepository Contr…Repository Infor…Repository Stati…
SnowflakeLoginIdNodeDaily 09:00Open issues pile up across repositories, and nobody sees the trend because GitHub keeps no daily count.
Paste this into your AI assistant. It loads GitHub repository details into Snowflake on a daily run with OWOX Data Marts, so open issues, forks and stars get a history next to your releases.
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-snowflake.md. The task: load GitHub repository details into Snowflake every day and chart open issues, forks and stars per repository over time, with our release dates and sign-ups marked. 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 activity belongs in your Snowflake account
A repository's stars and contributors are easy to read on GitHub and hard to compare with anything else. In your warehouse they become tables: join them by date to sign-ups and revenue, and whether the launch moved anything gets a query, not an opinion.
- Join stars and contributors to sign-ups by date in Snowflake SQL
- Build the star trend that GitHub shows only as today's total
- Put delivery next to the commercial tables your team already queries
GitHubRepository activityYour data warehouseRepositorySign-upsRevenueJoined by idYour release dateSign-ups and revenue afterOne Snowflake 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, name the repository as owner/repo, add an access token and tick the fields you need.
- Repository Information, Repository Contributors and Repository Statistics are the three endpoints you can pick
- An access token is the only credential, entered once in the Data Mart
Google AdsGitHub
Facebook AdsAuthorizeConnectedEndpointRepository Inform…Repository Contri…Repository Statis…Repository Inform…full_namestargazers_countforks_countopen_issues_countlanguagepushed_atStep 2: Load GitHub into a Snowflake table
Choose the schema in your storage; the database is the one you connected, and the names are pre-filled. Run it and the first load lands in your own Snowflake 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
DestinationDatabaseSchemagithubTablerepositoryRunTablegithub.repositoryStep 3: Get a readable output schema
After the first run you get the output schema, with a plain description for every field, which your quality checks can read as well.
- stargazers_count and forks_count are numbers, and created_at and pushed_at are dates
- contributors in the statistics table is a count; the contributors table lists each login with its contributions
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: Join repositories to releases and sign-ups in Snowflake
GitHub's tables are small. They get useful when Snowflake joins them to yours: repository name to the releases you track, and date to your sign-ups, with the join written once in your model.
- The repository name in full_name matches a repository column in your own release table
- Stars by date line up with sign-ups by date in one view
Repository Inform…full_namestargazers_countlanguageRepository Statis…datestarsStep 5: Schedule a daily run and start 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 Snowflake schema.
- A daily trigger gives the statistics table one row per day
- GitHub returns today's counts only, so there is nothing to backfill: your Snowflake history starts with the first run
Step 6: Reuse the same Snowflake tables everywhere
The same Snowflake tables feed your model, , , assistants such as Claude and ChatGPT, and scheduled AI insights in Slack or email.
- Each report reads the same rows, so the totals match
- Ask an AI assistant how many stars the repository gained last month, from your Snowflake 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 Snowflake
A script that calls the GitHub API, or a weekly export to a spreadsheet, gets you numbers. OWOX puts them in your Snowflake schema, beside the tables your team already queries.
- You own the data. The data lands in your own Snowflake account, in tables your roles and policies already govern.
- History you keep. GitHub's repository page shows the current count. In Snowflake the statistics table adds a row for every day you run it, so the trend stays.
- Ready for a data model. Join on full_name and date in a view your roles already govern.
- 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.