Environment
- rattler-build 0.72.2
- GitHub Actions, conda-forge feedstock (conda-smithy generated workflow)
RATTLER_BUILD_ENABLE_GITHUB_INTEGRATION=true, $GITHUB_STEP_SUMMARY
bind-mounted into the build container
What happens
On a package with a large file count (zig), the job ends with:
##[error]$GITHUB_STEP_SUMMARY upload aborted, supports content up to a size
of 1024k, got 1410k.
GitHub does not truncate on overflow — it drops the whole summary. The build
itself succeeds, so the net effect is that the summary is silently unavailable
on exactly the large, slow builds where it is most useful.
Measurements
From conda-forge/zig-feedstock PR #144, lane
linux_64_cross_target_platform_linux-64. The zig compiler package bundles libc
headers for every target triple it can cross-compile to.
The build log contains the packaged file listing twice:
| region |
lines |
% of log |
colorized live "packaging tree" (├─) |
21,021 |
42.9% |
final tar manifest (?rw-r--r--) |
20,993 |
42.8% |
| combined |
42,014 |
85.7% |
Within each listing, lib/zig/libc/* alone accounts for 17,502 lines —
35,004 across both, or 71.4% of the entire 49,016-line log.
Evidence that the summary tracks rattler-build's output, not build-script stdout
We reduced build-script output substantially in a follow-up commit (silencing an
xtrace-heavy loop, and narrowing an over-broad test-file glob):
|
before |
after |
change |
| log lines |
63,629 |
49,016 |
−23.0% |
| log bytes |
8,014,692 |
6,025,641 |
−24.8% |
| step summary |
1611k |
1410k |
−12.5% |
The summary shrank at roughly half the rate of the log, which suggests it is
dominated by rattler-build's own packaging report rather than by script output.
Caveat: we cannot inspect the summary directly to confirm this — GitHub
discards it on overflow, so its exact composition is inferred from the
correlation above rather than observed. Happy to instrument a run if that would
help.
Environment
RATTLER_BUILD_ENABLE_GITHUB_INTEGRATION=true,$GITHUB_STEP_SUMMARYbind-mounted into the build container
What happens
On a package with a large file count (zig), the job ends with:
##[error]$GITHUB_STEP_SUMMARY upload aborted, supports content up to a size
of 1024k, got 1410k.
GitHub does not truncate on overflow — it drops the whole summary. The build
itself succeeds, so the net effect is that the summary is silently unavailable
on exactly the large, slow builds where it is most useful.
Measurements
From
conda-forge/zig-feedstockPR #144, lanelinux_64_cross_target_platform_linux-64. The zig compiler package bundles libcheaders for every target triple it can cross-compile to.
The build log contains the packaged file listing twice:
├─)?rw-r--r--)Within each listing,
lib/zig/libc/*alone accounts for 17,502 lines —35,004 across both, or 71.4% of the entire 49,016-line log.
Evidence that the summary tracks rattler-build's output, not build-script stdout
We reduced build-script output substantially in a follow-up commit (silencing an
xtrace-heavy loop, and narrowing an over-broad test-file glob):
The summary shrank at roughly half the rate of the log, which suggests it is
dominated by rattler-build's own packaging report rather than by script output.
Caveat: we cannot inspect the summary directly to confirm this — GitHub
discards it on overflow, so its exact composition is inferred from the
correlation above rather than observed. Happy to instrument a run if that would
help.