ci: run the queue-storage prune suite against AlloyDB Omni#446
Conversation
awa reclaims ring slots with ACCESS EXCLUSIVE + TRUNCATE, whose relfilenode churn is far costlier on AlloyDB's storage engine than on stock Postgres. A regression there (an idle ring re-truncating empty slots every maintenance tick) saturated AlloyDB IO in production. Add a CI job that runs the prune suite on AlloyDB Omni 18.3 so the idle-skip behaviour is guarded on the engine where it bit, not only on vanilla Postgres.
hardbyte
added
the
full-ci
📝 WalkthroughWalkthroughAdds a gated ChangesAlloyDB Omni CI coverage
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 Checkov (3.3.8).github/workflows/ci.ymlTraceback (most recent call last): 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 |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eef35c8cd4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| timeout-minutes: 30 | ||
| services: | ||
| alloydb: | ||
| image: gcr.io/alloydb-omni/alloydbomni:18.3 |
There was a problem hiding this comment.
This service image is pulled anonymously by GitHub before any job steps run, but AlloyDB Omni's PostgreSQL 18 images are access-gated (Google's Docker Hub page says PG18 access requires registration: https://hub.docker.com/r/google/alloydbomni, and the 18.3 install docs say to use the image URI provided after requesting access). Since this workflow has no service-container credentials or prior registry login, main/full-ci runs will fail while starting the service instead of running the prune suite; use a public tag or add authenticated registry credentials for the provided image URI.
Useful? React with 👍 / 👎.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/ci.yml (1)
160-160: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winPin the AlloyDB Omni image to an immutable release.
Line [160] uses the floating
18.3tag. Pin the verified18.3.0image digest so future registry changes cannot silently alter what this CI job validates. Google’s container documentation uses the complete18.3.0version. (docs.cloud.google.com)Suggested change
- image: gcr.io/alloydb-omni/alloydbomni:18.3 + image: gcr.io/alloydb-omni/alloydbomni@sha256:<verified-18.3.0-digest>🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/ci.yml at line 160, Update the AlloyDB Omni image reference in the workflow service configuration from the floating 18.3 tag to the verified immutable 18.3.0 image digest, preserving the existing image and CI job setup.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/ci.yml:
- Line 172: Update the actions/checkout@v6 step to set persist-credentials to
false, ensuring checkout credentials are not retained for subsequent workflow
steps.
---
Nitpick comments:
In @.github/workflows/ci.yml:
- Line 160: Update the AlloyDB Omni image reference in the workflow service
configuration from the floating 18.3 tag to the verified immutable 18.3.0 image
digest, preserving the existing image and CI job setup.
🪄 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: 5bf1f94d-e234-4a3c-938d-9c6ebf37fa2d
📒 Files selected for processing (1)
.github/workflows/ci.yml
| --health-timeout 5s | ||
| --health-retries 40 | ||
| steps: | ||
| - uses: actions/checkout@v6 |
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 "== ci.yml around checkout area =="
if [ -f .github/workflows/ci.yml ]; then
nl -ba .github/workflows/ci.yml | sed -n '130,210p'
fi
echo "== occurrences of checkout in workflows =="
rg -n "actions/checkout|persist-credentials|cargo test|cargo|push|url|fetch" .github/workflows || trueRepository: hardbyte/awa
Length of output: 142
🌐 Web query:
actions/checkout persist-credentials default true README
💡 Result:
In the actions/checkout GitHub Action, the persist-credentials input parameter defaults to true [1][2]. This setting configures the local git configuration with the authentication token or SSH key used for the checkout [3][2]. When enabled, this allows subsequent steps in the workflow job to execute authenticated git commands (e.g., git push) automatically [3][4]. The token is removed by the action during post-job cleanup [3][5]. Security context and updates: - While the default remains true, security improvements have been implemented. In v6.0.0 and later, the action was updated to store these credentials in a separate file located in $RUNNER_TEMP rather than writing them directly into the.git/config file, which enhances security [6][7]. - Users concerned about this behavior can opt out by explicitly setting persist-credentials: false in their workflow configuration [3][2]. - There has been community discussion regarding whether the default should be false due to security concerns, but the default value has remained true across major versions [8][9].
Citations:
- 1: https://github.com/actions/checkout/blob/cbb722410c2e876e24abbe8de2cc27693e501dcb/action.yml
- 2: https://github.com/actions/checkout/?tab=readme-ov-file
- 3: https://github.com/actions/checkout
- 4: https://github.com/actions/checkout/tree/v6.0.2?tab=readme-ov-file
- 5: https://github.com/actions/checkout/blob/85e6279cec87321a52edac9c87bce653a07cf6c2/README.md
- 6: https://github.com/actions/checkout/tree/v6.0.0
- 7: actions/checkout@v5.0.1...v6.0.0
- 8: [security] Escalate concerning default
persist-credentials=trueplease actions/checkout#2312 - 9: Remove
persist-credentialsor change the default tofalseactions/checkout#485
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files .github/workflows
echo "== ci.yml around checkout area =="
if [ -f .github/workflows/ci.yml ]; then
nl -ba .github/workflows/ci.yml | sed -n '130,215p'
fi
echo "== occurrences of checkout and related commands in workflows =="
rg -n "actions/checkout|persist-credentials|cargo test|cargo|git push|git fetch|git fetch-pack|git clone|url|fetch" .github/workflows || trueRepository: hardbyte/awa
Length of output: 142
🌐 Web query:
actions/checkout v6 persist-credentials default true action.yml
💡 Result:
In actions/checkout v6, the persist-credentials input defaults to true [1][2][3]. This input controls whether the authentication token (or SSH key) used for the checkout is configured in the local git configuration [1][3]. When set to true (the default), this enables subsequent scripts and commands in the workflow to run authenticated git operations (such as git fetch or git push) [1][2]. The credentials are removed during post-job cleanup [1][4]. Starting with v6, the implementation was updated to improve credential security by storing these credentials in a separate file under $RUNNER_TEMP instead of directly in.git/config, though this does not change the default behavior or the requirement for users to explicitly set persist-credentials: false if they wish to opt out [1][2][5].
Citations:
- 1: https://github.com/actions/checkout/?tab=readme-ov-file
- 2: https://github.com/actions/checkout/tree/v6.0.2?tab=readme-ov-file
- 3: https://github.com/actions/checkout/blob/main/action.yml
- 4: https://github.com/actions/checkout
- 5: https://github.com/actions/checkout/tree/v6.0.0
🌐 Web query:
github actions checkout persist-credentials false security
💡 Result:
The persist-credentials input in the actions/checkout GitHub Action controls whether the action configures the local Git environment with the repository's access token or SSH key [1][2]. By default, this value is set to true [1][3]. When enabled, the action stores credentials so that subsequent scripts in the workflow can execute authenticated Git commands (such as git push or git fetch) without needing additional configuration [1][2]. Security Considerations: 1. Risk of Exposure: Historically, enabling persist-credentials caused the authentication token to be written directly into the local.git/config file [1][4]. This created risks, as the token could potentially be leaked if the repository contents were archived, uploaded as artifacts, or accessed by other third-party actions/steps running in the same job [5][6][4]. 2. Improved Security Mechanisms: In more recent versions of actions/checkout, the implementation has been updated to store credentials in a separate, more secure location under $RUNNER_TEMP rather than directly in.git/config [1][2]. This mitigates some risks related to accidental leakage, such as via artifact uploads [7][2]. 3. Recommended Practice: For workflows that do not require the action to push or perform authenticated Git operations, it is considered a security best practice to set persist-credentials: false [6][4]. This follows the principle of least privilege by ensuring that credentials are not unnecessarily available to other steps or processes in the runner [6]. Usage Example: To disable the persistence of credentials, use the following configuration in your workflow file [6][4]: - uses: actions/checkout@v4 with: persist-credentials: false If you use this setting, any subsequent step that requires authentication (e.g., git push) will fail unless you provide alternative authentication methods [1][2].
Citations:
- 1: https://github.com/actions/checkout
- 2: https://github.com/actions/checkout/tree/v6.0.2?tab=readme-ov-file
- 3: https://github.com/marketplace/actions/checkout?version=v3.6.0
- 4: https://yossarian.net/til/post/actions-checkout-can-leak-github-credentials/
- 5: Remove
persist-credentialsor change the default tofalseactions/checkout#485 - 6: https://actsense.dev/vulnerabilities/unsafe_checkout/
- 7: [security] Escalate concerning default
persist-credentials=trueplease actions/checkout#2312
Disable checkout credential persistence.
Line 172 uses actions/checkout@v6 without persist-credentials; that input defaults to true, leaving credentials available to later steps in the workflow. Since this checkout does not need authenticated Git operations afterwards, set it to false.
Suggested change
- uses: actions/checkout@v6
+ with:
+ persist-credentials: false📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v6 | |
| - uses: actions/checkout@v6 | |
| with: | |
| persist-credentials: false |
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 172-172: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/ci.yml at line 172, Update the actions/checkout@v6 step to
set persist-credentials to false, ensuring checkout credentials are not retained
for subsequent workflow steps.
Source: Linters/SAST tools
1 participant
Adds a
rust-test-alloydb-omniCI job that runs the queue-storage prune suite (includingtest_maintenance_idle_prune_replaces_child_filenode_once) against AlloyDB Omni 18.3, so the idle-prune behaviour is guarded on a disaggregated-storage engine and not only on vanilla Postgres.Context: awa reclaims ring slots via
ACCESS EXCLUSIVE+TRUNCATE, whose relfilenode churn is ~2–6× costlier on AlloyDB's storage engine than on stock PG (single-container Omni reproduces the engine cost; managed adds regional-storage round-trips on top). A regression where an idle ring re-truncated empty slots every maintenance tick saturated AlloyDB IO in production. This forward-ports the Omni CI coverage that shipped with the v0.6.4 hotfix so future versions keep it.Omni runs as a plain Postgres service (no columnar preload needed — the tests assert logical prune behaviour, not columnar performance). Gated behind the
full-cilabel like the other heavy Rust test jobs.Summary by CodeRabbit