-
Notifications
You must be signed in to change notification settings - Fork 179
staging: update release calendar logic (#1256) #1257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
staging: update release calendar logic (#1256) #1257
Conversation
WalkthroughReworks 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
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
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
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 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 |
There was a problem hiding this 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
contentsis still scoped toread. The defaultGITHUB_TOKENwill refuse thegit push origin "${BRANCH_NAME}", so the workflow will fail before the PR is created. Bump this towrite(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
📒 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
| - 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}" | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Summary by CodeRabbit
New Features
Chores