Make partial pipeline pass#2426
Conversation
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThis change updates various CI/CD pipeline configurations and documentation to switch Docker Node.js and Debian images from "buster-slim" to "bullseye-slim" variants. It also removes manual triggers from certain pipeline jobs and adds an entry to the changelog documenting a fix for pipeline status reporting. No changes to exported or public entities or active application logic are present. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
Status, Documentation and Community
|
f0e1e21 to
a9e86fb
Compare
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (5)
gigadb/app/tools/files-metadata-console/gitlab-config-live-build.yml (1)
22-22: Consistency gap: PHP layers remain on Buster while Node switched to Bullseye
Mixed Debian bases inside the same compose build can inflate image size and occasionally cause glibc / SSL incompatibilities. If there’s no technical blocker, aligning the remainingphp-$PHP_VERSION-*-buster.tarlayers to Bullseye will keep the stack homogeneous.gigadb/app/tools/files-metadata-console/gitlab-config-ci-test.yml (1)
14-14: Align base images or accept the mix
The test job now pulls Bullseye for Node while PHP images stay on Buster. Consider upgrading the PHP layers too, or document why the mix is deliberate to avoid confusion for future maintainers.ops/pipelines/gigadb-conformance-security-jobs.yml (1)
18-18: Reduce duplication & ensure artefact availability for Node Bullseye imageBoth
check_PSR2andcheck_PHPDocrepeat the same long list ofdocker loadcommands.
Consider extracting them into a YAML anchor / alias or a shell script to keep the pipeline DRY and easier to maintain.Also double-check that
node-$NODE_VERSION-bullseye-slim.taris downloaded by declaringneeds: ["base_images"](same concern as in the staging build job).Also applies to: 46-46
fuw/docker-pure-ftpd/gitlab-config-staging-build.yml (1)
21-21: Commented-out Node load line can be removedThe line is still updated to Bullseye but remains commented.
If the staging FTPD build never requires the Node image, delete the dead line to avoid future confusion; if it is required, uncomment and ensure the tar is supplied.CHANGELOG.md (1)
7-7: Grammar & capitalization correctionMinor wording issues: use plural “have” with “jobs,” and capitalize “GitLab” to match project style.
- - Fix #2424: Ensure Gitlab pipeline is marked as "Passed" when no jobs has failed + - Fix #2424: Ensure GitLab pipeline is marked as "Passed" when no jobs have failed
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
CHANGELOG.md(1 hunks)fuw/docker-pure-ftpd/gitlab-config-live-build.yml(1 hunks)fuw/docker-pure-ftpd/gitlab-config-staging-build.yml(1 hunks)gigadb/app/tools/files-metadata-console/gitlab-config-ci-build.yml(1 hunks)gigadb/app/tools/files-metadata-console/gitlab-config-ci-test.yml(1 hunks)gigadb/app/tools/files-metadata-console/gitlab-config-live-build.yml(1 hunks)gigadb/app/tools/files-metadata-console/gitlab-config-staging-build.yml(1 hunks)ops/pipelines/gigadb-build-jobs.yml(5 hunks)ops/pipelines/gigadb-conformance-security-jobs.yml(2 hunks)ops/pipelines/gigadb-deploy-jobs.yml(1 hunks)ops/pipelines/gitlab-tideways-jobs.yml(0 hunks)ops/scripts/setup_devdb.sh(1 hunks)
💤 Files with no reviewable changes (1)
- ops/pipelines/gitlab-tideways-jobs.yml
🧰 Additional context used
📓 Path-based instructions (2)
**/*
⚙️ CodeRabbit Configuration File
**/*: - Focus on code smells, logic errors, edge cases, missing test cases, security flaws and serious issues
- Avoid commenting on minor issues such as linting, formatting and style issues
- Never commit secrets, PII, passwords or API keys—use env-vars and .env files.
- Flag any file >300 lines or function >30 lines and suggest refactoring.
- Every new feature or bug-fix must arrive with automated tests; warn if none are touched.
- If the PR includes changes to the UI, the style guide should be updated too; warn if not.
Files:
ops/pipelines/gigadb-deploy-jobs.ymlCHANGELOG.mdops/pipelines/gigadb-conformance-security-jobs.ymlgigadb/app/tools/files-metadata-console/gitlab-config-live-build.ymlgigadb/app/tools/files-metadata-console/gitlab-config-staging-build.ymlgigadb/app/tools/files-metadata-console/gitlab-config-ci-build.ymlgigadb/app/tools/files-metadata-console/gitlab-config-ci-test.ymlops/scripts/setup_devdb.shfuw/docker-pure-ftpd/gitlab-config-staging-build.ymlfuw/docker-pure-ftpd/gitlab-config-live-build.ymlops/pipelines/gigadb-build-jobs.yml
**/*.{sh,bash}
⚙️ CodeRabbit Configuration File
**/*.{sh,bash}: - Useset -euo pipefailfor shell scripts.
- Quote all variables.
Files:
ops/scripts/setup_devdb.sh
🧠 Learnings (2)
📚 Learning: in the gigadb project, textual changes to website content should be categorized as "feat" (feature) ...
Learnt from: rija
PR: gigascience/gigadb-website#2157
File: CHANGELOG.md:7-7
Timestamp: 2025-05-26T17:52:49.544Z
Learning: In the GigaDB project, textual changes to website content should be categorized as "Feat" (feature) entries in the CHANGELOG.md, not as "Docs" (documentation) entries, even when the changes involve updating guidance or instructional text on web pages.
Applied to files:
CHANGELOG.md
📚 Learning: the pr "fix 561 separate admin user page from non admin user page" focuses specifically on separatin...
Learnt from: alli83
PR: gigascience/gigadb-website#2301
File: protected/views/user/_form.php:179-187
Timestamp: 2025-05-23T02:02:48.284Z
Learning: The PR "Fix 561 separate admin user page from non admin user page" focuses specifically on separating admin user pages from non-admin user pages, removing terms and captcha requirements on update and change password pages, and adding token generation for activation links. Issues outside this scope should be addressed in separate PRs.
Applied to files:
CHANGELOG.md
🔇 Additional comments (5)
fuw/docker-pure-ftpd/gitlab-config-live-build.yml (1)
23-23: Verify that the new tarball is produced by upstream caching/publish jobs
Thenode-$NODE_VERSION-bullseye-slim.tarlayer is now referenced (although still commented-out). If your image-save stage has not yet been updated to emit this exact filename, a future uncomment may break the job.No action needed if this line remains purely documentary, but double-check that every job that saves the Node image now uses the Bullseye tag so the artifact exists when you decide to enable the load step.
ops/scripts/setup_devdb.sh (1)
28-28: Comment still mentions Bullseye tarball – safe to ignore
The edited line is only an example (# comment). Nothing to flag functionally.gigadb/app/tools/files-metadata-console/gitlab-config-ci-build.yml (1)
16-16: Ensure the Bullseye Node tarball is present in CI cache
Same note as in the live build: confirm that the layernode-$NODE_VERSION-bullseye-slim.taris produced and uploaded during the cache-seed stage, otherwise thisdocker loadwill 404 and the build will fail.gigadb/app/tools/files-metadata-console/gitlab-config-staging-build.yml (1)
20-20: Verify thatnode-$NODE_VERSION-bullseye-slim.taris actually present in this job’s workspaceThe job does not declare a
needs:ordependencies:relationship to thebase_imagesjob that produces the tarball, sodocker load -i …will fail unless the runner’s cache happens to still contain the file.
Addneeds: ["base_images"](or fetch the image directly from the registry) to guarantee repeatable builds.ops/pipelines/gigadb-deploy-jobs.yml (1)
18-18: Potential missing artifact – Node Bullseye tar
docker load -i node-$NODE_VERSION-bullseye-slim.tarassumes the tar is available on the deploy runner.
Confirm that this job either:
- declares
needs: ["base_images"], or- pulls the image directly (and skips the tar).
Otherwise the deploy step will error out before any containers are touched.
| - docker pull node:$NODE_VERSION-bullseye-slim | ||
| - docker save -o node-$NODE_VERSION-bullseye-slim.tar node:$NODE_VERSION-bullseye-slim | ||
| - docker pull debian:buster | ||
| - docker save -o debian-buster.tar debian:buster | ||
| - docker pull debian:buster-slim | ||
| - docker save -o debian-buster-slim.tar debian:buster-slim | ||
| - docker pull debian:bullseye-slim | ||
| - docker save -o debian-bullseye-slim.tar debian:bullseye-slim | ||
| - docker pull debian:bullseye |
There was a problem hiding this comment.
💡 Verification agent
❓ Verification inconclusive
Large monolithic job – consider modularising base-image handling
Good call switching to Bullseye for Node and adding debian:bullseye-slim, but the base_images job is now 25+ docker commands and this YAML file has grown well past 300 lines.
Extract repetitive pull/save logic into a script (checked into ops/scripts) or use YAML anchors to keep the CI config maintainable and faster to review.
Additionally, verify no lingering references to node-$NODE_VERSION-buster-slim remain elsewhere:
🏁 Script executed:
#!/bin/bash
# Find any leftover buster-slim references
rg --no-heading 'node-\$NODE_VERSION-buster-slim' -nLength of output: 54
Modularise repetitive base-image pulls
- ops/pipelines/gigadb-build-jobs.yml (base_images job, around lines 18–24) contains 25+ near-identical
docker pull/docker savesteps. Extract that logic into a script underops/scripts/(e.g.pull-base-images.sh) or leverage YAML anchors to reduce duplication and improve maintainability. - Ran
rg --no-heading 'buster-slim' -nand confirmed there are no remainingbuster-slimreferences.
🤖 Prompt for AI Agents
In ops/pipelines/gigadb-build-jobs.yml around lines 18 to 24, there are many
repetitive docker pull and save commands for base images. To fix this, create a
shell script under ops/scripts/ (e.g., pull-base-images.sh) that accepts image
names and performs the pull and save operations. Then replace the repeated steps
in the YAML file with a single step that calls this script for each base image.
Alternatively, use YAML anchors and aliases to define the pull/save commands
once and reuse them to reduce duplication and improve maintainability.
kencho51
left a comment
There was a problem hiding this comment.
Hi @rija,
praise: By updating all the existing buster-slim images to bullseye-slim, the pipeline will cache all these images for the subsequent stages, this helps to fix failed to build: too many requests: You have reached your pull rate limit by not pulling the bullseye-slim image in every job.
praise: There is no more block jobs when all the jobs passed in the pipeline.
note (non-blocking): The EOL date of bullseyes is 31/08/2026, the next version trixie is out and should upgrade it when there is a chance.
issue: The Production-Dockerfile still using the php:${TARGET_PHP_VERSION}-fpm-buster base image, will get The repository 'http://deb.debian.org/debian buster Release' no longer has a Release file. during the build_live
suggestion: Should update it to php:${TARGET_PHP_VERSION}-fpm-bullseye. I have fixed it in PR #2425 ff8443d, but I think the fix should be in this PR as it will be merged before it.
praise: All tests are passing in gitlab pipeline.
|
Thanks for pointing out the buster issue. I've made the change to replace it with bullseye |
pli888
left a comment
There was a problem hiding this comment.
praise: My staging site was deployed and all tests passed in my CI pipeline.
praise: Code looks good to me.
Happy to approve.
Pull request for issue: #2424
This is a pull request for the following functionalities:
buster-slimwithbullseye-slimfpm-busterwithfpm-bullseyecli-busterwithcli-bullseyeHow to test?
Run the pipeline, it should be marked as "Passed" when finished
How have functionalities been implemented?
Make all jobs related to build and deploy on staging automated.
Any issues with implementation?
n/a
Any changes to automated tests?
n/a
Any changes to documentation?
n/a
Any technical debt repayment?
n/a
Any improvements to CI/CD pipeline?
Fixed the error:
Fixed the error:
Summary by CodeRabbit
Bug Fixes
Chores