Updated to 25.8.0.
#1821
Updated to 25.8.0.
#1821
Conversation
WalkthroughThe Docker image tag for the CI runner was updated from Changes
Estimated code review effort2 (~15 minutes) Possibly related PRs
Suggested labels
Poem
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.circleci/config.yml(1 hunks).github/workflows/build-test-deploy.yml(3 hunks).github/workflows/vortex-test-common.yml(3 hunks)
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/build-test-deploy.yml (1)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/vortex-test-common.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.circleci/config.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/build-test-deploy.yml (1)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/vortex-test-common.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.circleci/config.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (5)
- GitHub Check: build (0)
- GitHub Check: build (1)
- GitHub Check: vortex-test-installer (8.4)
- GitHub Check: vortex-test-installer (8.2)
- GitHub Check: vortex-test-installer (8.3)
.circleci/config.yml
Outdated
| - image: drevops/ci-runner:canary | ||
| auth: |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
CircleCI runner switched to canary – same reproducibility concern.
For consistency with the GitHub workflows (and to align with the PR intent), pin the image:
- - image: drevops/ci-runner:canary
+ - image: drevops/ci-runner:25.78.0If you keep canary, please rename all cache keys that still start with v25.7.0- to avoid mismatched metadata.
🏁 Script executed:
#!/bin/bash
# List CircleCI config to confirm image tag and existing cache keys
echo "Files under .circleci/:"
find . -maxdepth 2 -type f | sed 's/^/>> /'
echo -e "\n.circleci/config.yml (lines 30-60):"
sed -n '30,60p' .circleci/config.yml || echo "⚠️ .circleci/config.yml not found"
echo -e "\nImage references in .circleci/config.yml:"
grep -R "image: drevops/ci-runner" -n .circleci/config.yml || echo "⚠️ No ci-runner image found"
echo -e "\nCache keys referencing v25.7.0-:"
grep -R "v25\.7\.0-" -n .circleci || echo "⚠️ No cache keys with v25.7.0- found in .circleci/"Length of output: 4367
Pin CircleCI runner image or update cache keys
The drevops/ci-runner:canary tag is non‐deterministic and undermines build reproducibility. You can either pin to a stable version or, if you must keep canary, ensure cache keys are updated to match.
• In .circleci/config.yml at line 44
- - image: drevops/ci-runner:canary
+ - image: drevops/ci-runner:25.78.0• If retaining :canary, rename all cache‐key prefixes from v25.7.0- to a matching identifier (lines 153, 156, 186, 234, 235), e.g.:
- key: v25.7.0-db11-…
+ key: v25.78.0-db11-…📝 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.
| - image: drevops/ci-runner:canary | |
| auth: | |
| - image: drevops/ci-runner:25.78.0 | |
| auth: |
🤖 Prompt for AI Agents
In .circleci/config.yml at lines 44-45, the use of the non-deterministic image
tag 'drevops/ci-runner:canary' reduces build reproducibility. To fix this,
either pin the image to a stable version tag instead of 'canary' or, if you must
keep 'canary', update all cache key prefixes in the file (lines 153, 156, 186,
234, 235) to a new consistent identifier that matches the canary usage to ensure
cache validity.
| container: | ||
| image: drevops/ci-runner:25.7.0 | ||
| image: drevops/ci-runner:canary | ||
| env: |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Pin the runner image to an explicit version instead of canary.
drevops/ci-runner:canary moves every time a new build is published, which will make your CI runs non-deterministic and can silently introduce breaking changes.
Given the PR title “Updated to 25.78.0”, it looks like you actually want that specific release. Consider pinning the image to drevops/ci-runner:25.78.0 (or even better, a digest) to guarantee reproducible builds and simpler roll-backs.
- image: drevops/ci-runner:canary
+ image: drevops/ci-runner:25.78.0Same change is required for the other two jobs in this workflow.
Also applies to: 111-113, 171-173
🏁 Script executed:
#!/bin/bash
# Search for all uses of the canary tag in GitHub workflow files
rg -n "image: drevops/ci-runner:canary" .github/workflowsLength of output: 552
Pin all ci-runner:canary references to 25.78.0 for reproducible CI
The canary tag moves on every rebuild, leading to non-deterministic CI runs and potential silent breakages. Since this PR targets version 25.78.0, please update every occurrence:
• .github/workflows/vortex-test-common.yml
– lines 23, 112, 172
• .github/workflows/build-test-deploy.yml
– lines 59, 169, 387
Replace:
- image: drevops/ci-runner:canary
+ image: drevops/ci-runner:25.78.0(Or even better, pin by digest to guarantee exact builds.)
📝 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.
| container: | |
| image: drevops/ci-runner:25.7.0 | |
| image: drevops/ci-runner:canary | |
| env: | |
| container: | |
| image: drevops/ci-runner:25.78.0 | |
| env: |
🤖 Prompt for AI Agents
In .github/workflows/vortex-test-common.yml at lines 23, 112, and 172, replace
all occurrences of the image tag "drevops/ci-runner:canary" with
"drevops/ci-runner:25.78.0" to ensure reproducible CI runs. This change pins the
image version explicitly instead of using the moving "canary" tag. Optionally,
consider pinning by digest for exact build guarantees.
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/vortex-test-common.yml (1)
22-24: Pindrevops/ci-runnerto25.78.0(or a digest) instead of usingcanary.Using the moving
canarytag makes CI non-deterministic and can silently introduce breaking changes.
The PR title already references25.78.0, so switch all three jobs to that explicit tag (or even better, the image digest) for reproducible builds and simpler roll-backs.Also applies to: 118-120, 185-187
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/vortex-test-common.yml(6 hunks)
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/vortex-test-common.yml (4)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Composer dependencies are updated automatically with compatibility checks via RenovateBot
Learnt from: AlexSkrypnyk
PR: drevops/vortex#0
File: :0-0
Timestamp: 2025-05-29T12:15:32.188Z
Learning: Do not review files in .vortex/installer/tests/Fixtures/install directory as they are test fixtures.
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/vortex-test-common.yml (4)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Composer dependencies are updated automatically with compatibility checks via RenovateBot
Learnt from: AlexSkrypnyk
PR: drevops/vortex#0
File: :0-0
Timestamp: 2025-05-29T12:15:32.188Z
Learning: Do not review files in .vortex/installer/tests/Fixtures/install directory as they are test fixtures.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: build (1)
- GitHub Check: build (0)
- GitHub Check: vortex-test-workflow (3)
- GitHub Check: vortex-test-workflow (2)
- GitHub Check: vortex-test-workflow (1)
- GitHub Check: vortex-test-workflow (0)
- GitHub Check: vortex-test-deployment (1)
- GitHub Check: vortex-test-deployment (0)
- GitHub Check: vortex-test-common
- GitHub Check: vortex-test-installer (8.2)
- GitHub Check: vortex-test-installer (8.4)
- GitHub Check: vortex-test-installer (8.3)
- GitHub Check: vortex-test-docs
| - name: Install Ahoy | ||
| run: | | ||
| version=2.4.0 && \ | ||
| set -x && curl -L -o "/usr/local/bin/ahoy" "https://github.com/ahoy-cli/ahoy/releases/download/v${version}/ahoy-bin-$(uname -s)-amd64" && \ | ||
| chmod +x /usr/local/bin/ahoy && \ | ||
| ahoy --version |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Validate Ahoy download & consolidate the install step.
- Security: the script pipes a binary straight from GitHub without checksum or signature verification. Fetch the release’s SHA256 (or use GitHub’s signed assets) and verify before
chmod +xto avoid supply-chain risks. - Portability: the URL hard-codes
amd64; GitHub’s ARM runners (e.g.,ubuntu-lateston ARM) will break. Use$(uname -m)or map architectures explicitly. - DRY: the same install block is duplicated in three jobs—extract to a reusable composite action or a reusable step (
uses:syntax) to reduce copy/paste.
Example checksum verification diff for one job:
- version=2.4.0 && \
- set -x && curl -L -o "/usr/local/bin/ahoy" "https://github.com/ahoy-cli/ahoy/releases/download/v${version}/ahoy-bin-$(uname -s)-amd64" && \
- chmod +x /usr/local/bin/ahoy && \
- ahoy --version
+ set -euo pipefail
+ version=2.4.0
+ arch=$(uname -m)
+ url="https://github.com/ahoy-cli/ahoy/releases/download/v${version}/ahoy-bin-$(uname -s)-${arch}"
+ curl -L -o /tmp/ahoy "$url"
+ curl -L -o /tmp/ahoy.sha256 "$url.sha256"
+ sha256sum -c /tmp/ahoy.sha256
+ install -m 0755 /tmp/ahoy /usr/local/bin/ahoy
+ ahoy --versionAlso applies to: 150-155, 224-229
🤖 Prompt for AI Agents
In .github/workflows/vortex-test-common.yml around lines 83 to 88, improve the
Ahoy installation step by adding SHA256 checksum verification before making the
binary executable to enhance security. Replace the hardcoded "amd64"
architecture in the download URL with a dynamic detection using $(uname -m) or
an explicit mapping for supported architectures to ensure compatibility on ARM
runners. Finally, refactor the workflow to extract this installation logic into
a reusable composite action or reusable step to avoid duplication across
multiple jobs, specifically also addressing lines 150-155 and 224-229.
AlexSkrypnyk
force-pushed
the
feature/ci-runner-25.8.0
branch
from
c56e66a to
fe68457
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #1821 +/- ##
========================================
Coverage 74.51% 74.51%
========================================
Files 84 84
Lines 4760 4760
Branches 35 35
========================================
Hits 3547 3547
Misses 1213 1213 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
AlexSkrypnyk
force-pushed
the
feature/ci-runner-25.8.0
branch
from
fe68457 to
0957d5c
Compare
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (3)
.github/workflows/vortex-test-common.yml (1)
83-88:Install Ahoystep still pipes arbitrary binary without checksum & hard-codesamd64Security & portability concerns raised in the previous review are still unaddressed.
Please add SHA-256 verification and an architecture map or use the project’s composite action.Also applies to: 150-155, 224-229
.circleci/config.yml (2)
44-45: Cache keys out of sync with runner version 25.8.0 – will cause stale/incorrect hitsThe runner image moved to 25.8.0 but cache prefixes remain
v25.7.0-.
Update all five occurrences (153-157, 186, 234-236) or derive the prefix from an env var to keep CircleCI caches honest.Also applies to: 153-157, 186-186, 234-236
494-500:Install Ahoystep: no checksum,amd64onlySame concerns as the GitHub Actions workflow – please harden this step.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
⛔ Files ignored due to path filters (2)
.vortex/installer/tests/Fixtures/version_replacement/baseline/config.ymlis excluded by!.vortex/installer/tests/Fixtures/**.vortex/installer/tests/Fixtures/version_replacement/expected/config.ymlis excluded by!.vortex/installer/tests/Fixtures/**
📒 Files selected for processing (3)
.circleci/config.yml(2 hunks).github/workflows/build-test-deploy.yml(3 hunks).github/workflows/vortex-test-common.yml(6 hunks)
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.circleci/config.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.github/workflows/build-test-deploy.yml (1)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/vortex-test-common.yml (4)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Composer dependencies are updated automatically with compatibility checks via RenovateBot
Learnt from: AlexSkrypnyk
PR: drevops/vortex#0
File: :0-0
Timestamp: 2025-05-29T12:15:32.188Z
Learning: Do not review files in .vortex/installer/tests/Fixtures/install directory as they are test fixtures.
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.circleci/config.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.github/workflows/build-test-deploy.yml (1)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/vortex-test-common.yml (4)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Composer dependencies are updated automatically with compatibility checks via RenovateBot
Learnt from: AlexSkrypnyk
PR: drevops/vortex#0
File: :0-0
Timestamp: 2025-05-29T12:15:32.188Z
Learning: Do not review files in .vortex/installer/tests/Fixtures/install directory as they are test fixtures.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: build (0)
- GitHub Check: build (1)
- GitHub Check: vortex-test-deployment (1)
- GitHub Check: vortex-test-workflow (0)
- GitHub Check: vortex-test-workflow (2)
- GitHub Check: vortex-test-deployment (0)
- GitHub Check: vortex-test-workflow (1)
- GitHub Check: vortex-test-workflow (3)
- GitHub Check: vortex-test-common
- GitHub Check: vortex-test-installer (8.4)
- GitHub Check: vortex-test-installer (8.2)
- GitHub Check: vortex-test-installer (8.3)
- GitHub Check: vortex-test-docs
| container: | ||
| image: drevops/ci-runner:25.7.0 | ||
| image: drevops/ci-runner:25.8.0 | ||
|
|
There was a problem hiding this comment.
Image bumped to 25.8.0 but cache-key prefix still hard-coded to 25.7.0 – cache poisoning risk
The runner now uses drevops/ci-runner:25.8.0, yet every DB-cache key keeps the v25.7.0- prefix.
If another branch/job is still on 25.7.0, you’ll get cross-pollination; worse, once you invalidate 25.8.0 layers you’ll keep hitting a stale 25.7.0 cache and silently skip DB refresh.
Patch one of the occurrences and grep-replace the rest (or inject a ${{ env.CI_RUNNER_VERSION }} variable):
- key: v25.7.0-db11-${{ hashFiles('db_cache_branch') }}-${{ hashFiles('db_cache_fallback') }}-${{ hashFiles('db_cache_timestamp') }}
+ key: v25.8.0-db11-${{ hashFiles('db_cache_branch') }}-${{ hashFiles('db_cache_fallback') }}-${{ hashFiles('db_cache_timestamp') }}
...
- v25.7.0-db11-${{ hashFiles('db_cache_branch') }}-${{ hashFiles('db_cache_fallback') }}-
+ v25.8.0-db11-${{ hashFiles('db_cache_branch') }}-${{ hashFiles('db_cache_fallback') }}-Same adjustment is required on lines 153, 213 and 225-227.
Also applies to: 122-127, 153-153, 212-214, 225-227
🤖 Prompt for AI Agents
In .github/workflows/build-test-deploy.yml around lines 58 to 60 and also at
lines 122-127, 153, 212-214, and 225-227, the cache-key prefix is hard-coded to
version 25.7.0 while the container image is updated to 25.8.0, causing a cache
poisoning risk. To fix this, replace the hard-coded version prefix in all
cache-key definitions with a dynamic reference using an environment variable
like ${{ env.CI_RUNNER_VERSION }} that matches the image version. This ensures
cache keys align with the actual runner version and prevents stale cache usage
across versions.
🧹 Nitpick (assertive)
Optional: pin by SHA-digest for fully reproducible CI
Even a semver tag can be force-pushed on Docker Hub. Consider replacing
drevops/ci-runner:25.8.0 with its immutable digest (e.g. @sha256:…) to make roll-backs & diff-bisection deterministic.
🤖 Prompt for AI Agents
In .github/workflows/build-test-deploy.yml around lines 58 to 60, the Docker
image is currently referenced by a mutable semver tag drevops/ci-runner:25.8.0.
To ensure fully reproducible CI builds and enable deterministic roll-backs,
replace the image tag with its immutable SHA digest form (e.g.,
drevops/ci-runner@sha256:...). Obtain the correct SHA digest from the Docker
registry and update the image reference accordingly.
| image: drevops/ci-runner:25.8.0 | ||
| env: |
There was a problem hiding this comment.
🧹 Nitpick (assertive)
Nice upgrade – consider pinning by digest
All jobs now use the 25.8.0 runner – LGTM.
Same digest-pin recommendation as in the other workflow applies.
Also applies to: 118-120, 185-187
🤖 Prompt for AI Agents
In .github/workflows/vortex-test-common.yml around lines 23-24, 118-120, and
185-187, the Docker image is specified using a tag (25.8.0) which can lead to
inconsistencies if the tag is updated. To fix this, replace the image tag with
the exact image digest to pin the version precisely. Retrieve the digest for
drevops/ci-runner:25.8.0 from the Docker registry and update the image field to
use the digest format (e.g., drevops/ci-runner@sha256:...). This ensures
consistent and reproducible builds.
0957d5c to
6dd92d4
Compare
AlexSkrypnyk
force-pushed
the
feature/ci-runner-25.8.0
branch
from
6dd92d4 to
a986d57
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (8)
.github/workflows/build-test-deploy.yml (3)
168-170: Same cache-key mismatch as above – please update or parameterise.
383-385: Same cache-key mismatch as above – please update or parameterise.
58-60: Cache keys still stuck on 25.7.0 → stale / cross-polluted caches
Runner image is now25.8.0, yet every cache key (Restore DB cache,Save DB cache, etc.) still prefixesv25.7.0-…. The first restore on a fresh 25.8.0 build will hit an incompatible 25.7.0 layer and silently skip DB refresh.Patch all keys (122-127, 153, 214-229) or, better, derive the prefix from a single env var:
- key: v25.7.0-db11-${{ hashFiles('db_cache_branch') }}-... + key: v${{ env.CI_RUNNER_VERSION }}-db11-${{ hashFiles('db_cache_branch') }}-...Add
CI_RUNNER_VERSION: 25.8.0toenv:block next toTZto keep things in sync.
Failing to align these will produce hard-to-trace CI flakiness..github/workflows/vortex-test-common.yml (4)
83-88: Ahoy install step: no checksum, hard-coded amd64, copy/paste
This repeats previous feedback:
- Supply-chain risk – download is executed blindfolded.
- Fails on ARM runners – URL is fixed to
amd64.- Duplicated in three jobs – extract to a composite action.
See earlier suggested snippet for SHA-256 verification +
$(uname -m)handling.
23-24: Consider pinning by digest for reproducible CI
Same recommendation issued earlier – tag is mutable, digest is immutable.
118-120: Image-digest pinning – duplicate of the comment above.
185-187: Image-digest pinning – duplicate of the comment above..circleci/config.yml (1)
494-500: Ahoy install step: same security/portability duplication
No checksum verification,amd64only, duplicated logic – see prior comment in GHA workflow.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
.circleci/config.yml(2 hunks).github/workflows/build-test-deploy.yml(3 hunks).github/workflows/vortex-test-common.yml(6 hunks)
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/build-test-deploy.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.circleci/config.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.github/workflows/vortex-test-common.yml (4)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Composer dependencies are updated automatically with compatibility checks via RenovateBot
Learnt from: AlexSkrypnyk
PR: drevops/vortex#0
File: :0-0
Timestamp: 2025-05-29T12:15:32.188Z
Learning: Do not review files in .vortex/installer/tests/Fixtures/install directory as they are test fixtures.
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
.github/workflows/build-test-deploy.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.circleci/config.yml (2)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
.github/workflows/vortex-test-common.yml (4)
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Docker images are updated for containers via RenovateBot
Learnt from: AlexSkrypnyk
PR: #1816
File: .docker/cli.dockerfile:72-76
Timestamp: 2025-07-23T01:16:30.963Z
Learning: In the Vortex project, unauthenticated Composer installs should be allowed, so GitHub token secrets should not be marked as required=true in Docker build mounts. The conditional check if [ -s /run/secrets/github_token ] is the preferred approach to allow builds to proceed without a token when needed.
Learnt from: CR
PR: drevops/vortex#0
File: CLAUDE.md:0-0
Timestamp: 2025-07-18T15:00:28.327Z
Learning: Composer dependencies are updated automatically with compatibility checks via RenovateBot
Learnt from: AlexSkrypnyk
PR: drevops/vortex#0
File: :0-0
Timestamp: 2025-05-29T12:15:32.188Z
Learning: Do not review files in .vortex/installer/tests/Fixtures/install directory as they are test fixtures.
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (9)
- GitHub Check: build (0)
- GitHub Check: build (1)
- GitHub Check: vortex-test-workflow (0)
- GitHub Check: vortex-test-common
- GitHub Check: vortex-test-deployment (0)
- GitHub Check: vortex-test-workflow (1)
- GitHub Check: vortex-test-workflow (3)
- GitHub Check: vortex-test-deployment (1)
- GitHub Check: vortex-test-workflow (2)
| - image: drevops/ci-runner:25.8.0 | ||
| auth: |
There was a problem hiding this comment.
Cache prefix/version drift (25.8.0 vs 25.7.0) will poison CircleCI caches
Runner bumped to 25.8.0, but all cache keys (153, 156, 186, 234, 235) still read v25.7.0-….
Quick-fix (example for one section):
- - v25.7.0-db11-{{ checksum "/tmp/db_cache_branch" }}-{{ checksum "/tmp/db_cache_fallback" }}-{{ checksum "/tmp/db_cache_timestamp" }}
+ - v25.8.0-db11-{{ checksum "/tmp/db_cache_branch" }}-{{ checksum "/tmp/db_cache_fallback" }}-{{ checksum "/tmp/db_cache_timestamp" }}Prefer injecting a single CI_RUNNER_VERSION parameter and interpolating it to avoid this recurring drift.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In .circleci/config.yml around lines 44 to 45, the Docker image version is
updated to 25.8.0 but the cache keys still reference version 25.7.0, causing
cache poisoning. Fix this by defining a single CI_RUNNER_VERSION parameter with
the value 25.8.0 and update all cache keys to interpolate this variable instead
of hardcoding the version. This ensures consistency and prevents version drift
in cache keys.
Summary by CodeRabbit