Update/dockerfile rbe debian #2453
No reviewers
Labels
No labels
1week
2weeks
Failed compliance check
IP cameras
NATS
Possible security concern
Review effort 1/5
Review effort 2/5
Review effort 3/5
Review effort 4/5
Review effort 5/5
UI
aardvark
accessibility
amd64
api
arm64
auth
back-end
bgp
blog
bug
build
checkers
ci-cd
cleanup
cnpg
codex
core
dependencies
device-management
documentation
duplicate
dusk
ebpf
enhancement
eta 1d
eta 1hr
eta 3d
eta 3hr
feature
fieldsurvey
github_actions
go
good first issue
help wanted
invalid
javascript
k8s
log-collector
mapper
mtr
needs-triage
netflow
network-sweep
observability
oracle
otel
plug-in
proton
python
question
reddit
redhat
research
rperf
rperf-checker
rust
sdk
security
serviceradar-agent
serviceradar-agent-gateway
serviceradar-web
serviceradar-web-ng
siem
snmp
sysmon
topology
ubiquiti
wasm
wontfix
zen-engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
carverauto/serviceradar!2453
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "refs/pull/2453/head"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Imported from GitHub pull request.
Original GitHub pull request: #1985
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/1985
Original created: 2025-11-23T16:24:30Z
Original updated: 2025-11-23T16:26:05Z
Original head: carverauto/serviceradar:update/dockerfile_rbe_debian
Original base: main
Original merged: 2025-11-23T16:24:37Z by @mfreeman451
User description
IMPORTANT: Please sign the Developer Certificate of Origin
Thank you for your contribution to ServiceRadar. Please note, when contributing, the developer must include
a DCO sign-off statement indicating the DCO acceptance in one commit message. Here
is an example DCO Signed-off-by line in a commit message:
Describe your changes
Issue ticket number and link
Code checklist before requesting a review
PR Type
Enhancement
Description
Migrate RBE executor image from Oracle Linux 9 to Ubuntu 24.04
Update container image version to v1.0.15 across configurations
Switch release workflow to use remote Bazel configuration
Preserve Oracle Linux 9 Dockerfile as alternative option
Diagram Walkthrough
File Walkthrough
Dockerfile.rbe
Migrate RBE Dockerfile to Ubuntu 24.04docker/Dockerfile.rbe
oraclelinux:9toubuntu:24.04sources
BUILD.bazel
Update RBE platform container image versionBUILD.bazel
v1.0.14tov1.0.15MODULE.bazel
Update BuildBuddy toolchain image versionMODULE.bazel
v1.0.14tov1.0.15buildbuddy.yaml
Update BuildBuddy execution config image versionbuildbuddy.yaml
v1.0.14tov1.0.15release.yml
Enable remote Bazel execution in release workflow.github/workflows/release.yml
--config=no_remoteto--config=remote--@rules_pkg//toolchains/rpm:is_rpmbuild_available=1Dockerfile.rbe-ora9
Add Oracle Linux 9 RBE Dockerfile variantdocker/Dockerfile.rbe-ora9
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1985#issuecomment-3568126259
Original created: 2025-11-23T16:25:07Z
PR Compliance Guide 🔍
Below is a summary of compliance checks for this PR:
Secret handling in build
Description: The build uses a secret mount 'ghcr_token' in a Dockerfile RUN step, which risks leaking
credentials via layer caching or command output if not carefully controlled in CI; ensure
BuildKit is enforced, layers are not pushed to public registries, and commands avoid
echoing secrets.
Dockerfile.rbe [91-96]
Referred Code
Remote execution trust
Description: Switching Bazel to '--config=remote' for release publishing increases supply-chain risk if
remote execution credentials or workers are compromised; publishing artifacts during
release should avoid untrusted remote executors or enforce strict CAS integrity and
authenticated, isolated RBE.
release.yml [266-273]
Referred Code
Unpinned package installs
Description: Installing numerous development tools (podman, skopeo, rpm, compilers) in the RBE image
broadens the attack surface and, without pinning APT package versions or enabling
'apt-get' verification beyond GPG keys, can lead to non-reproducible or vulnerable builds.
Dockerfile.rbe [14-67]
Referred Code
Host network exposure
Description: Enabling host networking for RBE jobs via 'dockerNetwork: "host"' can expose the host
network from the executor to builds, allowing potential lateral movement or data
exfiltration if build steps are compromised.
buildbuddy.yaml [20-25]
Referred Code
🎫 No ticket provided
Codebase context is not defined
Follow the guide to enable codebase context checks.
Generic: Meaningful Naming and Self-Documenting Code
Objective: Ensure all identifiers clearly express their purpose and intent, making code
self-documenting
Status: Passed
Generic: Secure Error Handling
Objective: To prevent the leakage of sensitive system information through error messages while
providing sufficient detail for internal debugging.
Status: Passed
Generic: Secure Logging Practices
Objective: To ensure logs are useful for debugging and auditing without exposing sensitive
information like PII, PHI, or cardholder data.
Status: Passed
Generic: Comprehensive Audit Trails
Objective: To create a detailed and reliable record of critical system actions for security analysis
and compliance.
Status:
No audit logs: The changes introduce remote execution configuration but add no logging of critical
actions within the workflow or tooling, making it unclear if critical actions are
auditable.
Referred Code
Generic: Robust Error Handling and Edge Case Management
Objective: Ensure comprehensive error handling that provides meaningful context and graceful
degradation
Status:
Pull fallback: The skopeo image preload step lacks explicit error handling beyond set -euo and may skip
preload silently if GHCR_CNPG_IMAGE is unset, which could impact builds without a clear
fallback strategy.
Referred Code
Generic: Security-First Input Validation and Data Handling
Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent
vulnerabilities
Status:
Remote exec risks: Switching to --config=remote introduces dependency on remote execution without showing
validation or safeguards for external inputs and credentials in this diff.
Referred Code
Compliance status legend
🟢 - Fully Compliant🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label
Imported GitHub PR comment.
Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1985#issuecomment-3568127076
Original created: 2025-11-23T16:26:05Z
PR Code Suggestions ✨
Explore these optional code suggestions:
Safely prepend to path environment variable
Safely prepend to the
PKG_CONFIG_PATHenvironment variable by conditionallyadding the separator, preventing a trailing colon that could lead to
non-hermetic builds.
docker/Dockerfile.rbe [82]
Suggestion importance[1-10]: 7
__
Why: The suggestion correctly identifies a potential non-hermetic build issue with
PKG_CONFIG_PATHand provides a robust fix using standard shell parameter expansion.Remove the archived Oracle Linux Dockerfile
The suggestion recommends removing the newly added
docker/Dockerfile.rbe-ora9.This file archives the old Oracle Linux configuration but is not integrated into
any build or test process, creating a maintenance burden.
Examples:
docker/Dockerfile.rbe-ora9 [1-123]
Solution Walkthrough:
Before:
After:
Suggestion importance[1-10]: 6
__
Why: The suggestion correctly identifies that the archived
Dockerfile.rbe-ora9lacks any usage or testing mechanism, creating future maintenance overhead without a clear benefit.Split package installation for better caching
Split the single large
RUNinstruction for package installation into multipleRUNlayers to improve Docker layer caching, readability, and maintainability.docker/Dockerfile.rbe [14-67]
[To ensure code accuracy, apply this suggestion manually]Suggestion importance[1-10]: 6
__
Why: The suggestion correctly proposes splitting the
RUNcommand to improve Docker layer caching and readability, which is a valid and beneficial best practice.