ci(deploy-neep): tee log on remote, fetch tail via second SSH#3952
Conversation
The Truncate step was failing with "Argument list too long" because we passed the full remote stdout (multi-MB build log) through an env var into a runner shell, exceeding ARG_MAX. The previous capture_stdout + exec 2>&1 combination also duplicated every line in the captured output, making the size problem worse. Instead of piping the entire log through the runner: - Drop capture_stdout on the deploy step; we no longer need it. - Tee remote output to /tmp/canary-deploy.log on the VPS so the build log is preserved on disk regardless of action behavior. - Replace the Truncate step with a small second SSH that runs `tail -c 50000` against that file (with capture_stdout: true) only when the deploy fails. The captured output is bounded to 50KB, well under ARG_MAX and the GitHub comment limit. - Failure comment reads from steps.fetch_log.outputs.stdout.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThe deploy workflow now writes remote deploy stdout/stderr into /tmp/canary-deploy.log via tee; on failure a follow-up SSH step tails the last 50KB of that file and the PR failure comment embeds that tail. Several remote progress/error messages were updated. ChangesDeployment Log Capture and Failure Reporting
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
Mirror the rest of the workflow's English-only convention; the remote build script was the last place still echoing PT-BR progress and error markers.
|
2 participants
Description
Follow-up to #3951. The deploy ran successfully on the remote in #3940 (comment), but the workflow itself failed at the
Truncate remote output for commentstep:Two issues showed up in the captured log:
E2BIG) — we passed${{ steps.remote.outputs.stdout }}(multi-MB build log) as an env var to the truncate step's bash. Linux'sARG_MAXis ~2 MB and the env block counts toward it, soexecvefailed before bash even ran.=== [6/7] Deploy do binário ===printed twice, success banner printed twice). The combination ofappleboy/ssh-action'scapture_stdout: trueplus ourexec 2>&1was double-capturing each line, inflating the size.Behaviour
Actual
Expected
Type of change
What changed
capture_stdout: truefrom the deploy SSH step — we no longer rely on the action capturing the full log./tmp/canary-deploy.logon the VPS (exec > >(tee /tmp/canary-deploy.log) 2>&1) so the log lives on disk regardless of how the action captures.Truncate remote output for commentrunner step with a small second SSH stepFetch remote deploy log tailthat runstail -c 50000 /tmp/canary-deploy.logwithcapture_stdout: true. The captured output is bounded to ~50 KB — comfortably under bothARG_MAXand GitHub's ~65 K comment-body limit.steps.remote.outcome != 'success'), so successful deploys don't pay for an extra SSH session.${{ steps.fetch_log.outputs.stdout }}.How Has This Been Tested
/deployon a passing branch — verify the workflow now exits clean (no truncate-step crash) and the success comment is unchanged./deployon a deliberately broken branch — verify the failure comment contains the tail of the build log and is no longer duplicated.Test Configuration:
Checklist
Summary by CodeRabbit