Chore:Deprecation of Node 20: migrate actions in workflows to Node 24 versions#3460
Merged
Chore:Deprecation of Node 20: migrate actions in workflows to Node 24 versions#3460
Conversation
chrnorm/deployment-status version maybe has to be updated later on in deploy,yml. That action hasn't migrated to from Node 20 to 24 yet
VariableVince
added
the
Devops
Contributor
WalkthroughGitHub Actions workflows updated: action versions bumped (checkout v4→v5, setup-node v4→v5, create-github-app-token v2→v3, docker/login-action v3→v4, upload-artifact v4→v6), Node runtime moved from 20 to 24, and the deploy workflow now creates deployments and statuses via Changes
Sequence Diagram(s)sequenceDiagram
actor Developer
participant Actions as "GitHub Actions"
participant Checkout as "Checkout / Node\nactions/checkout@v5\nsetup-node@v5 (Node 24)"
participant Registry as "Docker Registry\ndocker/login-action@v4"
participant GH_API as "GitHub API\n(actions/github-script@v8)"
participant Environment as "Deployment Target"
Developer->>Actions: push / trigger workflow
Actions->>Checkout: checkout repo and setup Node 24
Actions->>Registry: authenticate and push image
Actions->>GH_API: createDeployment (repos.createDeployment)
GH_API-->>Actions: returns deployment_id
Actions->>Environment: deploy using image and deployment_id
Actions->>GH_API: createDeploymentStatus (repos.createDeploymentStatus)
GH_API-->>Actions: record success/failure with environment_url
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📝 Coding Plan
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}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
27-30: Pin Node.js 24 locally to match CI.CI jobs are upgraded to Node 24 (lines 29, 48, 60, 73). Add a local version pin using
package.jsonenginesfield and/or.nvmrcfile so developers' machines and CI run the same Node version.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/ci.yml around lines 27 - 30, Add a local Node version pin to match CI's Node 24: update package.json's "engines" field to specify "node": ">=24 <25" (or exact "24.x") and/or add a top-level .nvmrc file containing "24" so developers use the same runtime as the CI that uses actions/setup-node@v5; ensure CI and local pins are consistent and document the requirement in README if needed.
🤖 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 38-40: The workflow sets FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true
which forces all JS actions to Node 24 and will break
chrnorm/deployment-action@v2 and chrnorm/deployment-status@v2 that only support
Node 20; change the env entry FORCE_JAVASCRIPT_ACTIONS_TO_NODE24 to false (or
remove it) in the workflow until those chrnorm/*@v2 actions are upgraded to Node
24 to avoid deployment failures.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 27-30: Add a local Node version pin to match CI's Node 24: update
package.json's "engines" field to specify "node": ">=24 <25" (or exact "24.x")
and/or add a top-level .nvmrc file containing "24" so developers use the same
runtime as the CI that uses actions/setup-node@v5; ensure CI and local pins are
consistent and document the requirement in README if needed.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: f60283cf-0e77-432f-bce8-859c755808f8
📒 Files selected for processing (6)
.github/workflows/ci.yml.github/workflows/deploy.yml.github/workflows/pr-author.yml.github/workflows/pr-description.yml.github/workflows/pr-stale.yml.github/workflows/release.yml
github-project-automation
bot
moved this from Triage
to Development
in OpenFront Release Management
…cript@v8 (Node 24) and default github API calls
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 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 91-100: Wrap the createDeployment call in a try/catch and validate
the response before using it: call github.rest.repos.createDeployment (passing
required_contexts: [] if you intend deployments to ignore status checks) and
check that the returned `data` and `data.id` exist; on success call
core.setOutput('deployment_id', deployment.id), on failure log the error and
call core.setFailed with a clear message so the workflow fails with useful
diagnostics. Ensure you reference context.ref and process.env.ENVIRONMENT/ FQDN
as before and handle any thrown exception from
github.rest.repos.createDeployment.
- Around line 159-174: The update-status step assumes DEPLOYMENT_ID exists and
directly calls parseInt(process.env.DEPLOYMENT_ID) which yields NaN when empty;
modify the actions/github-script step's script to first validate
process.env.DEPLOYMENT_ID (e.g., check it's defined and that
Number.isInteger(Number(process.env.DEPLOYMENT_ID)) or parseInt produces a
finite number) and bail out (skip calling
github.rest.repos.createDeploymentStatus) when invalid; keep the logic that sets
state using process.env.STATUS and only call
github.rest.repos.createDeploymentStatus with a validated deployment_id and
environment_url when the ID is present.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 169098c9-52e6-4dc5-9544-15c7320473f7
📒 Files selected for processing (1)
.github/workflows/deploy.yml
Extra guards for Update deployment status step
Contributor
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/deploy.yml (1)
71-77:⚠️ Potential issue | 🟠 MajorGate both deployment API steps behind the repo check to prevent failures on workflow_dispatch outside the main repository.
The GitHub App token is created only for
openfrontio/OpenFrontIO(line 73), but the deployment creation step (lines 84–91) and status update step (line 160–162) use that token without the same repo gate. When running outside the main repository,steps.generate-token.outputs.tokenwill be empty, and withpermissions: {}, the implicitgithub.tokenhas nodeployments: writescope. Both steps will fail before the actual deployment starts.Apply repo gate to both deployment steps
- name: 📝 Create deployment + if: ${{ github.repository == 'openfrontio/OpenFrontIO' }} uses: actions/github-script@v8- name: 🔄 Update deployment status - if: ${{ always() && steps.deployment.outcome == 'success' && steps.deployment.outputs.deployment_id != '' }} + if: ${{ github.repository == 'openfrontio/OpenFrontIO' && always() && steps.deployment.outcome == 'success' && steps.deployment.outputs.deployment_id != '' }} uses: actions/github-script@v8🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 71 - 77, The deployment creation and status update steps are not gated by the same repo check as the GitHub App token step (id: generate-token), causing failures when run outside openfrontio/OpenFrontIO; update the workflow so the "Create deployment" and "Update deployment status" steps use the same condition (if: ${{ github.repository == 'openfrontio/OpenFrontIO' }}) or otherwise check that steps.generate-token.outputs.token is present before using it, ensuring both steps only run when the repo matches and the app token exists.
♻️ Duplicate comments (1)
.github/workflows/deploy.yml (1)
93-100:⚠️ Potential issue | 🟠 Major
createDeploymentis still blocked by status checks on push runs.Line 93 still omits
required_contexts, and GitHub verifies all unique commit-status contexts by default unless you pass an empty array. On this workflow'spushpath, that can reject the deployment while CI is still running, which leavesdeployment_idunset and skips the final status update. (docs.github.com)Small fix if previews should start immediately
const { data: deployment } = await github.rest.repos.createDeployment({ owner: context.repo.owner, repo: context.repo.repo, ref: context.ref, environment: process.env.ENVIRONMENT, description: 'Deployment to ' + process.env.FQDN, - auto_merge: false + auto_merge: false, + required_contexts: [] });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 93 - 100, The createDeployment call omits required_contexts so GitHub blocks deployments until status checks complete; update the call that builds the deployment (the github.rest.repos.createDeployment invocation that returns { data: deployment }) to include required_contexts: [] in the options object so the deployment can start immediately, then ensure subsequent code that reads deployment.id or deployment_id still handles the returned deployment and proceeds to set the final status.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.github/workflows/deploy.yml:
- Around line 71-77: The deployment creation and status update steps are not
gated by the same repo check as the GitHub App token step (id: generate-token),
causing failures when run outside openfrontio/OpenFrontIO; update the workflow
so the "Create deployment" and "Update deployment status" steps use the same
condition (if: ${{ github.repository == 'openfrontio/OpenFrontIO' }}) or
otherwise check that steps.generate-token.outputs.token is present before using
it, ensuring both steps only run when the repo matches and the app token exists.
---
Duplicate comments:
In @.github/workflows/deploy.yml:
- Around line 93-100: The createDeployment call omits required_contexts so
GitHub blocks deployments until status checks complete; update the call that
builds the deployment (the github.rest.repos.createDeployment invocation that
returns { data: deployment }) to include required_contexts: [] in the options
object so the deployment can start immediately, then ensure subsequent code that
reads deployment.id or deployment_id still handles the returned deployment and
proceeds to set the final status.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 1b7a36f1-916c-4712-95b1-6395d1a8130d
📒 Files selected for processing (1)
.github/workflows/deploy.yml
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/deploy.yml (1)
178-182: Consider usingcore.warninginstead ofcore.setFailedfor this defensive check.The condition at line 169 already ensures
deployment_idis not empty. This inner validation at lines 178-182 is a belt-and-suspenders check for the rare case where the ID is non-empty but not a valid integer.Using
core.setFailedhere will mark the entire job as failed even if the actual deployment succeeded. Since this is a status-reporting step, failing the job might be misleading.💡 Suggested change
const deploymentId = Number(process.env.DEPLOYMENT_ID); if (!Number.isInteger(deploymentId)) { - core.setFailed('No valid deployment ID, skipping status update'); + core.warning('No valid deployment ID, skipping status update'); return; }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 178 - 182, The current defensive check converts process.env.DEPLOYMENT_ID to deploymentId and calls core.setFailed when it’s not an integer; replace core.setFailed with core.warning so the job isn’t marked failed for this non-critical status-reporting validation. In the block referencing deploymentId and process.env.DEPLOYMENT_ID, call core.warning('No valid deployment ID, skipping status update') (or a similar message) and then return to skip the update, leaving the main job outcome unchanged.
🤖 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 71: The workflow currently uses actions/create-github-app-token@v3 which
introduces breaking changes in v3.0.0; update the deploy workflow to either pin
to a compatible v2 tag (e.g., actions/create-github-app-token@v2) or ensure CI
meets v3 requirements by documenting/adding the necessary environment and
runtime settings: if running on self-hosted runners require Actions Runner
v2.327.1+ and if HTTP_PROXY/HTTPS_PROXY are used set NODE_USE_ENV_PROXY=1 in the
job environment; reference the step using actions/create-github-app-token@v3 to
apply the appropriate change.
---
Nitpick comments:
In @.github/workflows/deploy.yml:
- Around line 178-182: The current defensive check converts
process.env.DEPLOYMENT_ID to deploymentId and calls core.setFailed when it’s not
an integer; replace core.setFailed with core.warning so the job isn’t marked
failed for this non-critical status-reporting validation. In the block
referencing deploymentId and process.env.DEPLOYMENT_ID, call core.warning('No
valid deployment ID, skipping status update') (or a similar message) and then
return to skip the update, leaving the main job outcome unchanged.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5c551730-c6ec-41e7-8e3a-13e82cd06e3b
📒 Files selected for processing (1)
.github/workflows/deploy.yml
Contributor
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:
- Around line 169-177: The "🔄 Update deployment status" step is missing a
required action selector; add a uses: directive (uses: actions/github-script@v8)
to that step so the existing with: script: | block is executed by the
github-script action; ensure the uses: line is placed at the same indentation
level as name/if/env/with and keep the existing with: script content intact so
the deployment update runs correctly.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 37884fdc-8527-49e2-9cc4-97b10990e2be
📒 Files selected for processing (1)
.github/workflows/deploy.yml
Contributor
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:
- Around line 91-100: The createDeployment call currently uses context.ref which
is a branch ref and can be resolved to a different commit later; update the call
to pin the deployment to the trigger commit by replacing the ref argument in the
github.rest.repos.createDeployment invocation with process.env.GITHUB_SHA (the
exact commit SHA), ensuring the deployment record refers to the commit that
started the workflow; locate the createDeployment call that assigns to response
and change only the ref parameter to process.env.GITHUB_SHA.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7db85e0b-0248-4d70-9a92-37619b83b62e
📒 Files selected for processing (1)
.github/workflows/deploy.yml
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/deploy.yml (2)
85-100: Make the deployment environment identify the real target.Line 95 only uses
prod/staging, but this workflow can deploy to different hosts and subdomains. In GitHub Deployments that collapses separate targets into one environment record, so the active/inactive history stops matching the real deploy target.🛠️ Possible adjustment
env: ENVIRONMENT: ${{ inputs.target_domain == 'openfront.io' && 'prod' || 'staging' }} + HOST: ${{ github.event_name == 'workflow_dispatch' && inputs.target_host || 'staging' }} FQDN: ${{ env.FQDN }} with: github-token: ${{ steps.generate-token.outputs.token }} script: | + const environmentName = `${process.env.ENVIRONMENT}:${process.env.HOST}:${process.env.FQDN}`; const response = await github.rest.repos.createDeployment({ owner: context.repo.owner, repo: context.repo.repo, ref: process.env.GITHUB_SHA, - environment: process.env.ENVIRONMENT, + environment: environmentName, description: 'Deployment to ' + process.env.FQDN, auto_merge: false, required_contexts: [], transient_environment: process.env.ENVIRONMENT === 'staging' && context.ref !== 'refs/heads/main', production_environment: process.env.ENVIRONMENT === 'prod' });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 85 - 100, The deployment environment should include the real target host so GitHub Deployment records are unique per host; update the createDeployment call to set the environment to a string that combines the current ENVIRONMENT and the actual target (use inputs.target_domain or FQDN) instead of just ENVIRONMENT alone (modify the environment argument passed to github.rest.repos.createDeployment and ensure any checks that compute transient_environment/production_environment still derive from ENVIRONMENT); e.g., build the environment name from ENVIRONMENT + a separator + FQDN/inputs.target_domain so each subdomain/host gets its own GitHub Deployment environment.
176-181: Add the workflow run link to the deployment status.The new REST call keeps
environment_url, but it drops the easy link back to the run that produced the status. Addinglog_urlmakes deployment failures much easier to trace from the Deployments UI.🔎 Possible improvement
await github.rest.repos.createDeploymentStatus({ owner: context.repo.owner, repo: context.repo.repo, deployment_id: process.env.DEPLOYMENT_ID, state: process.env.STATUS === 'success' ? 'success' : 'failure', - environment_url: 'https://' + process.env.FQDN + environment_url: 'https://' + process.env.FQDN, + log_url: `${process.env.GITHUB_SERVER_URL}/${process.env.GITHUB_REPOSITORY}/actions/runs/${process.env.GITHUB_RUN_ID}` });🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/deploy.yml around lines 176 - 181, The deployment status call to github.rest.repos.createDeploymentStatus omits a link back to the workflow run; add the log_url field to that call so the Deployments UI links to the run that produced the status. Update the createDeploymentStatus call (the same block that sets environment_url) to include log_url and set it to the Actions run URL (for example by constructing it from GITHUB_SERVER_URL + '/' + GITHUB_REPOSITORY + '/actions/runs/' + GITHUB_RUN_ID or the equivalent context/run variables available in this workflow).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/deploy.yml:
- Around line 85-100: The deployment environment should include the real target
host so GitHub Deployment records are unique per host; update the
createDeployment call to set the environment to a string that combines the
current ENVIRONMENT and the actual target (use inputs.target_domain or FQDN)
instead of just ENVIRONMENT alone (modify the environment argument passed to
github.rest.repos.createDeployment and ensure any checks that compute
transient_environment/production_environment still derive from ENVIRONMENT);
e.g., build the environment name from ENVIRONMENT + a separator +
FQDN/inputs.target_domain so each subdomain/host gets its own GitHub Deployment
environment.
- Around line 176-181: The deployment status call to
github.rest.repos.createDeploymentStatus omits a link back to the workflow run;
add the log_url field to that call so the Deployments UI links to the run that
produced the status. Update the createDeploymentStatus call (the same block that
sets environment_url) to include log_url and set it to the Actions run URL (for
example by constructing it from GITHUB_SERVER_URL + '/' + GITHUB_REPOSITORY +
'/actions/runs/' + GITHUB_RUN_ID or the equivalent context/run variables
available in this workflow).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: e67a0d2d-e005-4c8e-a108-b839e84ed784
📒 Files selected for processing (1)
.github/workflows/deploy.yml
VariableVince
changed the title
github-project-automation
bot
moved this from Development
to Final Review
in OpenFront Release Management
github-project-automation
bot
moved this from Final Review
to Complete
in OpenFront Release Management
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
2 participants
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.
Description:
Node 20 will reach EOL in April 2026. Node.js 20 actions are deprecated and will be forced to run on Node.js 24 starting June 2, 2026: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
Update our workflows in this PR.
For deployment-action and deployment-status: stop using these. They seem quite unmaintained which could pose risks and there is no Node 24 version yet: Update to use Node 24 chrnorm/deployment-action#93 and Update to use Node 24 chrnorm/deployment-status#53. It will probably be updated to Node 24, but why wait if we don't actually need to be dependent on them per se.
Instead of the above, use actions/github-script@v8 with default API. Maybe a bit more maintainance work, if any, but better than to be dependent on unmaintained outside actions. For reference see https://docs.github.com/en/rest/deployments/deployments?apiVersion=2026-03-10#create-a-deployment
For auto-author-assign, use v3.0.1 (4d585cc37690897bd9015942ed6e766aa7cdb97f). From v3.0.0 it uses Node 24: https://github.com/toshimaru/auto-author-assign/releases
For stale, use v10.2.0 (b5d41d4e1d5dceea10e7104786b73624c18a190f). From v10.0.0 it uses Node 24: https://github.com/actions/stale/releases
For other actions, use their appropriate version for Node 24.
Tested all with FORCE_JAVASCRIPT_ACTIONS_TO_NODE24=true
Please complete the following:
Please put your Discord username so you can be contacted if a bug or regression is found:
tryout33