docs: add CHANGELOG.md and automate release drafting#184
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds release-drafter configuration and workflow, a weekly scheduled changelog workflow plus a Groq-backed changelog generator script, and a project ChangesRelease Notes Automation and Changelog
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/release-drafter.yml (1)
8-9: ⚡ Quick winPrefer running this workflow only on default-branch pushes.
Lines 8-9 add PR-event runs that are unnecessary for “merged-to-main” release drafting and can create noisy or permission-constrained runs.
Proposed simplification
on: push: branches: - main - master - pull_request: - types: [opened, reopened, synchronize]🤖 Prompt for 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. In @.github/workflows/release-drafter.yml around lines 8 - 9, The workflow currently triggers on pull_request events (the pull_request block) which is unnecessary; remove the pull_request trigger (or restrict it) and ensure the workflow only runs on pushes to the default branch by keeping/adding a push trigger with branches set to your default branch (e.g., branches: [main] or your repo's default branch name) so release drafting runs only on merged-to-default-branch pushes.
🤖 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/release-drafter.yml:
- Line 22: Replace the movable tag "release-drafter/release-drafter@v6" with the
full commit SHA that corresponds to the v6.4.0 release (i.e., change the uses
line in the workflow to "release-drafter/release-drafter@<full-commit-sha>");
locate the correct SHA from the release-drafter GitHub repo (the v6.4.0 tag or
release commit) and use that exact SHA so the action is pinned to an immutable
commit.
In `@CHANGELOG.md`:
- Around line 1-132: Add standard Keep a Changelog headings: make the top line a
level-1 title "Changelog", keep the one-line project description as a paragraph
under it, then introduce a "## [Unreleased]" section (if applicable) followed by
each released version as level-2 headings like "## [0.9.0] - 2026-04-15" and
convert each release's categories into level-3 headings "### Added", "###
Changed", "### Fixed" grouping the listed items under those subheadings; ensure
existing version markers such as "[0.9.0]" and section labels ("Added",
"Changed", "Fixed") are preserved but promoted to the appropriate Markdown
heading levels.
---
Nitpick comments:
In @.github/workflows/release-drafter.yml:
- Around line 8-9: The workflow currently triggers on pull_request events (the
pull_request block) which is unnecessary; remove the pull_request trigger (or
restrict it) and ensure the workflow only runs on pushes to the default branch
by keeping/adding a push trigger with branches set to your default branch (e.g.,
branches: [main] or your repo's default branch name) so release drafting runs
only on merged-to-default-branch pushes.
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 19cfc916-4223-4dcc-890c-9a799b7cc0fe
📒 Files selected for processing (3)
.github/release-drafter.yml.github/workflows/release-drafter.ymlCHANGELOG.md
|
Is This really usefull For urBackend? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainGreat question, 🏁 Script executed: Length of output: 6092
❌ 1. CHANGELOG.md Dates Are Wrong (Fabricated)The dates in the CHANGELOG don't match the actual GitHub release dates at all:
❌ 2. CHANGELOG.md Content Doesn't Match Actual ReleasesThe written entries appear to be fabricated and don't reflect what was actually shipped:
The entries need to be sourced directly from the existing GitHub Releases page, not written from scratch. ❌ 3. Release Drafter Labels Don't Match Repo LabelsThe release-drafter config references labels that don't exist in this repo:
Consequences:
✅ What's Good
Suggested Fixes
version-resolver:
minor:
labels:
- "feature"
- "enhancement"
patch:
labels:
- "bug"
- "chore"
default: "patch"
categories:
- title: "🚀 Added"
labels:
- "feature"
- "enhancement"
- title: "🐛 Fixed"
labels:
- "bug"
- title: "📝 Documentation"
labels:
- "documentation"Would you like me to open a review comment on the PR directly flagging these issues? 🐇 |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/release-drafter.yml (2)
4-26: ⚡ Quick winConsider adding categories for security fixes and breaking changes.
Common release-drafter configurations include categories for security vulnerabilities and breaking changes to highlight critical updates. Without them, security fixes and breaking changes may be grouped under generic categories or omitted entirely.
♻️ Suggested configuration additions
Add to
version-resolver:version-resolver: + major: + labels: + - 'breaking' minor: labels: - 'feature' - 'enhancement' patch: labels: - 'bug' - 'chore' - 'documentation' + - 'security' default: patchAdd to
categories:categories: - title: '🚀 Added' labels: - 'feature' - 'enhancement' - title: '🐛 Fixed' labels: - 'bug' + - title: '🔒 Security' + labels: + - 'security' + - title: '💥 Breaking Changes' + labels: + - 'breaking' - title: '📝 Documentation' labels: - 'documentation' - title: '🧹 Chore' labels: - 'chore'🤖 Prompt for 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. In @.github/release-drafter.yml around lines 4 - 26, Add explicit "security" and "breaking" entries to both the version-resolver and categories sections so security fixes and breaking changes are identified and released correctly: update the version-resolver to include a "security" level (mapped to a label like 'security') and a "major" or "breaking" level (mapped to a 'breaking' or 'major' label), and add corresponding category blocks under categories with titles like '🔒 Security' (labels: 'security') and '⚠️ Breaking changes' (labels: 'breaking' or 'major') so that the release-drafter YAML recognizes and highlights those PRs; ensure the label names match your repo's existing labels and reference the top-level keys version-resolver and categories when making the edits.
12-12: ⚡ Quick winThe
chorelabel has no corresponding changelog category.Line 12 includes
chorein thepatchversion bump rules, but no category in lines 16–26 includeschore. PRs labeled withchorewill bump the patch version but won't appear in the generated release notes.♻️ Add a category for chore changes
- title: '📝 Documentation' labels: - 'documentation' + - title: '🧹 Chore' + labels: + - 'chore'🤖 Prompt for 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. In @.github/release-drafter.yml at line 12, The release-drafter config lists 'chore' as a patch bump rule but has no matching changelog category, so add a category entry that matches the 'chore' label (e.g., a category with name/title like "Chores" and label: 'chore') under the existing categories section so PRs labeled chore appear in release notes and still trigger patch bumps; alternatively map 'chore' into an existing category by adding 'chore' to that category's labels.
🤖 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.
Nitpick comments:
In @.github/release-drafter.yml:
- Around line 4-26: Add explicit "security" and "breaking" entries to both the
version-resolver and categories sections so security fixes and breaking changes
are identified and released correctly: update the version-resolver to include a
"security" level (mapped to a label like 'security') and a "major" or "breaking"
level (mapped to a 'breaking' or 'major' label), and add corresponding category
blocks under categories with titles like '🔒 Security' (labels: 'security') and
'⚠️ Breaking changes' (labels: 'breaking' or 'major') so that the
release-drafter YAML recognizes and highlights those PRs; ensure the label names
match your repo's existing labels and reference the top-level keys
version-resolver and categories when making the edits.
- Line 12: The release-drafter config lists 'chore' as a patch bump rule but has
no matching changelog category, so add a category entry that matches the 'chore'
label (e.g., a category with name/title like "Chores" and label: 'chore') under
the existing categories section so PRs labeled chore appear in release notes and
still trigger patch bumps; alternatively map 'chore' into an existing category
by adding 'chore' to that category's labels.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 016dfbf4-8596-4fe6-b402-1ec6b62a2d30
📒 Files selected for processing (3)
.github/release-drafter.yml.github/workflows/release-drafter.ymlCHANGELOG.md
✅ Files skipped from review due to trivial changes (1)
- CHANGELOG.md
|
@yash-pouranik u can verify again |
|
@coderabbitai |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chainSure, let me re-check the current state of the PR branch to see if the issues have been addressed. 🏁 Script executed: Length of output: 10582
✅ Issues Resolved
|
| Label in Config | Used For | Exists in Repo? |
|---|---|---|
breaking |
Triggers major version bump + "💥 Breaking Changes" section | ❌ No |
security |
Populates "🔒 Security" section | ❌ No |
Impact:
- The major version can never be bumped automatically (no
breakinglabel to apply to PRs). - The 🔒 Security category in release notes will always be empty.
These are low-priority gaps — the core automation will work fine for day-to-day feature/bug/chore PRs. The author can either:
- Create the
breakingandsecuritylabels in the repo, or - Remove those two categories from
.github/release-drafter.ymlto keep the config clean.
Overall verdict: The PR is now in good shape and the main issues are addressed. It's ready to merge once the two minor label gaps above are decided upon.
🐇 (¬ω¬)ノ — much better after the fixes!
|
I will add the required labels, can u please share how this ci will work? |
|
Tip For best results, initiate chat on the files or code changes.
How the Release Drafter CI WorkssequenceDiagram
participant Dev as Developer
participant GH as GitHub
participant RD as Release Drafter Action
participant Draft as Draft Release
Dev->>GH: Open PR with labels (e.g. "feature", "bug")
Dev->>GH: Merge PR → push to main
GH->>RD: Trigger release-drafter.yml workflow
RD->>GH: Read all merged PRs since last release tag
RD->>RD: Group by label → build changelog categories
RD->>RD: Calculate next version via version-resolver rules
RD->>Draft: Create/Update Draft Release with changelog + version
Dev->>GH: Manually publish Draft Release when ready
Step-by-Step Flow1. You label a PR before merging
2. PR is merged to The workflow in 3. Release Drafter runs It scans all merged PRs since the last published release tag, groups their titles by label into changelog sections, and calculates the next semantic version. 4. A Draft Release is created/updated You'll find it under Releases → Draft on GitHub. The draft body will look something like: 5. You publish the release manually The draft is never auto-published — you review it, tweak the notes if needed, and click Publish Release when you're ready. The tag Key Point
|
|
What I need before merging this PR? |
|
Tip For best results, initiate chat on the files or code changes.
✅ Already Done (no action needed)
🔲 Still To Do Before (or right after) MergingCreate 2 missing labels in the repo:
You can create them quickly via GitHub UI at Settings → Labels → New label, or I can run the SummaryOnce those 2 labels exist in the repo, the PR is ready to merge. The automation will work correctly for all day-to-day PRs immediately after merging. 🐇 |
|
and githubtoken? |
|
Tip For best results, initiate chat on the files or code changes.
|
| Item | Status |
|---|---|
GITHUB_TOKEN setup |
✅ Nothing to do — fully automatic |
contents: write permission |
✅ Already in the workflow file |
Create breaking label |
🔲 Do this before/after merging |
Create security label |
🔲 Do this before/after merging |
You're good — just create those 2 labels and you're ready to merge! 🐇 (◕‿◕✿)
|
@Mansi0905 u still here |
|
yep im . the suggestions of coderabbit will be completed tomorrow .no worries r |
|
I dont think theres any update neede? |
well yeah u are correct there is no need for updates atp. but let's just try to see the extra steps required. i mean we can give it a try |
|
@coderabbitai
|
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 1405 🏁 Script executed: Length of output: 14564
1. Should you stop committing directly to
|
| Action | Release Drafter | Weekly Changelog Automation |
|---|---|---|
Direct commit to main |
❌ Ignored — it only reads merged PRs | |
PR merged to main |
✅ Picked up, labelled, categorised | ✅ Rich context: PR title, body, labels, author |
Currently your branch protection is off — so nothing enforces PRs right now. You can either:
- Enable branch protection rules at Settings → Branches → Add rule (require PR + 1 approval), or
- Use PRs as a team discipline without enforcement for now.
Hotfixes and tiny config tweaks can still go direct — but for features and meaningful changes, PRs give you the Release Drafter benefits automatically.
2. Weekly Mintlify Changelog Automation — Yes, this is totally doable! 🎯
Your existing format is already well-structured. Here's the design:
sequenceDiagram
participant Cron as Monday 9AM (Cron)
participant GH as GitHub Actions
participant AI as OpenAI API
participant Docs as mintlify/docs/changelog/
Cron->>GH: Trigger workflow
GH->>GH: git log --since=7days (merged PRs + commits)
GH->>GH: git diff HEAD~N (last 7 days of changes)
GH->>AI: Send commit messages + diff summary
AI->>GH: Return <Update> block in Mintlify MDX format
GH->>Docs: Append to current month's .mdx file
GH->>GH: Open a PR for human review
Note over GH: Never auto-merges — you stay in control
The output would automatically match your existing format:
<Update label="2026-05-26" description="Week of May 20–26" tags={["Feature", "Fix"]}>
## New features
...
## Bug fixes
...
</Update>One important requirement: This needs an OpenAI API key (stored as OPENAI_API_KEY in GitHub Secrets) to read the diffs and generate human-readable summaries. Without AI, you'd only get raw commit messages formatted — which is less useful.
Plan: Weekly Mintlify Changelog Automation
- Create
.github/workflows/weekly-changelog.yml— Monday cron, collects 7-day git history, calls OpenAI, appends to the current month's MDX file, opens a PR - Create
.github/scripts/generate-changelog-entry.js— Node.js helper script that formats the AI response into a valid Mintlify<Update>block and patches the right monthly file
Setup Checklist for the Automation
Once merged, you'll need to do one thing:
- Add
OPENAI_API_KEYto GitHub Secrets
→ Settings → Secrets and variables → Actions → New repository secret
→ Name:OPENAI_API_KEY, Value: your OpenAI key
That's it. Every Monday at 9 AM UTC a PR will open automatically with the AI-generated changelog entry for you to review and merge.
Note on direct commits: The workflow above opens a PR (not a direct commit), so it also feeds into Release Drafter — two automations working together. 🐇
(◕‿◕✿)
🏁 Script executed:
#!/bin/bash
# Check if there's already a scripts dir in .github
ls .github/ 2>/dev/null
Length of output: 70
@yash-pouranik — confirmed, no scripts/ folder exists yet. Here are the two files to create:
File 1: .github/workflows/weekly-changelog.yml
name: Weekly Mintlify Changelog
on:
schedule:
- cron: "0 9 * * 1" # Every Monday at 9 AM UTC
workflow_dispatch: # Manual trigger anytime
permissions:
contents: write
pull-requests: write
jobs:
generate-changelog:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
fetch-depth: 0 # Full history needed for git log
- name: Set up Node.js
uses: actions/setup-node@v4
with:
node-version: "20"
- name: Collect last 7 days of merged PRs and commits
id: collect
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
SINCE=$(date -d '7 days ago' --utc +%Y-%m-%dT%H:%M:%SZ)
TODAY=$(date --utc +%Y-%m-%d)
WEEK_START=$(date -d '7 days ago' --utc +%Y-%m-%d)
echo "today=$TODAY" >> $GITHUB_OUTPUT
echo "week_start=$WEEK_START" >> $GITHUB_OUTPUT
gh pr list \
--repo ${{ github.repository }} \
--state merged \
--base main \
--json number,title,body,labels,mergedAt,author \
--jq "[.[] | select(.mergedAt >= \"$SINCE\")]" \
> /tmp/merged_prs.json
git log --since="7 days ago" --oneline --no-merges > /tmp/commits.txt || true
git diff --stat "HEAD@{7 days ago}" HEAD -- \
':!package-lock.json' ':!*.lock' ':!*.snap' \
2>/dev/null | tail -20 > /tmp/diff_stat.txt || true
- name: Generate changelog entry via OpenAI
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
node .github/scripts/generate-changelog-entry.js \
/tmp/merged_prs.json \
/tmp/commits.txt \
/tmp/diff_stat.txt \
"${{ steps.collect.outputs.today }}" \
"${{ steps.collect.outputs.week_start }}" \
> /tmp/new_entry.mdx
echo "=== Generated entry preview ==="
cat /tmp/new_entry.mdx
- name: Prepend entry to current month's changelog file
run: |
MONTH=$(date --utc +%B | tr '[:upper:]' '[:lower:]')
YEAR=$(date --utc +%Y)
FILE="mintlify/docs/changelog/${MONTH}-${YEAR}.mdx"
if [ ! -f "$FILE" ]; then
cat > "$FILE" << EOF
---
title: Changelog ($(date --utc +"%B %Y"))
description: What's new in urBackend — new features, improvements, and fixes for $(date --utc +"%B").
---
EOF
fi
# Insert new entry right after the frontmatter closing ---
FRONTMATTER_END=$(grep -n "^---$" "$FILE" | sed -n '2p' | cut -d: -f1)
if [ -z "$FRONTMATTER_END" ]; then
cat /tmp/new_entry.mdx >> "$FILE"
else
{
head -n "$FRONTMATTER_END" "$FILE"
echo ""
cat /tmp/new_entry.mdx
echo ""
tail -n +"$((FRONTMATTER_END + 1))" "$FILE"
} > /tmp/patched.mdx
mv /tmp/patched.mdx "$FILE"
fi
echo "Updated: $FILE"
- name: Open Pull Request
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
BRANCH="changelog/week-of-${{ steps.collect.outputs.week_start }}"
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]`@users.noreply.github.com`"
git checkout -b "$BRANCH"
git add mintlify/docs/changelog/
git commit -m "docs: weekly changelog update for week of ${{ steps.collect.outputs.week_start }}"
git push origin "$BRANCH"
gh pr create \
--repo ${{ github.repository }} \
--base main \
--head "$BRANCH" \
--title "docs: weekly changelog (week of ${{ steps.collect.outputs.week_start }})" \
--body "## Weekly Changelog Update
Auto-generated changelog entry for the week of **${{ steps.collect.outputs.week_start }}** → **${{ steps.collect.outputs.today }}**.
Please review the AI-generated entries for accuracy before merging.
> 🤖 Generated by the weekly-changelog workflow. Edit this PR to correct any inaccuracies before merging." \
--label "documentation"File 2: .github/scripts/generate-changelog-entry.js
const fs = require("fs");
const https = require("https");
const [, , prsFile, commitsFile, diffStatFile, today, weekStart] =
process.argv;
const prs = JSON.parse(fs.readFileSync(prsFile, "utf8"));
const commits = fs.readFileSync(commitsFile, "utf8").trim();
const diffStat = fs.readFileSync(diffStatFile, "utf8").trim();
// Nothing merged this week — emit a minimal placeholder
if (!prs.length && !commits) {
process.stdout.write(
`<Update label="${today}" description="Week of ${weekStart}–${today}" tags={["Improvement"]}>\n\nNo significant changes this week.\n\n</Update>\n`
);
process.exit(0);
}
const prSummary = prs
.map(
(pr) =>
`- PR #${pr.number} by @${pr.author?.login ?? "unknown"}: ${pr.title}\n` +
` Labels: ${(pr.labels ?? []).map((l) => l.name).join(", ") || "none"}\n` +
` ${(pr.body ?? "").slice(0, 400).replace(/\n+/g, " ")}`
)
.join("\n\n");
const prompt = `You are a technical writer for urBackend, a Backend-as-a-Service platform (auth, database, storage, mail, webhooks, RLS).
Based on the merged pull requests and git activity below, write a Mintlify changelog entry for the week of ${weekStart} to ${today}.
## Merged PRs:
${prSummary || "None"}
## Recent commits:
${commits || "None"}
## Files changed (summary):
${diffStat || "None"}
## Output rules:
- Output ONLY the raw <Update> MDX block — no explanation, no markdown fences.
- Use this exact structure:
<Update label="${today}" description="Week of ${weekStart}–${today}" tags={["Feature", "Improvement", "Fix"]}>
## New features
**Feature name** — User-facing description. [Doc link if obvious]
## Improvements
**Improvement name** — Description.
## Bug fixes
- Fix description.
</Update>
- Only include sections (## New features / ## Improvements / ## Bug fixes) that have actual content.
- Adjust the tags array to only include applicable tags: "Feature", "Improvement", "Fix", "Security".
- Write for developers using the platform, not the internal team.
- Be concise and factual. Do not invent features not evidenced by the input.
- If all changes are internal/infra with no user-visible impact, write a single brief Improvements bullet.`;
const payload = JSON.stringify({
model: "gpt-4o-mini",
messages: [{ role: "user", content: prompt }],
max_tokens: 1000,
temperature: 0.3,
});
const options = {
hostname: "api.openai.com",
path: "/v1/chat/completions",
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${process.env.OPENAI_API_KEY}`,
"Content-Length": Buffer.byteLength(payload),
},
};
const req = https.request(options, (res) => {
let data = "";
res.on("data", (chunk) => (data += chunk));
res.on("end", () => {
try {
const response = JSON.parse(data);
if (response.error) {
console.error("OpenAI error:", response.error.message);
process.exit(1);
}
process.stdout.write(response.choices[0].message.content.trim() + "\n");
} catch (e) {
console.error("Failed to parse OpenAI response:", e.message);
process.exit(1);
}
});
});
req.on("error", (e) => {
console.error("Request error:", e.message);
process.exit(1);
});
req.write(payload);
req.end();Final setup steps
| Step | Where | Action |
|---|---|---|
| 1 | GitHub → Settings → Secrets → Actions | Add OPENAI_API_KEY |
| 2 | GitHub → Settings → Branches | Add branch protection rule on main (require PR) |
| 3 | After merging this PR (#184) |
Test via Actions → Weekly Mintlify Changelog → Run workflow |
The workflow opens a PR every Monday for your review — you're never auto-publishing anything. 🐇 (◕‿◕✿)
Failed to handle agent chat message. Please try again.
|
@coderabbitai |
|
Tip For best results, initiate chat on the files or code changes.
Token limit concern? Not at all 🟢The free tier standard cap is 30 requests/min, 6,000 tokens/min, and 14,400 requests/day per model. The weekly changelog workflow makes exactly 1 API call per week — the prompt (PR titles + commits + diff stat) will be around ~1,500 input tokens and the response ~500 output tokens. You're nowhere near any limit. No credit card required — just sign up at console.groq.com and you're making API calls within minutes. Changes needed in the scriptThe Groq API is OpenAI-compatible, so you can point the OpenAI SDK at Groq's base URL with a one-line change. Here's the updated // Change 1: hostname + path
const options = {
hostname: "api.groq.com",
path: "/openai/v1/chat/completions", // ← Groq's OpenAI-compatible endpoint
method: "POST",
headers: {
"Content-Type": "application/json",
Authorization: `Bearer ${process.env.GROQ_API_KEY}`, // ← GROQ_API_KEY
"Content-Length": Buffer.byteLength(payload),
},
};
// Change 2: model name in payload
const payload = JSON.stringify({
model: "openai/gpt-oss-120b", // ← Groq model ID
messages: [{ role: "user", content: prompt }],
max_tokens: 1000,
temperature: 0.3,
});And in - name: Generate changelog entry via Groq
env:
GROQ_API_KEY: ${{ secrets.GROQ_API_KEY }} # ← was OPENAI_API_KEY
run: |
node .github/scripts/generate-changelog-entry.js ...Updated setup checklist
That's it — completely free, no credit card, and fast inference. 🐇 |
|
@Mansi0905 |
|
@coderabbitai |
idk man was stdying for exam but my mind was here, so i just appeared again |
|
Exactly!! |
|
@coderabbitai |
yeah true that, idk struggling a lot trying my best, |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 8794
✅ All Code/Files — Done
🔲 Two Things Still Need To Be Done (by you — repo access required)1. Create 2 missing labels → Settings → Labels → New label
2. Add
|
|
then leave end sems that is joke, just create one more issue and start working. |
|
@coderabbitai |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 873
I can create them for you right now — just say the word and I'll run: gh label create "breaking" --repo geturbackend/urBackend --color "`#e11d48`" --description "Triggers major version bump"
gh label create "security" --repo geturbackend/urBackend --color "`#7c3aed`" --description "Security-related changes"Or you can add them manually at Settings → Labels → New label. Once those two are created, your final merge checklist looks like this:
Also, the open question from earlier — should the weekly workflow update |
|
@coderabbitai |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 1255
Updated final pre-merge checklist:
One open question before merging 👇The weekly workflow currently writes to root |
|
@coderabbitai |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 9816
|
| Automation | What it actually does | Updates CHANGELOG.md on disk? |
|---|---|---|
| Release Drafter | Creates/updates a GitHub Draft Release on the Releases page when a PR is merged to main |
❌ No — it only writes to GitHub Releases UI |
| Weekly workflow | Runs every Monday, collects 7-day PRs, generates AI summary | Should write to Mintlify MDX (currently broken — writes to root CHANGELOG.md) |
So the two tracks are:
flowchart LR
PR[PR merged to main] --> RD[Release Drafter]
RD --> GHR[GitHub Draft Release\n on Releases page\n with semver tag]
CRON[Every Monday 9AM] --> WW[Weekly Groq Workflow]
WW --> MDX[mintlify/docs/changelog/\nmay-2026.mdx\njune-2026.mdx etc.\n with <Update> MDX blocks]
Root CHANGELOG.md stays as a static historical document (v0.1.0–v0.9.0) — it doesn't auto-update.
What needs to change — 2 files, @Mansi0905
Fix 1: .github/workflows/weekly-changelog.yml
Replace the Prepend entry to CHANGELOG.md step with:
- name: Prepend entry to current month's Mintlify changelog
run: |
MONTH=$(date --utc +%B | tr '[:upper:]' '[:lower:]')
YEAR=$(date --utc +%Y)
FILE="mintlify/docs/changelog/${MONTH}-${YEAR}.mdx"
# Create monthly file if it doesn't exist yet
if [ ! -f "$FILE" ]; then
cat > "$FILE" << EOF
---
title: Changelog
description: What's new in urBackend — new features, improvements, and fixes.
---
EOF
fi
# Insert new <Update> entry right after the closing --- of frontmatter
FRONTMATTER_END=$(grep -n "^---$" "$FILE" | sed -n '2p' | cut -d: -f1)
if [ -z "$FRONTMATTER_END" ]; then
cat changelog_entry.md >> "$FILE"
else
{
head -n "$FRONTMATTER_END" "$FILE"
echo ""
cat changelog_entry.md
echo ""
tail -n +"$((FRONTMATTER_END + 1))" "$FILE"
} > /tmp/patched.mdx
mv /tmp/patched.mdx "$FILE"
fi
echo "Updated: $FILE"
- name: Open Pull Request
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
BRANCH="changelog/week-of-$(date +%Y-%m-%d)"
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]`@users.noreply.github.com`"
git checkout -b "$BRANCH"
git add mintlify/docs/changelog/ # ← was CHANGELOG.md
git diff --staged --quiet && echo "No changes to commit" && exit 0
git commit -m "docs: weekly changelog update $(date +%Y-%m-%d)"
git push origin "$BRANCH"
gh pr create \
--repo ${{ github.repository }} \
--base main \
--head "$BRANCH" \
--title "docs: weekly changelog update $(date +%Y-%m-%d)" \
--body "Auto-generated weekly changelog entry. Please review before merging." \
--label "documentation"Fix 2: .github/scripts/generate-changelog-entry.js
The AI prompt needs to output <Update> MDX format (matching april-2026.mdx) instead of ### Added / ### Fixed markdown. Replace the prompt variable with:
const TODAY = new Date().toISOString().slice(0, 10);
const WEEK_START = new Date(Date.now() - 7 * 24 * 60 * 60 * 1000)
.toISOString()
.slice(0, 10);
const prompt = `You are a technical writer for urBackend, an open-source Backend-as-a-Service platform (auth, database, storage, mail, webhooks, RLS).
Based on the following merged pull requests from the last 7 days, write a Mintlify changelog <Update> entry.
Merged PRs (${prCount} total):
${prSummary}
Output ONLY the raw <Update> MDX block — no explanation, no markdown fences.
Use this exact format (matching the existing changelog style):
<Update label="${TODAY}" description="Week of ${WEEK_START}–${TODAY}" tags={["Feature", "Improvement", "Fix"]}>
## New features
**Feature name** — User-facing description. [Doc link if obvious]
## Improvements
**Improvement name** — Description.
## Bug fixes
- Fix description (`#PR_NUMBER`)
</Update>
Rules:
- Only include sections (## New features / ## Improvements / ## Bug fixes) that have actual content.
- Adjust the tags array to only include applicable tags from: "Feature", "Improvement", "Fix", "Security".
- Write for developers using the platform, not the internal team.
- Be concise and factual. Do not invent features not evidenced by the PRs.
- If no PRs were merged, output a minimal entry: No significant changes this week.`;Summary for @Mansi0905
| File | Change |
|---|---|
.github/workflows/weekly-changelog.yml |
Change target from CHANGELOG.md → mintlify/docs/changelog/{month}-{year}.mdx; update git add path |
.github/scripts/generate-changelog-entry.js |
Update AI prompt to output <Update> MDX format instead of ### Added / ### Fixed markdown |
Once those two changes are committed, the full picture is:
- ✅ PR merged → Release Drafter → GitHub Draft Release (semantic version)
- ✅ Every Monday → Groq AI →
<Update>block prepended to current month's MDX → PR opened for review
🐇 (◕‿◕✿)
There was a problem hiding this comment.
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/scripts/generate-changelog-entry.js (1)
66-96:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winCheck
res.statusCodebefore parsing the body.Currently a non-2xx response is only detected if Groq returns a well-formed JSON body containing
response.error. For HTTP-layer failures (e.g., 429 rate limit with a plain-text body, 502/504 from an upstream proxy returning HTML) you fall through to theJSON.parsecatch with a generic "Failed to parse response" message. Inspectingres.statusCodefirst gives clearer diagnostics and lets you treat retryable failures distinctly if you ever add retry/backoff.♻️ Proposed fix
const req = https.request(options, (res) => { let data = ""; res.on("data", (chunk) => { data += chunk; }); res.on("end", () => { + if (res.statusCode < 200 || res.statusCode >= 300) { + console.error(`Groq API returned HTTP ${res.statusCode}`); + console.error("Raw response:", data); + process.exit(1); + } try { const response = JSON.parse(data);🤖 Prompt for 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. In @.github/scripts/generate-changelog-entry.js around lines 66 - 96, Inside the https.request response handler (the callback using res and inside res.on("end")), check res.statusCode before attempting JSON.parse: if statusCode is not in the 2xx range, log a clear error including the HTTP status code, status message and the raw body (data), and exit non‑zero (or handle retryable codes like 429/502/503/504 specially if you later add backoff); only call JSON.parse(data) when res.statusCode indicates success. This change should be applied around the existing res.on("end") block that currently does JSON.parse and references response.error and response.choices.
🧹 Nitpick comments (3)
.github/workflows/weekly-changelog.yml (2)
84-97: 💤 Low valueFrontmatter detection assumes the second
---is the frontmatter terminator.
grep -n "^---$" | sed -n '2p'picks the 2nd---line in the file. That is correct for a fresh MDX, but if a human ever adds an MDX horizontal rule (---on its own line) above existing<Update>entries, the insertion point shifts into the body and corrupts content. A more robust approach is to find the second---only within the leading frontmatter block (e.g., bail if line 1 isn't---, then locate the next---).🤖 Prompt for 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. In @.github/workflows/weekly-changelog.yml around lines 84 - 97, The current FRONTMATTER_END logic assumes the second "---" anywhere is the frontmatter end; update the detection so it first verifies the file starts with "---" (line 1) and only then searches for the next "---" after line 1 to set FRONTMATTER_END (instead of using grep ... | sed -n '2p'); change the code that builds /tmp/patched.mdx to use this new FRONTMATTER_END and fall back to appending changelog_entry.mdx when the file doesn't start with a frontmatter delimiter or no terminating "---" is found.
67-71: 💤 Low valueUse UTC consistently for date-derived names.
Line 69-70 correctly uses
date --utcto pick the monthly file, but lines 105, 111, 117 usedatewithout--utc. Onubuntu-latestthe system clock is already UTC so this currently behaves the same, but it's a latent inconsistency that could surface if the runner image changes or if you switch to a self-hosted runner. Worth aligning to avoid the file name and PR title disagreeing across midnight.Also applies to: 105-117
🤖 Prompt for 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. In @.github/workflows/weekly-changelog.yml around lines 67 - 71, The workflow uses date --utc for MONTH and YEAR when building FILE but other date invocations (used to build the changelog filename and PR title later) omit --utc; update every date command that derives names/titles to include --utc (e.g., the MONTH, YEAR, and any DATE or variables used to construct FILE and the PR title/branch) so all name-based date calculations use date --utc consistently (look for usages of the variables FILE, MONTH, YEAR, DATE, and any PR title/branch construction in this workflow and add --utc to their date calls)..github/scripts/generate-changelog-entry.js (1)
89-89: ⚡ Quick winDefensively strip code fences from the model output.
The prompt tells the model to emit raw MDX with "no markdown fences", but LLMs occasionally wrap output in
```mdx ... ```regardless. Sincecontent.trim()is written straight into a.mdxfile that Mintlify will render, an accidental fence will break the rendered page. A smallreplace(/^```\w*\n?|\n?```$/g, '')before writing is cheap insurance.♻️ Proposed fix
- process.stdout.write(content.trim()); + const cleaned = content + .trim() + .replace(/^```(?:mdx|md)?\s*\n?/, "") + .replace(/\n?```$/, ""); + process.stdout.write(cleaned);🤖 Prompt for 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. In @.github/scripts/generate-changelog-entry.js at line 89, The code currently writes content.trim() directly via process.stdout.write(content.trim()); to the .mdx output; update the write step to defensively strip optional Markdown/M DX code fences from the model output by creating a cleaned string from content (e.g., const cleaned = content.trim().replace(/(^```(?:mdx|md)?\s*\n?)|(\n?```$)/g, "");) and then call process.stdout.write(cleaned) instead of writing content.trim(); this ensures any accidental surrounding ``` fences are removed before output.
🤖 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/weekly-changelog.yml:
- Around line 105-112: The branch name BRANCH="changelog/week-of-$(date
+%Y-%m-%d)" is deterministic and will cause git checkout -b "$BRANCH" or git
push origin "$BRANCH" to fail on same-day re-runs; update the workflow to make
BRANCH unique per run (e.g., append a timestamp or GITHUB_RUN_ID) or change the
git commands to be idempotent by using git checkout -B "$BRANCH" (replace
existing local branch) and git push --force-with-lease origin "$BRANCH" (safe
update if remote exists) so repeated executions succeed; apply this change to
the BRANCH assignment and the git checkout/git push steps referenced above.
---
Outside diff comments:
In @.github/scripts/generate-changelog-entry.js:
- Around line 66-96: Inside the https.request response handler (the callback
using res and inside res.on("end")), check res.statusCode before attempting
JSON.parse: if statusCode is not in the 2xx range, log a clear error including
the HTTP status code, status message and the raw body (data), and exit non‑zero
(or handle retryable codes like 429/502/503/504 specially if you later add
backoff); only call JSON.parse(data) when res.statusCode indicates success. This
change should be applied around the existing res.on("end") block that currently
does JSON.parse and references response.error and response.choices.
---
Nitpick comments:
In @.github/scripts/generate-changelog-entry.js:
- Line 89: The code currently writes content.trim() directly via
process.stdout.write(content.trim()); to the .mdx output; update the write step
to defensively strip optional Markdown/M DX code fences from the model output by
creating a cleaned string from content (e.g., const cleaned =
content.trim().replace(/(^```(?:mdx|md)?\s*\n?)|(\n?```$)/g, "");) and then call
process.stdout.write(cleaned) instead of writing content.trim(); this ensures
any accidental surrounding ``` fences are removed before output.
In @.github/workflows/weekly-changelog.yml:
- Around line 84-97: The current FRONTMATTER_END logic assumes the second "---"
anywhere is the frontmatter end; update the detection so it first verifies the
file starts with "---" (line 1) and only then searches for the next "---" after
line 1 to set FRONTMATTER_END (instead of using grep ... | sed -n '2p'); change
the code that builds /tmp/patched.mdx to use this new FRONTMATTER_END and fall
back to appending changelog_entry.mdx when the file doesn't start with a
frontmatter delimiter or no terminating "---" is found.
- Around line 67-71: The workflow uses date --utc for MONTH and YEAR when
building FILE but other date invocations (used to build the changelog filename
and PR title later) omit --utc; update every date command that derives
names/titles to include --utc (e.g., the MONTH, YEAR, and any DATE or variables
used to construct FILE and the PR title/branch) so all name-based date
calculations use date --utc consistently (look for usages of the variables FILE,
MONTH, YEAR, DATE, and any PR title/branch construction in this workflow and add
--utc to their date calls).
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: b37062b9-5e44-443a-aa97-faf259cfba67
📒 Files selected for processing (2)
.github/scripts/generate-changelog-entry.js.github/workflows/weekly-changelog.yml
|
is everything as plan? @coderabbitai ? |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 10460
How it all works post-merge:flowchart LR
A[PR merged to main] --> B[Release Drafter workflow]
B --> C[GitHub Draft Release\nupdated with semver tag]
D[Every Monday 9AM UTC] --> E[Weekly Mintlify Changelog workflow]
E --> F[Groq openai/gpt-oss-120b\ngenerates Update MDX block]
F --> G[Prepended to mintlify/docs/changelog/\nmay-2026.mdx, june-2026.mdx etc.]
G --> H[PR opened for your review\nnever auto-merges]
You're good to merge — just add |
|
I hope these workflows will not run on PR? @coderabbitai > |
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 414
Neither has a The only thing that kicks off Release Drafter is an actual merge (push) to |
|
@Mansi0905 |
thank you for the patience and helping me |
2 participants
Description
This PR addresses the missing and fragmented changelogs by introducing a unified
CHANGELOG.mdand setting up automated release drafting workflows. This dual-solution provides clear historical context for users and eliminates manual overhead for maintainers when cutting new releases.Key Changes
Structured
CHANGELOG.md:v0.1.0throughv0.9.0into a single file in the root directory.Automated Release notes Workflow:
.github/workflows/release-drafter.ymlto trigger the automatic update of draft releases when Pull Requests are merged into the main branch..github/release-drafter.ymlto configure the Release Drafter. It maps labels on merged Pull Requests (likefeat,fix,docs,security) to the corresponding headings in the draft release notes and automatically calculates the next semantic version number.Related Issues
Closes #183
Checklist
.github/and.github/workflows/)Summary by CodeRabbit
Chores
Documentation