Adding milestone release calendar sync workflow#48593
Conversation
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Claude Code Review
This repository is configured for manual code reviews. Comment @claude review to trigger a review and subscribe this PR to future pushes, or @claude review once for a one-time review.
Tip: disable this comment in your organization's Code Review settings.
WalkthroughAdds a Python CLI that synchronizes Google Calendar release events with open GitHub milestone due dates. It supports service-account and OAuth authentication, event matching, duplicate and stale-event handling, dry-run plan rendering, and applying calendar changes. It also adds dependency declarations and a manually triggered GitHub Actions workflow with selectable dry-run or apply execution modes. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
| working-directory: tools/release/calendar-sync | ||
| env: | ||
| GCAL_SERVICE_ACCOUNT_JSON: ${{ secrets.GCAL_SERVICE_ACCOUNT_JSON }} | ||
| GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} |
There was a problem hiding this comment.
@lukeheath @allenhouchins before we merge this it would be good to add these to manage reading the milestones and updating the release calendar.
I tested locally with an oauth client and my gh auth token and tested dry-run and --apply to create the next milestone calendar events in 2027.
Let me know if you have any questions.
There was a problem hiding this comment.
It's also fine if we want to just check this in and run it manually if the calendar ever de-syncs and remove this action. Just thought it would be easier if the workflow automation happened w/o anyone needing to remember
There was a problem hiding this comment.
@georgekarrv sorry for the delay on this. I can set up the service account if you can shoot me over what permissions it needs.
Also, should we change 4.100 to 5.0 to help force our hand?! :-)
There was a problem hiding this comment.
In Google Cloud (the service account itself):
- In the project, enable the Google Calendar API.
- Create a service account and generate a JSON key. No project-level IAM roles needed — it doesn't touch any GCP resources.
Calendar access (this is what scopes it to just our calendar):
4. Open the Fleet releases calendar → Settings and sharing → Share with specific people or groups.
5. Add the service account's email (…@…iam.gserviceaccount.com) with "Make changes to events."
- Not "Make changes and manage sharing" — it never touches ACLs.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 8
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/calendar-sync.yml:
- Around line 23-26: Update the Harden Runner step in the calendar sync workflow
to use blocked egress instead of audit, and configure an allowlist containing
only the GitHub and Google API endpoints required by the job. Preserve the
existing secret-bearing steps and ensure their outbound requests remain
functional under the restricted policy.
- Around line 15-16: Update the workflow permissions block to grant read access
to issues in addition to contents, so the milestone API calls made by sync.py
can succeed.
- Around line 28-35: Upgrade the action references in the workflow: replace the
v3.6.0 pin for actions/checkout and the v4.7.1 pin for actions/setup-python with
current releases, and update each to its corresponding immutable commit SHA
while retaining the version comments.
In `@tools/release/calendar-sync/sync.py`:
- Around line 60-62: Update RELEASE_DAY_RE, RC_RE, and DEVELOP_RE to match both
legacy unversioned event titles and their current versioned forms by making the
version suffix optional while preserving existing whitespace and summary
constraints. Ensure the matching logic at the planner and replacement-handling
references also recognizes these legacy recurring events before creating
replacements.
- Around line 488-516: Prevent duplicate creation of overdue milestone events in
the unmatched-event handling for release-day and RC actions. Update the scan
range to include the earliest open milestone, or add a release-date check before
appending create actions in the relevant milestone loop and the corresponding
logic around lines 666–688, skipping events whose release date has passed. Use
the existing milestone date helpers and matching logic consistently.
- Around line 147-172: Update oauth_credentials to persist token_path with
owner-only permissions (0600). Ensure this applies both when creating the file
and when replacing an existing token, using an appropriate secure file-writing
or chmod approach around the existing open/write logic.
- Around line 207-221: Update apply_action to handle timed events consistently
with fetch_events: when applying a move or date change, patch the event’s
start.dateTime and end.dateTime fields, preserving the appropriate time and
timezone information, or explicitly reject timed events before they enter the
action plan. Use the existing fetch_events and apply_action symbols to locate
both sides of the behavior.
- Around line 291-299: Update desired_rc() so the PATCH_RC_DURATION_DAYS
short-window fallback is used only when m.out_of_band is true; for normal
milestones without current_start, preserve the appropriate standard RC start
behavior. Ensure plan_actions() missing-RC creation via desired_rc(m, None) no
longer assigns the short patch window to regular milestones.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: ac04358a-edd1-47fa-8cde-0acccf62216f
⛔ Files ignored due to path filters (1)
tools/release/calendar-sync/README.mdis excluded by!**/*.md
📒 Files selected for processing (3)
.github/workflows/calendar-sync.ymltools/release/calendar-sync/requirements.txttools/release/calendar-sync/sync.py
|
Just marking as Draft until @lukeheath and @allenhouchins get a chance to look. It's ready for review but has already been open a while. |
3 participants
This is a calendar sync workflow to trigger off of milestones being created or due dates being updated to keep the release calendar automatically in sync
example of me running it locally
We can now get rid of the recurring unnamed events and just rely on this once it's merged and added to milestone updates to trigger automatically
Summary by CodeRabbit