Repository navigation
ci: log builder environment for image build diagnostics - #148
zekraken-bot wants to merge 2 commits into
Conversation
Add a small build-info step to the op builder stage so CI-only image build failures can be reproduced from the job log. No runtime image changes.
|
No actionable comments were generated in the recent review.
|
| Layer / File(s) | Summary |
|---|---|
Print build environment reth/Dockerfile |
The build stage prints builder and host details, then prints sorted environment variables while excluding names matching sensitive-name patterns. The command allows the filtered list to be empty. |
Priority:
Estimated code review effort: 2 (Simple) | ~10 minutes
Change: Feature
Possibly related PRs
- LiskHQ/lisk-node#147: Adds a temporary ARM64 probe to the
opDocker build that prints environment data.
Suggested reviewers: nazgolze
Merge Risk: 
Minimal · up to f45e7
-
This adds diagnostic logging to the image build and does not change what is published. No concrete risk was found in the supplied build and CI configuration, so it is low risk to merge.
Pre-merge checks: 
5
-
Full details: Description check
-
Explanation
The description uses all required headings and clearly explains the problem, implementation, and testing. It omits the issue reference required by the template, but the description is otherwise complete.
Full details: Docstring Coverage
-
Explanation
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (1 skipped: 1 unsupported.)
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
A rabbit checks the build-time sky
Prints kernel, routes, and disks nearby
Secret names are filtered away
Sorted clues appear for the day
Then off the build goes, hop and try
Comment @coderabbitai help to get the list of available commands.
Record kernel/CPU/DMI/network details next to the existing uid/host/env line so CI-only image build failures can be reproduced from the job log. No runtime image changes.
What was the problem?
ARM64 image builds are difficult to triage from the CI log alone: the log does not record which builder produced the image, so architecture-, toolchain- or runner-specific failures cannot be reproduced reliably.
How was it solved?
Added a small
build-infostep at the start of theopbuilder stage that prints the kernel, user, hostname and the build environment (excluding variables with sensitive-looking names). This only affects build logs; the published image content is unchanged.How was it tested?
The Dockerfile parses correctly and CI will exercise both the
linux/amd64andlinux/arm64image builds.Summary by CodeRabbit