Skip to content

Conversation

@transphorm
Copy link
Member

@transphorm transphorm commented Oct 10, 2025

Summary by CodeRabbit

  • New Features

    • Manual triggering for staging and production releases.
    • Date-based release branches for staging and production to better track each release.
    • Enhanced PR creation with release date, branch details, and appropriate labels.
    • Clearer workflow inputs and options for selecting the release job.
  • Chores

    • Improved scheduling logic with guard conditions for each job.
    • Propagated branch names across steps to streamline downstream actions.
    • Refined logging and outputs for better visibility.
    • Maintained existing PR checks while aligning with the new branch strategy.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 10, 2025

Walkthrough

Reworks the release-calendar workflow to use dated release branches for staging and production, adds manual trigger input, propagates a BRANCH_NAME output, updates PR creation to target these branches, and adjusts labeling, logging, and guards. Includes steps to create/push release branches and to check existing PRs using the computed branch names.

Changes

Cohort / File(s) Summary
Workflow metadata & inputs
.github/workflows/release-calendar.yml
Updated manual input description for job_to_run and clarified options. Expanded scheduling/manual-trigger guards and added explicit input descriptions.
Branching & outputs
.github/workflows/release-calendar.yml
Introduced dated release branches: release/staging-YYYY-MM-DD and release/production-YYYY-MM-DD. Added BRANCH_NAME outputs and propagated them across steps for titles, bodies, and PR heads.
Staging flow (dev → staging)
.github/workflows/release-calendar.yml
Added steps to create/push release/staging-* from dev, check for existing PRs using computed head/base, and create PRs referencing the new branch with updated body formatting.
Production flow (staging → main)
.github/workflows/release-calendar.yml
Added steps to create/push release/production-* from staging, check for existing PRs, and create PRs to main with updated body, dates, and branch references.
Labels, logging, and PR content
.github/workflows/release-calendar.yml
Ensured required labels exist and apply staging/production labels. Enhanced logs and PR body content with release date and branch details.

Sequence Diagram(s)

sequenceDiagram
  autonumber
  actor U as User/Scheduler
  participant G as GitHub Actions (release-calendar)
  participant Repo as Repo (branches)
  participant PR as GitHub PRs API

  U->>G: Trigger workflow (manual or schedule) with job_to_run=staging
  G->>G: Compute release date and BRANCH_NAME (release/staging-YYYY-MM-DD)
  G->>Repo: Create branch from dev -> BRANCH_NAME
  Repo-->>G: Branch created/pushed
  G->>PR: Search existing PRs (base=staging, head=BRANCH_NAME)
  PR-->>G: Existing? (none or found)
  alt No existing PR
    G->>PR: Create PR (head=BRANCH_NAME, base=staging, labels)
    PR-->>G: PR URL
  else Existing PR
    G->>G: Skip creation
  end
Loading
sequenceDiagram
  autonumber
  actor U as User/Scheduler
  participant G as GitHub Actions (release-calendar)
  participant Repo as Repo (branches)
  participant PR as GitHub PRs API

  U->>G: Trigger workflow (manual or schedule) with job_to_run=production
  G->>G: Compute release date and BRANCH_NAME (release/production-YYYY-MM-DD)
  G->>Repo: Create branch from staging -> BRANCH_NAME
  Repo-->>G: Branch created/pushed
  G->>PR: Search existing PRs (base=main, head=BRANCH_NAME)
  PR-->>G: Existing? (none or found)
  alt No existing PR
    G->>PR: Create PR (head=BRANCH_NAME, base=main, labels)
    PR-->>G: PR URL
  else Existing PR
    G->>G: Skip creation
  end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

Suggested labels

codex

Poem

New branches sprout with dates in tow,
From dev to staging, then main we go.
A BRANCH_NAME whisper guides each run,
Calendars click—another done.
Labels stick, logs softly sing,
PRs line up—release is king. 🚀

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 clearly indicates that the staging release calendar logic has been updated and directly relates to the workflow changes introduced in this pull request.
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/migrate-release-calendar-to-staging

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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
.github/workflows/release-calendar.yml (1)

45-48: Grant write permissions for branch pushes.

We now push new release branches, but contents is still scoped to read. The default GITHUB_TOKEN will refuse the git push origin "${BRANCH_NAME}", so the workflow will fail before the PR is created. Bump this to write (and keep other scopes minimal) so the branch push succeeds.

 permissions:
-  contents: read
+  contents: write
   pull-requests: write
   issues: write # Required for creating labels
📜 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 756a850 and db55ecc.

📒 Files selected for processing (1)
  • .github/workflows/release-calendar.yml (9 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). (1)
  • GitHub Check: type-check

Comment on lines +147 to +159
- name: Create release branch from dev
if: ${{ steps.guard_schedule.outputs.continue == 'true' && steps.check_dev_staging.outputs.existing_pr == '' }}
env:
BRANCH_NAME: ${{ steps.check_dev_staging.outputs.branch_name }}
shell: bash
run: |
set -euo pipefail
echo "Creating release branch ${BRANCH_NAME} from dev"
git fetch origin dev
git checkout -b "${BRANCH_NAME}" origin/dev
git push origin "${BRANCH_NAME}"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

Handle pre-existing release branches before recreating them.

git checkout -b "${BRANCH_NAME}" origin/dev (and the staging variant later) hard-fails if the branch already exists on origin—e.g., someone reruns the job the same day, or the previous PR merged without deleting the branch. That leaves the workflow stuck. Guard for an existing remote branch and recreate it cleanly before pushing.

-          git fetch origin dev
-          git checkout -b "${BRANCH_NAME}" origin/dev
-          git push origin "${BRANCH_NAME}"
+          git fetch origin dev "${BRANCH_NAME}" || true
+          if git ls-remote --exit-code origin "${BRANCH_NAME}" >/dev/null 2>&1; then
+            echo "Remote branch ${BRANCH_NAME} already exists; removing before recreating"
+            git push origin --delete "${BRANCH_NAME}"
+          fi
+          git checkout -B "${BRANCH_NAME}" origin/dev
+          git push origin "${BRANCH_NAME}"

Apply the same safeguard in the production branch creation step so both paths are resilient.

Also applies to: 330-342

🤖 Prompt for AI Agents
.github/workflows/release-calendar.yml lines 147-159: the job currently fails if
a remote branch with BRANCH_NAME already exists; detect and handle an existing
remote branch before creating and pushing the new one by (1) checking for the
remote branch (git ls-remote --heads origin "${BRANCH_NAME}"), (2) if it exists
delete or overwrite it (either git push origin --delete "${BRANCH_NAME}" or
remove local orphan and force-push), then create the branch from origin/dev (git
fetch origin dev; git branch -D "${BRANCH_NAME}" 2>/dev/null || true; git
checkout -b "${BRANCH_NAME}" origin/dev) and push with a force/setting upstream
(git push -u --force origin "${BRANCH_NAME}"); apply the same guard and changes
to the production branch creation block at lines 330-342.

@transphorm transphorm merged commit 36310d0 into staging Oct 10, 2025
13 checks passed
@transphorm transphorm deleted the justin/migrate-release-calendar-to-staging branch October 10, 2025 20:20
This was referenced Oct 26, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants