Description
After the main github actions code goes in, #20, we need to push it to our other github repositories where tracking is needed. The plan is to add an org-level webhook routing issues events to an AWS Lambda (following the existing pattern in github-admin/webhooks/). This will allow tickets to be filed in any JCSDA-Internal repo while still syncing to the same sheet. The repo column already in the spreadsheet schema handles the multi-repo case without any schema changes.
Notes: once you move to the org webhook → Lambda architecture, this entire concern goes away. The Lambda will receive events sequentially from the webhook queue (or you'd handle concurrency in the Lambda itself), and there's no GitHub Actions concurrency group involved at all. The retry logic already added to the Python script is what handles contention at that layer.
Acceptance Criteria (Definition of Done)
Issue tracking in one spreadsheet across all JCSDA repos
Dependencies
#20
Description
After the main github actions code goes in, #20, we need to push it to our other github repositories where tracking is needed. The plan is to add an org-level webhook routing
issuesevents to an AWS Lambda (following the existing pattern ingithub-admin/webhooks/). This will allow tickets to be filed in any JCSDA-Internal repo while still syncing to the same sheet. Therepocolumn already in the spreadsheet schema handles the multi-repo case without any schema changes.Notes: once you move to the org webhook → Lambda architecture, this entire concern goes away. The Lambda will receive events sequentially from the webhook queue (or you'd handle concurrency in the Lambda itself), and there's no GitHub Actions concurrency group involved at all. The retry logic already added to the Python script is what handles contention at that layer.
Acceptance Criteria (Definition of Done)
Issue tracking in one spreadsheet across all JCSDA repos
Dependencies
#20