Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Large Actions artifacts (> ~8MB) will fail checksum when merging their chunks #31354

Closed
lunny opened this issue Jun 13, 2024 · 3 comments · Fixed by #31664
Closed

Large Actions artifacts (> ~8MB) will fail checksum when merging their chunks #31354

lunny opened this issue Jun 13, 2024 · 3 comments · Fixed by #31664
Labels
Milestone

Comments

@lunny
Copy link
Member

lunny commented Jun 13, 2024

ref: https://forum.gitea.com/t/large-actions-artifacts-8mb-will-fail-checksum-when-merging-their-chunks/9291

I'm using a self-hosted Gitea 1.22.0, with the patched version of upload-artifact@v4 (https://github.com/ChristopherHX/gitea-upload-artifact@v4), and am trying to upload a ~1.8GB artifact.

From the Actions step:

Uploaded bytes 1851809172
Finished uploading artifact content to blob storage!
SHA256 hash of uploaded artifact zip is 5445b7ac4b993cbc01f349b0ec90b8ebceee564cff62ce9a529fdb9ce1326886
Finalizing artifact upload
::error::Failed to FinalizeArtifact: Unexpected token 'E', "Error merge chunks%0A" is not valid JSON

When looking at the Gitea server logs, this matches up to this error message:

...artifactsv4.go:363:finalizeArtifact() [E] Error merge chunks: update artifact error checksum is invalid

I did some tests, and it looks like any artifacts that are bigger than roughly 8MB will fail to be merged when finalizing the upload.

@lunny lunny added the type/bug label Jun 13, 2024
@ChristopherHX
Copy link
Contributor

Investigating... Interesting my original .net based implementation has no problem with 807MB Zip files for me (that doesn't do checksum checks like I did for Gitea, but the linux shasum tool confirms a correct upload)

Now I need to test Gitea Actions itself and bisect the problem

Related my nektos/act port seem to be affected as well (8 MB mentioned as well...), this could be indeed a porting problem from .net to go

@ChristopherHX
Copy link
Contributor

Problem found for act:

Multiple chunks are uploaded with type "block" without using "appendBlock", my .net Implementation didn't have different handling for these upload type and this solves the issue for act itself

8MB seems to be the chunk size

@VAllens
Copy link

VAllens commented Jul 23, 2024

I also encountered the same problem.
Has there been any progress?

@lunny lunny added this to the 1.22.4 milestone Nov 15, 2024
GiteaBot pushed a commit to GiteaBot/gitea that referenced this issue Nov 15, 2024
Multiple chunks are uploaded with type "block" without using
"appendBlock" and eventually out of order for bigger uploads.
8MB seems to be the chunk size

This change parses the blockList uploaded after all blocks to get the
final artifact size and order them correctly before calculating the
sha256 checksum over all blocks

Fixes go-gitea#31354
@go-gitea go-gitea locked as resolved and limited conversation to collaborators Dec 21, 2024
project-mirrors-bot-tu bot pushed a commit to project-mirrors/forgejo-as-gitea-fork that referenced this issue Jan 23, 2025
Multiple chunks are uploaded with type "block" without using
"appendBlock" and eventually out of order for bigger uploads.
8MB seems to be the chunk size

This change parses the blockList uploaded after all blocks to get the
final artifact size and order them correctly before calculating the
sha256 checksum over all blocks

Fixes go-gitea#31354

(cherry picked from commit b594cec)

Conflicts:
	routers/api/actions/artifactsv4.go
  conflict because of Refactor AppURL usage (go-gitea#30885) 67c1a07
    that was not cherry-picked in Forgejo
    the resolution consist of removing the extra ctx argument
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants