Action: jfrog/fly-action/distribute@v1 (also affects @v1.7.1), type: docker
Runner: ubuntu-24.04, runner 2.335.1
Summary
The distribute action writes its results blob into $GITHUB_ENV as FLY_DISTRIBUTE_RESULTS. Because that value includes a files array with per-file download_count, it grows over time. Once it exceeds the Linux single-env-var limit (MAX_ARG_STRLEN = 131072 bytes), the kernel rejects execve for any process that inherits the environment. Every step and post-cleanup step after distribute then fails to start bash/node with:
An error occurred trying to start process '/usr/bin/bash' with working directory '...'. Argument list too long
The same error also hits Post Run actions/checkout and Post <your-action> (node) cleanup steps, so the whole job fails even though the distribute itself succeeded.
Evidence
Measured in CI immediately after the distribute step:
FLY_DISTRIBUTE_RESULTS = 133,965 bytes
- Total of all other env vars ≈ 10 KB
FLY_ACCESS_TOKEN = 754 bytes
So it is specifically this one oversized variable, not overall environment size. The single-string limit (MAX_ARG_STRLEN, 128 KB) is exceeded by FLY_DISTRIBUTE_RESULTS alone. The workflow passed for months and only began failing once the accumulated blob crossed ~128 KB.
Impact
Any job that runs a step (or relies on action post-steps) after distribute fails to spawn any process — bash, node, etc. The distribute succeeds, but the deploy/notify steps and post-cleanup all break.
Expected
results is already exposed as a step output and a job-summary table, which is the right place for it. It should not also be written to $GITHUB_ENV. Please remove the FLY_DISTRIBUTE_RESULTS GITHUB_ENV export, or cap its size / drop the files array from the env copy.
Workaround (for other users hitting this)
Add a step immediately after distribute that blanks the variable. A step-level env: override lets that step's own shell start despite the oversized inherited value, and writing an empty value to $GITHUB_ENV clears it for all subsequent steps and the post-cleanup steps:
- name: Clear oversized FLY_DISTRIBUTE_RESULTS
env:
FLY_DISTRIBUTE_RESULTS: ""
run: echo "FLY_DISTRIBUTE_RESULTS=" >> "$GITHUB_ENV"
Action:
jfrog/fly-action/distribute@v1(also affects@v1.7.1),type: dockerRunner:
ubuntu-24.04, runner 2.335.1Summary
The
distributeaction writes its results blob into$GITHUB_ENVasFLY_DISTRIBUTE_RESULTS. Because that value includes afilesarray with per-filedownload_count, it grows over time. Once it exceeds the Linux single-env-var limit (MAX_ARG_STRLEN= 131072 bytes), the kernel rejectsexecvefor any process that inherits the environment. Every step and post-cleanup step afterdistributethen fails to startbash/nodewith:The same error also hits
Post Run actions/checkoutandPost <your-action>(node) cleanup steps, so the whole job fails even though the distribute itself succeeded.Evidence
Measured in CI immediately after the distribute step:
FLY_DISTRIBUTE_RESULTS= 133,965 bytesFLY_ACCESS_TOKEN= 754 bytesSo it is specifically this one oversized variable, not overall environment size. The single-string limit (
MAX_ARG_STRLEN, 128 KB) is exceeded byFLY_DISTRIBUTE_RESULTSalone. The workflow passed for months and only began failing once the accumulated blob crossed ~128 KB.Impact
Any job that runs a step (or relies on action post-steps) after
distributefails to spawn any process —bash,node, etc. The distribute succeeds, but the deploy/notify steps and post-cleanup all break.Expected
resultsis already exposed as a step output and a job-summary table, which is the right place for it. It should not also be written to$GITHUB_ENV. Please remove theFLY_DISTRIBUTE_RESULTSGITHUB_ENVexport, or cap its size / drop thefilesarray from the env copy.Workaround (for other users hitting this)
Add a step immediately after
distributethat blanks the variable. A step-levelenv:override lets that step's own shell start despite the oversized inherited value, and writing an empty value to$GITHUB_ENVclears it for all subsequent steps and the post-cleanup steps: