chore: R-16 toolchain pin + reconciliation #85
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -9,10 +9,11 @@ on: | |
| permissions: | ||
| actions: read | ||
| contents: read | ||
| security-events: write | ||
| id-token: write | ||
| jobs: | ||
| scorecard: | ||
| uses: hyperpolymath/standards/.github/workflows/scorecard-reusable.yml@5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236 | ||
|
There was a problem hiding this comment. 🩺 Stability & Availability | 🟠 Major | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -eu
printf '%s\n' '--- workflow excerpt ---'
sed -n '1,35p' .github/workflows/scorecard.yml
printf '%s\n' '--- pinned commit lookup ---'
if command -v gh >/dev/null 2>&1; then
gh api repos/hyperpolymath/standards/commits/5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236 \
--jq '{sha: .sha, message: .commit.message}'
else
curl -sS -D /tmp/headers \
-H 'Accept: application/vnd.github+json' \
'https://api.github.com/repos/hyperpolymath/standards/commits/5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236' \
-o /tmp/commit.json
sed -n '1,12p' /tmp/headers
cat /tmp/commit.json
fi
printf '%s\n' '--- reusable workflow reference ---'
curl -sS -L \
'https://raw.githubusercontent.com/hyperpolymath/standards/5b1d00229e5e8c0c0fbfedc7e80f37ea50f49236/.github/workflows/scorecard-reusable.yml' \
-o /tmp/reusable.yml
wc -c /tmp/reusable.yml
sed -n '1,12p' /tmp/reusable.ymlRepository: hyperpolymath/universal-language-server-plugin Length of output: 925 🌐 Web query:
💡 Result: To use a GitHub Actions reusable workflow from a different repository, you reference the workflow file using the following syntax in your caller workflow job [1][2][3]: {owner}/{repo}/.github/workflows/{filename}@{ref} In this syntax: - {owner}/{repo} is the organization or repository where the reusable workflow is located [1][4]. -.github/workflows/{filename} is the path to the workflow file within that repository [1]. - @{ref} specifies the version of the workflow to use [1]. The {ref} can be a commit SHA, a release tag, or a branch name [1][5]. Using a full commit SHA is the recommended approach for stability and security, as it ensures that the workflow execution remains consistent and is not subject to changes if the branch or tag is updated [1][6]. If you use a tag or branch, be aware that those references can be moved, which might result in the execution of different workflow code than expected [6]. Example configuration: jobs: call-reusable-workflow: uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9t0 When you reference a reusable workflow in the same repository, you do not use the {owner}/{repo} or @{ref} syntax; instead, you use./.github/workflows/{filename} or $/.github/workflows/{filename} (the latter is not supported on GitHub Enterprise Server) [1][2]. In these cases, the called workflow uses the same commit as the caller workflow [1][3]. Citations:
Pin the reusable workflow to an existing commit. The pinned SHA does not exist in 🤖 Prompt for AI Agents |
||
| permissions: | ||
| contents: read | ||
| security-events: write | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,2 @@ | ||
| [tools] | ||
| rust = "stable" | ||
|
There was a problem hiding this comment. 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🔎 Supported by static analysis🏁 Script executed: #!/bin/bash
set -euo pipefail
rg -n '(^rust\s*=|RUST_VERSION|image:\s*rust:)' .mise.toml .gitlab-ci.yml
fd -H -a '^(mise\.lock|\.tool-versions)$' .Repository: hyperpolymath/universal-language-server-plugin Length of output: 1116 🏁 Script executed: #!/bin/bash
set -euo pipefail
printf '%s\n' '--- .mise.toml ---'
cat -n .mise.toml
printf '%s\n' '--- CI version and toolchain setup ---'
sed -n '1,40p' .gitlab-ci.yml
printf '%s\n' '--- repository toolchain files ---'
find . -maxdepth 3 -type f \( -name 'mise.lock' -o -name '.tool-versions' -o -name 'rust-toolchain' -o -name 'rust-toolchain.toml' \) -printRepository: hyperpolymath/universal-language-server-plugin Length of output: 1190 🌐 Web query:
💡 Result: In mise, you can manage Rust versions by specifying them in your Citations:
Pin the Rust toolchain to
🤖 Prompt for AI Agents |
||
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.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🔎 Supported by static analysis
🏁 Script executed:
sed -n '1,80p' .github/workflows/scorecard.ymlRepository: hyperpolymath/universal-language-server-plugin
Length of output: 616
🌐 Web query:
GitHub Actions workflow-level permissions job-level permissions reusable workflow call permissions precedence💡 Result:
In GitHub Actions, GITHUB_TOKEN permissions are determined through a specific hierarchy of precedence. When a workflow executes, permissions are calculated sequentially: first at the organization or repository level (defaults), then refined at the workflow level, and finally overridden at the job level [1][2]. Key Precedence Rules: 1. Job-Level Overrides: If a permissions block is defined within a job, it completely replaces any permissions set at the workflow level for that specific job [1][3]. Job-level permissions do not merge with or append to workflow-level permissions; they represent the entire set of permissions for that job [3][4]. 2. Defaulting: If no permissions are specified at the job level, the job inherits the permissions defined at the workflow level [1][5]. If no workflow-level permissions are defined, the job inherits the repository's default permissions [5][2]. 3. Exclusivity: Specifying a permissions block sets any omitted scopes to none [4][6]. For example, if you define only contents: write, all other permissions (e.g., packages, issues) are explicitly set to none [4][6]. 4. Reusable Workflows: When calling a reusable workflow, the caller's job-level permissions (or workflow-level if the job-level is absent) constrain the called workflow [7][8]. The permissions passed to a called workflow can only be maintained or downgraded—they cannot be elevated [7][8]. If the calling job does not specify a permissions block, the called workflow will receive the repository's default permissions [7][8]. To adhere to the principle of least privilege, it is recommended to define a minimal set of permissions at the workflow level (such as contents: read) and explicitly escalate permissions only for the specific jobs that require additional access [3][4][5].
Citations:
Keep write permissions at job scope.
jobs.scorecard.permissionsoverrides the workflow-level permissions for the current job. Jobs without their own permissions block inheritsecurity-events: writeandid-token: write. Remove these workflow-level entries and retain them underjobs.scorecard.🧰 Tools
🪛 zizmor (1.29.0)
[warning] 12-12: overly broad permissions (excessive-permissions): security-events: write is overly broad at the workflow level
(excessive-permissions)
[error] 13-13: overly broad permissions (excessive-permissions): id-token: write is overly broad at the workflow level
(excessive-permissions)
🤖 Prompt for AI Agents
Source: Linters/SAST tools