forked from mainsail-crew/MainsailOS
-
-
Notifications
You must be signed in to change notification settings - Fork 160
Chore node24 build migration #231
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
Open
LongLiveCHIEF
wants to merge
1
commit into
Rat-OS:v2.1.x
Choose a base branch
from
LongLiveCHIEF:chore-node24-build-migration
base: v2.1.x
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,6 @@ | ||
| allowBuilds: | ||
| '@swc/core': true | ||
| '@tsparticles/engine': true | ||
| core-js: true | ||
| core-js-pure: true | ||
| sharp: true |
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.
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.
🧩 Analysis chain
🏁 Script executed:
Repository: Rat-OS/RatOS
Length of output: 165
🏁 Script executed:
Repository: Rat-OS/RatOS
Length of output: 5408
🏁 Script executed:
Repository: Rat-OS/RatOS
Length of output: 3982
🌐 Web query:
actions/checkout persist-credentials default value💡 Result:
The actions/checkout input persist-credentials has the default value true (i.e., it persists the token/credentials by default). This is stated by GitHub’s checkout documentation as “Default: true” for persist-credentials, and the docs also describe that it can be opted out by setting persist-credentials: false.[1][2] Brief context: when persist-credentials is enabled, the auth token is persisted in the local git config so later steps can run authenticated git commands; the token is removed during post-job cleanup, and you can disable persistence with persist-credentials: false.[1][2]
Citations:
🌐 Web query:
pnpm/action-setup package_json_file default reads repository root package.json packageManager input💡 Result:
Default behavior: pnpm/action-setup’s package_json_file input defaults to reading package.json from the repository root (path “package.json”). [1] The action documents that package_json_file is optional with default value
package.json. That means if you don’t set package_json_file, it will look forpackageManagerin the root-level package.json and (when you omit the version input) use the pnpm version from that packageManager field. [1] If your repo doesn’t have a root package.json or you want to point at a different one (e.g., a monorepo subfolder), you must set package_json_file accordingly. [1] (Implementation detail) The action also treats package_json_file as a path input and normalizes/expands it before using it to read the packageManager configuration. [2]Citations:
🌐 Web query:
pnpm/action-setup inputs version package_json_file packageManager inference behavior💡 Result:
pnpm/action-setup: inputs + version/packageManager inference behavior 1) with: version - Meaning: “Version of pnpm to install.” [1] - Optionality/inference: - It is optional when your repo’s package.json contains a packageManager field. [1] - Otherwise it is required. [1] - “Version” parsing/inference: the input supports npm-style versioning formats such as exact versions (e.g. 6.24.1), version ranges (e.g. 6, 6.x.x, 6.24.x), caret ranges (e.g. ^6.24.1), wildcards (*), and also latest. [1] 2) with: package_json_file - Meaning: Optional file path (default package.json) to read “packageManager” configuration from. [1] - Inference behavior tie-in: - When you omit with.version, the action will read the packageManager field from the file specified by package_json_file (defaulting to package.json) to determine which pnpm version to install. [1] 3) packageManager field (conceptually, in your package.json) - This is not an action input; it’s a field in the project’s package.json that pnpm/action-setup reads (from package_json_file) to infer the pnpm version when with.version is omitted. [1] Overall decision logic - If packageManager exists in the specified package_json_file: you may omit with.version and pnpm/action-setup installs the pnpm version from that field. [1] - If packageManager does not exist: with.version becomes required. [1] (Implementation note: the action’s input processing expands package_json_file and retrieves version via its input processing layer.) [2]
Citations:
Pin deploy-docs workflow action refs to SHAs and harden checkout/pnpm version sourcing
In
.github/workflows/deploy-docs.yml(lines 14-17),actions/checkout@v6,pnpm/action-setup@v6, andactions/setup-node@v4use floating tags—pin them to full commit SHAs.actions/checkoutalso lackswith: persist-credentials: false, so it keeps credentials (default istrue).Additionally,
pnpm/action-setup@v6has nowith.versionand nowith.package_json_file, so it defaults to readingpackage.jsonfrom the repo root; this repo has no rootpackage.json, so it won’t reliably usesite/package.json’spackageManagerpin.🔒 Suggested hardening
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 14-15: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 15-15: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 16-16: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
[error] 17-17: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents