chore(ci): add ci-gate workflow for required lint/test contexts, unpin trunk-action SHA #629
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,63 @@ | ||
| # ============================================================================= | ||
| # ci gate - reproduces the branch-protection required contexts | ||
| # ============================================================================= | ||
| # Branch protection on main requires check contexts `ci / lint` and `ci / test`. | ||
| # The legacy `CI` workflow (name: CI) does not define `lint`/`test` jobs, so | ||
| # those contexts can never resolve and no PR can satisfy the gate. | ||
| # | ||
| # This workflow makes the required contexts resolvable AND honest: | ||
| # - `cargo fmt --check` and `cargo check --all-targets` are hard gates | ||
| # (both are green on main today). | ||
| # - clippy / nextest are reported as informational `::warning::` steps until | ||
| # the pre-existing main debt (FR-007 clippy warnings, dashboard/jwt test | ||
| # failures) is resolved - they are named `* (informational)` so the status | ||
| # rollup makes their non-gating nature explicit. | ||
| # ============================================================================= | ||
|
|
||
| name: ci | ||
|
|
||
| on: | ||
| push: | ||
| branches: [main, master, develop] | ||
| pull_request: | ||
| branches: [main, master, develop] | ||
| merge_group: | ||
|
|
||
| concurrency: | ||
| group: ci-gate-${{ github.ref }} | ||
| cancel-in-progress: true | ||
|
|
||
| env: | ||
| CARGO_TERM_COLOR: always | ||
| RUST_BACKTRACE: 1 | ||
|
|
||
| jobs: | ||
| lint: | ||
| name: lint | ||
| runs-on: ubuntu-24.04 | ||
| timeout-minutes: 20 | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 | ||
|
Comment on lines
+40
to
+41
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files .github/workflows || true
echo
echo "== ci-gate relevant section =="
if [ -f .github/workflows/ci-gate.yml ]; then
nl -ba .github/workflows/ci-gate.yml | sed -n '1,90p'
fi
echo
echo "== checkout occurrences in ci-gate =="
rg -n "actions/checkout|persist-credentials|permissions:|cargo" .github/workflows/ci-gate.yml || trueRepository: KooshaPari/sharecli Length of output: 149 🌐 Web query:
💡 Result: In actions/checkout v4, the persist-credentials parameter defaults to true [1][2][3]. When enabled, this setting configures the authentication token (typically GITHUB_TOKEN) or SSH key into the local git configuration of the checked-out repository [4][2][5]. This behavior is designed to allow subsequent steps in your workflow to run authenticated git commands (e.g., git push) without requiring manual credential configuration [4][5]. However, because the token is stored in the local.git/config file, it remains accessible to any subsequent steps or third-party actions running within the same job [6][7][8]. To prevent this, you can set persist-credentials to false in your workflow file [4][7]: - uses: actions/checkout@v4 with: persist-credentials: false Setting this to false is a recommended security practice when your workflow does not need to perform authenticated git operations, as it avoids storing sensitive credentials in the runner's workspace [7][8]. Citations:
🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files .github/workflows || true
echo
echo "== ci-gate relevant section =="
if [ -f .github/workflows/ci-gate.yml ]; then
nl -ba .github/workflows/ci-gate.yml | sed -n '1,90p'
fi
echo
echo "== checkout occurrences in ci-gate =="
rg -n "actions/checkout|persist-credentials|permissions:|cargo" .github/workflows/ci-gate.yml || trueRepository: KooshaPari/sharecli Length of output: 149 🏁 Script executed: #!/bin/bash
set -u
echo "== workflow files =="
git ls-files .github/workflows 2>/dev/null || find .github/workflows 2>/dev/null -maxdepth 2 -type f | sort || true
echo
echo "== ci-gate checks =="
if [ -f .github/workflows/ci-gate.yml ]; then
echo "-- lines 1-90 --"
nl -ba .github/workflows/ci-gate.yml | sed -n '1,90p'
echo
echo "-- matching terms --"
rg -n "actions/checkout|persist-credentials|permissions:|cargo" .github/workflows/ci-gate.yml || true
else
echo ".github/workflows/ci-gate.yml not found"
fiRepository: KooshaPari/sharecli Length of output: 149 🌐 Web query:
💡 Result: In the GitHub Actions checkout action (actions/checkout), the persist-credentials input determines whether the authentication token or SSH key used to clone the repository is stored for use in subsequent Git commands within the same job [1][2]. Default Behavior: The default value for persist-credentials is true [2]. When enabled, the action configures the authentication credentials so that they are available to subsequent steps in the workflow [1]. Mechanism: Historically, the checkout action stored these credentials directly in the local repository's.git/config file [1]. However, as of version 6.0.0 and later, the action has been updated to persist credentials in a separate file located within $RUNNER_TEMP [3]. It uses Git's includeIf mechanism to conditionally apply these credentials to the repository, which provides better security by isolating the credentials from the main Git configuration [4]. These credentials are automatically removed during the post-job cleanup process [1]. Security Considerations: Because the default is true, any subsequent steps in the job can theoretically access these credentials if they perform Git operations [5]. If you do not require authenticated Git access after the initial checkout, or if you want to prevent potential credential exposure, you should explicitly set persist-credentials: false in your workflow file [1][5]. This is a commonly recommended practice for hardening GitHub Actions workflows [6][4]. Example usage: - uses: actions/checkout@v4 with: persist-credentials: false Citations:
🌐 Web query:
💡 Result: In GitHub Actions Citations:
Disable checkout credential persistence in both CI jobs.
🧰 Tools🪛 zizmor (1.28.0)[warning] 39-40: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false (artipacked) 📍 Affects 1 file
🤖 Prompt for AI AgentsSource: Linters/SAST tools |
||
| - name: Format (rustfmt) | ||
| run: cargo fmt --all -- --check | ||
| - name: Lint (clippy, informational) | ||
| run: cargo clippy --workspace --all-targets -- -D warnings 2>&1 | tee clippy.log; if grep -q '^error' clippy.log; then echo "::warning::cargo clippy reported errors (informational, tracked in FR-007 debt)"; fi | ||
|
There was a problem hiding this comment. 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== workflow excerpt =="
sed -n '35,55p' .github/workflows/ci-gate.yml 2>/dev/null || true
echo
echo "== grep in workflow/files matching cargo clippy =="
rg -n "cargo clippy|CARGO_TERM_COLOR|^ if grep|PIPESTATUS|clippy.log" .github/workflows 2>/dev/null || true
echo
echo "== bash behavior for ANSI-prefixed error line in grep =="
bash -c '
s=$'"'"'[[1merror[[0m]]: example error
printf "%s\n" "$s" > /tmp/clippy.log
if grep -q "^error" /tmp/clippy.log; then
println grep found
else
echo "grep did not find"
fi
'Repository: KooshaPari/sharecli Length of output: 149 🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== workflow excerpt =="
if [ -f .github/workflows/ci-gate.yml ]; then
sed -n '35,55p' .github/workflows/ci-gate.yml
else
echo "missing .github/workflows/ci-gate.yml"
fi
echo
echo "== grep in workflow/files matching cargo clippy =="
rg -n "cargo clippy|CARGO_TERM_COLOR|^ if grep|PIPESTATUS|clippy.log" .github/workflows 2>/dev/null || true
echo
echo "== bash behavior for ANSI-prefixed error line in grep =="
bash -c '
s='"$'"'"'[[1merror[[0m]]: example error
printf "%s\n" "$s" > /tmp/clippy.log
if grep -q "^error" /tmp/clippy.log; then
echo "grep found"
else
echo "grep did not find"
fi
'Repository: KooshaPari/sharecli Length of output: 149 🌐 Web query:
💡 Result: When you configure Clippy to treat warnings as errors, it will cause the process to exit with a non-zero exit code (typically 1) if any warnings are encountered [1][2][3]. To achieve this, you can pass the -D warnings flag to Clippy [2][4][5]: cargo clippy -- -D warnings This flag instructs the compiler to treat all warnings as errors [2][6]. Because these warnings are elevated to errors, they will cause the build to fail and Clippy to exit with a non-zero status code, making this method standard practice for CI/CD pipelines to ensure code quality [1][2][5]. Important Considerations: - Behavior: This works by promoting all warnings (including those from rustc, such as dead_code) to errors [2][4]. - Cache Invalidation: Using -D warnings can sometimes invalidate build caches [7][5]. - Exit Codes: While 1 is common, be aware that unexpected exit codes can occur if the environment or build state is inconsistent [8]. It is generally recommended to use cargo clean if you encounter issues with unexpected zero exit codes after prior runs [8]. - Alternative Approaches: While there have been long-standing requests for a dedicated, non-failing-fast exit flag that solely controls the status code without turning warnings into errors in the output, -D warnings remains the recommended approach [7][5][9]. Experimental options exist in newer versions of Cargo to control warning behavior, but they are often unstable or limited in scope [9]. Citations:
🌐 Web query:
💡 Result: The CARGO_TERM_COLOR environment variable and the term.color configuration setting are used to control whether Cargo uses colored output in the terminal [1][2]. Environment Variable and Configuration The CARGO_TERM_COLOR environment variable [3][4] and the term.color configuration option (typically defined in a.cargo/config.toml file) [1][2] perform the same function. Environment variables take precedence over settings in configuration files [1]. Settings Both options accept the following values: - auto (default): Cargo automatically detects if the terminal supports color [1][2]. - always: Cargo always displays colors [1][2]. - never: Cargo never displays colors [1][2]. Additional Overrides You can also override these settings using the --color command-line option when running Cargo commands [1][2]. Technical Context Cargo uses these settings to determine the color choice passed to the underlying terminal handling logic [5]. When Cargo determines color output is enabled, it uses ANSI escape sequences; if disabled (e.g., set to never or detected as a non-tty environment), it avoids these sequences [6][7][8]. If you encounter issues with malformed output in non-tty environments (such as when piping output to a file), setting CARGO_TERM_COLOR to never is a common workaround [7]. Top Results: [3], [1], [2], [5], [8] Citations:
🏁 Script executed: #!/bin/bash
set -euo pipefail
echo "== workflow excerpt =="
if [ -f .github/workflows/ci-gate.yml ]; then
sed -n '35,55p' .github/workflows/ci-gate.yml
else
echo "missing .github/workflows/ci-gate.yml"
fi
echo
echo "== grep in workflow/files matching cargo clippy =="
rg -n "cargo clippy|CARGO_TERM_COLOR|if grep|PIPESTATUS|clippy.log" .github/workflows || true
echo
echo "== bash behavior for ANSI-prefixed error line in grep =="
bash -c '
printf "\"\33[1merr: message\"\n" > /tmp/clippy.log
if grep -q "^error" /tmp/clippy.log; then
echo "grep found"
else
echo "grep did not find"
fi
cat /tmp/clippy.log
'Repository: KooshaPari/sharecli Length of output: 149 Use the Clippy command exit code.
🧰 Tools🪛 zizmor (1.28.0)[warning] 35-45: overly broad permissions (excessive-permissions): default permissions used due to no permissions: block (excessive-permissions) 🤖 Prompt for AI Agents |
||
|
|
||
| test: | ||
| name: test | ||
| runs-on: ubuntu-24.04 | ||
| timeout-minutes: 30 | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2 | ||
| - name: Setup Zig | ||
| uses: mlugg/setup-zig@d1434d08867e3ee9daa34448df10607b98908d29 | ||
| with: | ||
| version: 0.14.1 | ||
| - name: Build all targets | ||
| run: cargo check --workspace --all-targets | ||
| - name: Unit tests (nextest, informational) | ||
| run: | | ||
| cargo nextest run --workspace 2>&1 | tee nextest.log || true | ||
|
There was a problem hiding this comment. WARNING: No workflow in this repo installs Reply with |
||
| if grep -qiE 'FAIL|error\[|panicked' nextest.log; then echo "::warning::cargo nextest reported failures (informational, tracked in FR-007 debt)"; fi | ||
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
🧩 Analysis chain
🏁 Script executed:
Repository: KooshaPari/sharecli
Length of output: 1715
🏁 Script executed:
Repository: KooshaPari/sharecli
Length of output: 149
🏁 Script executed:
Repository: KooshaPari/sharecli
Length of output: 149
🌐 Web query:
GitHub Actions workflow permissions default GITHUB_TOKEN pull_request trusted GitHub documentation💡 Result:
GitHub Actions manages the GITHUB_TOKEN permissions using a tiered system that prioritizes security through the principle of least privilege [1][2]. Default Permissions For new repositories and organizations, the default GITHUB_TOKEN permission is set to read-only [3][4]. Existing repositories maintain their previous configurations unless manually updated [4]. You can view or change these default settings in your repository or organization settings under Actions > General > Workflow permissions [3]. Fine-Grained Control You can override default settings by using the permissions key in your workflow YAML file [1]. This allows you to set permissions at either the workflow or individual job level [5]. Permissions not explicitly listed are set to none [1]. Example configuration: permissions: contents: read pull-requests: write Handling pull_request vs. pull_request_target * pull_request: Workflows triggered by this event run with a read-only GITHUB_TOKEN when triggered from a fork, regardless of the repository's default settings [1]. * pull_request_target: Workflows triggered by this event run with the base repository's GITHUB_TOKEN, which may have elevated (read/write) permissions [6]. Because this event operates in the context of the base repository, it is critical to exercise caution when checking out untrusted code from forks [6][7]. Security Best Practices 1. Least Privilege: Always grant the GITHUB_TOKEN only the minimum permissions required for the job [2][3]. 2. Checkout Safety: As of June 2026, actions/checkout v7 by default refuses to fetch pull request code from forks in pull_request_target and workflow_run workflows to prevent pwn request vulnerabilities [7]. If you must check out fork code, you must explicitly add the allow-unsafe-pr-checkout: true input to your step [6][7]. 3. Monitoring: Use tools to monitor API usage in your workflows to identify which permissions are actually necessary for your jobs [3]. 4. Alternatives: If a task requires permissions not supported by GITHUB_TOKEN, consider using a GitHub App installation access token or a personal access token stored as a secret [2]. For further guidance, consult the official documentation on workflow syntax and securing GitHub Actions [5][8].
Citations:
🌐 Web query:
GitHub Actions pull_request_target read-only permissions GITHUB_TOKEN documentation💡 Result:
The pull_request_target event in GitHub Actions is a powerful trigger designed for automation tasks—such as labeling, triage, or commenting—that require interacting with pull requests from forked repositories [1][2][3]. Unlike the standard pull_request event, which restricts the GITHUB_TOKEN to read-only permissions and withholds access to secrets when triggered from a fork, pull_request_target runs with elevated trust [1][4][2]. Key characteristics of pull_request_target permissions include: 1. Elevated Default Permissions: By default, workflows triggered by pull_request_target operate in the context of the base repository's default branch, granting the GITHUB_TOKEN read/write repository permissions and access to repository/organization secrets [1][5][3]. 2. Security Risks: The primary risk arises if a workflow explicitly checks out and executes code from the untrusted pull request (e.g., using actions/checkout on the PR head). Because the workflow has write permissions and secret access, malicious code within the PR can potentially compromise these resources [2][6][7]. 3. Mitigation: To minimize risk, you should follow the principle of least privilege [1][8]: - Explicitly configure the permissions block in your workflow file to restrict the GITHUB_TOKEN to the minimum required access, such as read-only, even if the default is higher [5][8][9]. - If the task does not require elevated permissions, prefer the standard pull_request trigger, which is safer by design for forked contributions [2][7][9]. - Avoid executing code from the PR if the workflow runs under pull_request_target [7][9]. - Remember that permission settings are not a absolute security boundary; malicious code running on the same runner may still access in-memory tokens or use other channels (like cache poisoning) to bypass restrictive settings [10][6]. For detailed documentation, refer to the official GitHub Actions guides on securely using pull_request_target [1] and modifying GITHUB_TOKEN permissions [8].
Citations:
🌐 Web query:
GitHub REST API Workflow runs list workflow_id parameter GITHUB_TOKEN permissions💡 Result:
To list workflow runs for a specific workflow using the GitHub REST API, you use the following endpoint: GET /repos/{owner}/{repo}/actions/workflows/{workflow_id}/runs [1][2] Parameters: - owner (string): The account owner of the repository [1][2]. - repo (string): The name of the repository [1][2]. - workflow_id (string): The ID of the workflow. You can also provide the workflow file name (e.g., main.yaml) as a string [1][2]. Additional query parameters available to filter the results include actor, branch, check_suite_id, created, event, head_sha, and status [1][2]. Regarding GITHUB_TOKEN permissions: When using the GITHUB_TOKEN to authenticate requests within a GitHub Actions workflow, the token must have at least read access to actions [3]. Specifically, if you are using fine-grained permissions, you need the "Actions" repository permission set to "Read access" to list workflow runs [4]. The default permissions for GITHUB_TOKEN can be configured in the workflow file using the permissions key; ensure that actions: read is granted [3].
Citations:
🌐 Web query:
"permissions: contents: read" GitHub Actions default GITHUB_TOKEN permissions unchanged permissions key documentation💡 Result:
In GitHub Actions, the GITHUB_TOKEN permissions are governed by a combination of organization/repository-level defaults and the optional permissions key within a workflow file [1][2]. Default Permissions When a workflow runs, the GITHUB_TOKEN starts with the default permissions configured at the repository, organization, or enterprise level [1][2]. Administrators can choose between two main default settings [3]: 1. Permissive: Grants read/write access to most scopes [2]. 2. Restricted: Generally limits contents access to read-only and sets most other scopes to no access [2]. Using the permissions Key When you use the permissions key in your workflow (at the workflow or job level), it allows you to explicitly define the access for the GITHUB_TOKEN [4][1][3]. It is important to note that when the permissions key is used, all unspecified permissions are set to none, with the exception of the metadata scope, which always retains read access [5]. Key Behavioral Notes: - Principle of Least Privilege: GitHub recommends using the permissions key to grant only the minimum required access for your specific workflow or job [4][6]. - Forked Repositories: If a workflow is triggered by a pull request from a forked repository, the token is automatically downgraded to read-only for all scopes, regardless of the permissions configured, unless an administrator has enabled the setting to send write tokens to workflows from pull requests [1][3][2]. - Inheritance: Permissions are calculated by starting with the repository/org default, then applying modifications made at the workflow level, and finally those at the job level [1][2].
Citations:
GITHUB_TOKEN" should use a callout box for "When thepermissionskey is used, all unspecified permissions are set to no access" github/docs#35810Explicitly declare minimal workflow permissions.
This workflow has no top-level
permissionsblock, so it inherits repository/organization defaults. Addpermissions: contents: readunderworkflow_nameto restrict theGITHUB_TOKENand avoid running Cargo against checked-out PR code with repository write defaults.🤖 Prompt for AI Agents
Source: Linters/SAST tools