main: update release calendar logic

[transphorm]

Summary by CodeRabbit

• Chores
  • Introduced automated release pipelines that create staging and production release pull requests on a set schedule with optional manual triggering.
  • Added safeguards to skip duplicates, honor event types/days, and verify that production releases only proceed when changes exist.
  • Automatically manages release labels and generates informative PR descriptions with dates, branch details, commit summaries, and checklists.
  • Improved logging for clearer visibility into release workflow actions and decisions.

[coderabbitai]

Walkthrough

Introduces a GitHub Actions workflow (.github/workflows/release-calendar.yml) that schedules and manually triggers staging and production release PR creation. It performs event/day guards, ensures labels, checks existing PRs and branch divergence, creates dated release branches, and generates PR bodies via Python, using gh CLI for branch/PR operations.

Changes

Cohort / File(s)	Summary
Release automation workflow \.github/workflows/release-calendar.yml	Adds a scheduled and workflow_dispatch-driven pipeline to create dated staging (dev → staging) and production (staging → main) release PRs. Includes guard checks by event/day, existing PR detection, label creation, release branch creation/push, and PR body generation via Python; uses gh CLI for labels and PRs.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor User as User (workflow_dispatch)
  participant Cron as Scheduler (cron)
  participant GHA as GitHub Actions
  participant GH as GitHub API/gh CLI
  participant Py as Python PR Body Gen

  rect rgb(245,245,255)
    note over Cron,GHA: Trigger
    Cron->>GHA: Friday 17:00 UTC (staging) / Sunday 17:00 UTC (production)
    User-->>GHA: workflow_dispatch (job_to_run=staging|production)
  end

  rect rgb(245,255,245)
    note over GHA: Guards
    GHA->>GHA: Check event type, day-of-week, inputs
    GHA->>GHA: Decide staging vs production flow
  end

  alt Staging flow
    GHA->>GH: Search existing PR release/staging-YYYY-MM-DD -> staging
    GH-->>GHA: Exists? (yes/no)
    opt If none
      GHA->>GH: Ensure labels (release, automated, staging)
      GHA->>GH: Create branch from dev (release/staging-YYYY-MM-DD) and push
      GHA->>Py: Generate pr_body.md (staging)
      Py-->>GHA: pr_body.md
      GHA->>GH: Open PR to staging with labels/body
    end
  else Production flow
    GHA->>GHA: Skip on push events
    GHA->>GH: Check if staging ahead of main
    GH-->>GHA: Ahead? (yes/no)
    opt If ahead and no existing PR
      GHA->>GH: Ensure labels (release, automated, production)
      GHA->>GH: Create branch from staging (release/production-YYYY-MM-DD) and push
      GHA->>Py: Generate pr_body.md (production checklist, commits ahead)
      Py-->>GHA: pr_body.md
      GHA->>GH: Open PR to main with labels/body
    end
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Add release calendar workflow for automated PRs #1217 — Also updates the same release-calendar workflow, overlapping on PR body generation via Python instead of heredocs.
• update release calendar logic #1256 — Adjusts the workflow to standardize dated release branches and refine PR existence/label handling.
• staging: update release calendar logic (#1256) #1257 — Implements dated release branches and propagates branch name outputs within the same workflow.

Suggested labels

codex

Poem

Friday taps the staging drum—tick, tock, tags align,
Sunday sails to mainline seas, on branches by design.
Bots pen checklists, Python hums,
gh waves the PRs through the plums.
Calendar whispers, “Ship in time.” 🚀📅

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title Check	✅ Passed	The title accurately captures the core change by indicating an update to the release calendar logic, it is concise, clear, and directly related to the modifications in the GitHub Actions workflow without unnecessary detail.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch justin/update-main-with-release-calendar

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 48f8d79 and 3ee4038.

📒 Files selected for processing (1)

• .github/workflows/release-calendar.yml (1 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

.github/workflows/**/*.{yml,yaml}

📄 CodeRabbit inference engine (AGENTS.md)

.github/workflows/**/*.{yml,yaml}: In GitHub workflows, use the shared composite actions in .github/actions for dependency caching instead of calling actions/cache directly
Use the cache-yarn composite action for Yarn dependency caching in workflows
Use the cache-bundler composite action for Ruby gems caching in workflows
Use the cache-gradle composite action for Gradle caching in workflows
Use the cache-pods composite action for CocoaPods caching in workflows

Files:

• .github/workflows/release-calendar.yml

⏰ Context from checks skipped due to timeout of 300000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)

• GitHub Check: type-check
• GitHub Check: test-common
• GitHub Check: type-check
• GitHub Check: test-common

[coderabbitai]

⚠️ Potential issue | 🔴 Critical

Grant write permissions to push release branches.

Both release jobs run git push, but the workflow narrows contents permission to read, so the pushes will fail. Update the workflow permissions to include contents: write before merging.

Apply this diff:

 permissions:
-  contents: read
+  contents: write
   pull-requests: write
   issues: write # Required for creating labels

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	permissions:
	contents: read
	pull-requests: write
	permissions:
	contents: write
	pull-requests: write
	issues: write # Required for creating labels

🤖 Prompt for AI Agents

.github/workflows/release-calendar.yml around lines 45 to 47: the workflow
currently sets permissions.contents to read while release jobs perform git push,
causing pushes to fail; change the permissions block so contents is set to write
(e.g., contents: write) while keeping pull-requests: write, ensuring the
workflow has push access for release branches.

[transphorm]

let's not use feature branches to merge to main