Open Shweta4398 opened 5 months ago
We just started getting this as well. https://github.com/cloudposse/atmos/actions/runs/9664474935
@juxtin Can you help here ??
any update on this? thanks
This is affecting us too, even after updating to v4.3.3+
It's causing confusion within our team because it appears as a job failure. So until this is fixed we don't think we can use this GH action
Hi folks, Jon from GitHub here. Thanks for filing this issue originally @Shweta4398 and others for commenting on it.
What's happening here is that the action summary buffer is exceeding its maximum size and we are not truncating it gracefully, which then triggers the error that you're getting in the logs from actions/core
. Our team is starting to take a look into the problem.
A root cause of this would be on PRs with a massive amount of changes, such as the one where this was found by your team @osterman, in a PR that reorganized substantial parts of the repo. Because this action writes a summary of all the dependency changes to the action job summary, it can get into this situation.
A potential workaround would be to set the show-openssf-scorecard
setting to false
, which will reduce the amount of content written to the log, but even that cannot not guarantee that the output buffer could get too large on a PR with hundreds of changes to it.
For those +1'ing this issue, having links to example PRs and action runs would be helpful for us to diagnose the issue better.
We'd also love to take a look at any contributions toward a fix, if anyone has time to take a crack at it.
A PR to address this has been landed, and should be present in the next DR Action point release 👍
For folks that want to try this out in preview, you should be able to customize the version of the DR Action you're using to pin to the HEAD
commit SHA of this PR and give it a try
@elireisman Using the merge commit we still encounter the issue:
Run actions/dependency-review-action@6ea3b24563819b02be6332d9a462499780efd5d1
Dependency review did not detect any denied packages
Vulnerabilities
Licenses
Denied
Scorecard
Dependency Changes
Error: $GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 1540k. For more information see: https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary
👋 @chintai-paul thank you for trying the change out on the repo you've been having trouble with. Is this a public repo, and if so, can you point me to it?
I suspect the additional table formatting applied to the truncated summary is adding to the total buffer size and requires us to set a lower threshold, but I'll know more when I can circle back. Will post an update and/or a follow up PR when I know more, thanks again for letting me know 🙇
@elireisman Unfortunately it's a private repository. Here's the output amount of each category in the action output:
4 Vulnerabilities, 8 missing licenses, 0 denied, 990 scorecards (24 below threshold) (58619 characters), 2193 lines of dependency changes (68599 characters).
Configuration: fail-on-severity: high
, comment-summary-in-pr: on-failure
FWIW I ran into this as well, repository is public in this case if you wanted to take a look: https://github.com/embrace-io/embrace-react-native-sdk/actions/runs/11239608069/job/31247062327?pr=53
We are also seeing this issue, on v4.3.3, in a private repo. We are using this to ensure packages with licenses we don't allow are not merged, and this action can't fail, or we will have to abandon your solution entirely. The action needs to handle errors and still pass or reject correctly regardless of whether a summary gets uploaded somewhere, that's of secondary importance. Also github's own actions should not be failing because of github's own arbitrary size limits.
Hello folks - thank you for the updates on this. The fix we attempted was implemented as a stopgap, during a team first responder rotation. Unfortunately, the quick fix was not a comprehensive solution.
The DR Action currently caches a lot of it's output in the host Action's own core.summary
buffer rather than in local structures that can be formatted after the fact. This makes it awkward to right-size summary outputs when a DR run generates oversized output. Refactoring to decouple DR results from core.summary
outputs will also let us unit test these post-processing steps in isolation, and avoid this kind of trouble in the future.
The work is tracked to implement this, but as the scope extends beyond an FR shift, we are still attempting to prioritize it. As Jon mentioned upthread, if anyone wants to take a swing at contributing in the meantime, we'd be happy to review those PRs.
Describe the bug It gives me the below error of the size .
To Reproduce
Warning: Unable to write summary to pull-request. Make sure you are giving this workflow the permission 'pull-requests: write'. Error: $GITHUB_STEP_SUMMARY upload aborted, supports content up to a size of 1024k, got 2906k. For more information see: https://docs.github.com/actions/using-workflows/workflow-commands-for-github-actions#adding-a-markdown-summary
My workflow uses upgraded version that is :-
the comment-summary-in-pr must be present, otherwise you won't get the output