EPMRPP-89449 || Load release versions from GitHub#1068
Open
maria-hambardzumian wants to merge 3 commits intodevelopfrom
Open
EPMRPP-89449 || Load release versions from GitHub#1068maria-hambardzumian wants to merge 3 commits intodevelopfrom
maria-hambardzumian wants to merge 3 commits intodevelopfrom
Conversation
WalkthroughAdds a new release-sync workflow and Node.js script to fetch GitHub Releases into docs, and updates the deploy workflow to add a sync-versions job, use GH_TOKEN with explicit checkout/ref, and merge master into develop after deployment. Changes
Sequence DiagramsequenceDiagram
participant User
participant GHA as GitHub Actions
participant Script as sync-releases.js
participant API as GitHub Releases API
participant FS as Repository Filesystem
participant Remote as Git Remote
User->>GHA: Trigger workflow_dispatch / workflow_call (scope, count)
GHA->>Script: Run Node script with GH_TOKEN, RELEASES_URL, SYNC_SCOPE
Script->>API: Fetch releases (paginated) using GH_TOKEN
API-->>Script: Return releases data
Script->>Script: Filter, sort, apply scope, transform body
Script->>FS: Ensure docs/releases/, check existing files
Script->>FS: Write new .md files and .releases-updated
Script->>Remote: Configure user, commit & push docs/releases/
Remote-->>GHA: Push result (changes merged into repo)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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 |
maria-hambardzumian
requested review from
AmsterGet and
pressayuliya
as code owners
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Fix all issues with AI agents
In @.github/workflows/deploy.yml:
- Line 53: The workflows now rely on a custom secret named GH_TOKEN (referenced
as github_token: ${{ secrets.GH_TOKEN }}) so ensure that a Personal Access Token
is added to the repository Secrets as GH_TOKEN, that the PAT includes the
minimum required scopes (e.g., repo or contents: write) and that you have a
rotation/expiry plan for it; update any consumer workflows (deploy step and the
sync-releases usage of secrets.GH_TOKEN) to either validate the secret exists
(fail fast with a clear error) or fall back to GITHUB_TOKEN if appropriate, and
document the required secret name and scope in the repo README or CONTRIBUTING
guide.
In @.github/workflows/sync-releases.yml:
- Around line 29-33: The input "count" is not validated and can be non-numeric,
causing SYNC_SCOPE to become invalid; fix by (a) updating the input to enforce
numeric type and document format (change the input declaration for count to
type: number and adjust the description to "Number of releases to check
(positive integer, only used with \"last-n\")"), and/or (b) add a validation
step early in the workflow that reads the input "count" and checks it against a
regex like ^[1-9]\d*$ (fail the job with a clear error if it doesn't match)
before constructing SYNC_SCOPE so you never set SYNC_SCOPE to an invalid
"last-<value>".
In `@scripts/sync-releases.js`:
- Around line 165-176: The buildFileName function currently normalizes release
names by stripping stage suffixes via stripPrefix and
v.replace(...Final|RC|Beta|Alpha...), which causes collisions between stages
(e.g., "5.12 RC" and "5.12 Final" both become Version5.12.md) and also mislabels
BETA as RC in the /^BETA/i branch; update buildFileName to preserve the stage
qualifier in the generated filename (or add a clear code comment if intentional
to dedupe stages) and change the /^BETA/i branch to emit a Beta-specific
filename (e.g., Version{nums}Beta.md or preserve the original qualifier) rather
than Version{nums}RC.md; reference the buildFileName function and stripPrefix
call to locate and adjust the suffix-handling logic accordingly.
- Around line 46-48: The sidebar_position conflict happens because position = i
+ 1 is based on the current filtered index but existing files are skipped, so
their front-matter positions aren't updated and new inserts shift indices; to
fix, stop using the loop index and instead compute a deterministic,
non-colliding position: either (A) track createdCount and set position =
createdCount + 1 only for newly-created files (increment createdCount when you
actually write a file), or (B) sort releases by a stable key like
release.published_at and compute position from that order (e.g., position = 1 +
index in the published_at-sorted array) and then rewrite front-matter for all
files accordingly; update the code around buildSidebarLabel(name),
transformBody(...), and where position is assigned so position is derived from
createdCount or the published_at-sorted index instead of i.
- Around line 88-92: The cutoff calculation using
cutoff.setMonth(cutoff.getMonth() - 1) can roll forward on month-boundary dates
(e.g., Mar 31 -> Mar 3); replace that logic in the scope === 'last-month' branch
by computing now = new Date(), then create cutoff = new Date(now.getFullYear(),
now.getMonth() - 1, now.getDate()) and if cutoff.getMonth() !== (now.getMonth()
- 1 + 12) % 12, clamp to the previous month's last day with cutoff = new
Date(now.getFullYear(), now.getMonth(), 0); keep the existing
releases.filter((r) => new Date(r.published_at) >= cutoff) unchanged.
- Around line 110-114: The GH token check and warning are inside the while
(true) pagination loop causing the warning to print for every page; move the
block that checks process.env.GH_TOKEN and sets headers.Authorization (or emits
the console.warn) to execute once before entering the loop so headers is
prepared once and the warning is only emitted a single time; update the code
that currently references headers inside the loop to use the preconfigured
headers.
🧹 Nitpick comments (3)
scripts/sync-releases.js (1)
148-151: URL regex may capture trailing punctuation.The pattern
https?:\/\/[^\s)<>\]]+will absorb trailing periods, commas, or colons that appear right after a URL (e.g.,https://example.com.→ link includes the.). This is a common issue in release notes where sentences end with a URL.You could add common trailing punctuation to the exclusion set or strip it after matching:
Minimal fix — strip trailing punctuation from matched URL
result = result.replace( /(?<!["\(])(?<!\]\()https?:\/\/[^\s)<>\]]+/g, - (url) => `[${extractLabel(url)}](${url})`, + (url) => { + const cleaned = url.replace(/[.,;:!?]+$/, ''); + const trailing = url.slice(cleaned.length); + return `[${extractLabel(cleaned)}](${cleaned})${trailing}`; + }, );.github/workflows/sync-releases.yml (2)
70-77: Direct push to branch — consider if this aligns with your branch strategy.This step pushes directly to whichever branch the workflow is dispatched on, bypassing pull request review. For automated doc generation this is common, but if your branch protection or team process requires review for all changes, consider creating a PR instead. This is just an operational note — no action required if direct push is intended.
44-46: Consider passingGH_TOKENto checkout for consistency with git operations.
actions/checkout@v4defaults toGITHUB_TOKENfor git credentials, and thegit pushat line 77 uses the same credentials. Since you already haveGH_TOKENavailable in the workflow (line 56), it's best practice to use it consistently for all git operations. This ensures the workflow works correctly if the repository has branch protection rules or other configurations that require a PAT instead ofGITHUB_TOKEN.Proposed fix
- name: Checkout repository uses: actions/checkout@v4 + with: + token: ${{ secrets.GH_TOKEN }}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/sync-releases.yml (1)
86-93: Consider pulling before pushing to handle concurrent runs.If two workflow runs execute simultaneously (e.g., scheduled + manual dispatch), the second
git pushwill fail because the remote branch has moved ahead. Agit pull --rebasebefore push would make this more resilient.♻️ Suggested improvement
git add docs/releases/ git commit -m "docs: sync release pages from GitHub Releases" + git pull --rebase git push🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/sync-releases.yml around lines 86 - 93, The push step under the "Commit and push new release pages" job can fail when concurrent workflow runs update the branch; modify that step (the run block in the "Commit and push new release pages" step) to perform a git pull --rebase (preferably git pull --rebase --autostash) before git push so the local branch rebases onto the latest remote and avoids non-fast-forward errors, and keep the subsequent git push as-is; ensure the commands run only when steps.changes.outputs.has_changes == 'true' as currently specified..github/workflows/deploy.yml (1)
44-49: Use--ff-onlyon the pull to fail fast if the ref diverged.If
sync-versionspushed new commits tomaster, this pull picks them up — good. But a baregit pullcould create an unexpected merge commit in the working tree if anything diverged. Using--ff-onlymakes this explicit and fails early on unexpected state.Suggested fix
- name: Pull latest changes - run: git pull origin master + run: git pull --ff-only origin master🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 44 - 49, Change the "Pull latest changes" step to use a fast-forward-only pull so a divergent ref fails the workflow: replace the bare git pull invocation in the step named "Pull latest changes" with git pull --ff-only origin master (so the action fails instead of creating an unexpected merge commit).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/deploy.yml:
- Around line 85-96: The current merge step masks fetch failures, doesn't handle
merge conflicts, and may fail when pushing with the default token; update the
block around the git commands so that git fetch origin develop:develop checks
the exit status and only ignores the specific "branch not found" case (do not
use a blanket "|| exit 0"), detect absence of the develop branch explicitly
before proceeding, run git checkout develop then run git merge --no-ff master -m
"Sync || merge master into develop" but capture its exit code and on non-zero
print a clear message like "Merge conflict — manual resolution needed" and exit
1 (or create a PR/issue flow), and replace the git push origin develop call to
use the GH_TOKEN credentials (consistent with other workflow steps) so
branch-protected pushes succeed or fail with a clear error.
- Around line 67-73: Update the GitHub Actions step named "Deploy" to use the
newer peaceiris/actions-gh-pages action by changing the version tag in the uses
entry from peaceiris/actions-gh-pages@v3 to peaceiris/actions-gh-pages@v4; keep
the rest of the step parameters (github_token, publish_dir, publish_branch,
commit_message) unchanged to ensure behavior is preserved while moving to Node
20-compatible action.
---
Duplicate comments:
In @.github/workflows/deploy.yml:
- Around line 32-37: The GH_TOKEN secret referenced by the reusable workflow
call (job sync-versions using .github/workflows/sync-releases.yml) is
missing/needs provisioning; add GH_TOKEN to the repository (or organization)
secrets with the required scopes (repo and workflow access) and ensure the same
secret is available to the deploy job that also uses secrets.GH_TOKEN; verify
both the sync-versions reusable-workflow invocation and the deploy step consume
the same secrets.GH_TOKEN and that repository settings permit reusable workflows
to access it.
In @.github/workflows/sync-releases.yml:
- Around line 16-52: The reviewer approved the workflow but left a duplicate
review tag; no code changes to workflow_call, workflow_dispatch, or env
RELEASES_URL are needed—remove the redundant "[duplicate_comment]" marker from
the review comment (leave the approval tag "[approve_code_changes]" intact) so
the PR thread isn't flagged as a duplicate, and confirm the existing inputs
'scope' and 'count' remain unchanged.
---
Nitpick comments:
In @.github/workflows/deploy.yml:
- Around line 44-49: Change the "Pull latest changes" step to use a
fast-forward-only pull so a divergent ref fails the workflow: replace the bare
git pull invocation in the step named "Pull latest changes" with git pull
--ff-only origin master (so the action fails instead of creating an unexpected
merge commit).
In @.github/workflows/sync-releases.yml:
- Around line 86-93: The push step under the "Commit and push new release pages"
job can fail when concurrent workflow runs update the branch; modify that step
(the run block in the "Commit and push new release pages" step) to perform a git
pull --rebase (preferably git pull --rebase --autostash) before git push so the
local branch rebases onto the latest remote and avoids non-fast-forward errors,
and keep the subsequent git push as-is; ensure the commands run only when
steps.changes.outputs.has_changes == 'true' as currently specified.
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/deploy.yml:
- Line 73: The commit_message entry currently uses ${
github.event.head_commit.message } which is empty for workflow_dispatch; update
the commit_message field to provide a fallback when github.event.head_commit is
null (e.g., use an expression that checks github.event.head_commit and falls
back to a sensible default like "Manual deployment" or include github.ref/
github.sha). Modify the commit_message key (same place where commit_message: ${{
github.event.head_commit.message }} is defined) to use a conditional expression
that reads github.event.head_commit.message when present and otherwise supplies
the fallback string.
---
Duplicate comments:
In @.github/workflows/deploy.yml:
- Around line 90-92: The git fetch command within the if block ("git fetch
origin develop:develop") is suppressing all errors via "2>/dev/null", which
hides network/auth issues; remove that redirection and instead capture or let
stderr be visible, then explicitly check the fetch exit status and inspect
stderr for the specific "couldn't find remote ref" / "remote ref not found"
message before treating it as "develop branch not found"; log the captured
stderr (or let it print) when non-zero and only treat the case as a missing
branch when the stderr matches the branch-not-found pattern, otherwise fail or
surface the real error.
- Line 68: The workflow action is pinned to peaceiris/actions-gh-pages@v3 which
uses Node 16 (EOL); update the action reference to peaceiris/actions-gh-pages@v4
in the GitHub Actions workflow (replace the uses: peaceiris/actions-gh-pages@v3
entry with `@v4`) and verify any breaking changes in the
peaceiris/actions-gh-pages v4 release notes (adjust inputs/flags in the deploy
job if necessary).
- Line 70: The workflow references a custom secret named github_token under the
key github_token (github_token: ${{ secrets.GH_TOKEN }}), but that secret must
be created and provisioned with the appropriate scopes in the repository/org
secrets; create or update the GH_TOKEN secret in the repository (or org)
settings and ensure it has the required scopes (at minimum repo access and
workflow permissions or a PAT with repo and workflow management scopes) so the
GitHub Actions job can authenticate successfully.
| github_token: ${{ secrets.GH_TOKEN }} | ||
| publish_dir: ./${{ env.BUILD_DIR }} | ||
| publish_branch: gh-pages | ||
| commit_message: ${{ github.event.head_commit.message }} |
There was a problem hiding this comment.
commit_message will be empty on workflow_dispatch triggers.
With the newly added workflow_dispatch trigger (line 26), github.event.head_commit is null for manual dispatches, so ${{ github.event.head_commit.message }} resolves to an empty string. This produces a deploy commit with no meaningful message.
Suggested fix — provide a fallback
- commit_message: ${{ github.event.head_commit.message }}
+ commit_message: ${{ github.event.head_commit.message || format('Manual deploy {0}', github.sha) }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/deploy.yml at line 73, The commit_message entry currently
uses ${ github.event.head_commit.message } which is empty for workflow_dispatch;
update the commit_message field to provide a fallback when
github.event.head_commit is null (e.g., use an expression that checks
github.event.head_commit and falls back to a sensible default like "Manual
deployment" or include github.ref/ github.sha). Modify the commit_message key
(same place where commit_message: ${{ github.event.head_commit.message }} is
defined) to use a conditional expression that reads
github.event.head_commit.message when present and otherwise supplies the
fallback string.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
https://jiraeu.epam.com/browse/EPMRPP-89449
Summary by CodeRabbit
New Features
Chores