Cannot upload artifacts

[kinosang]

Got error of ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:2384)

full logs see https://github.com/JoyMoe/OpenData/runs/3917346331?check_suite_focus=true

[eine]

That is probably a temporary connection error on GitHub's side. Can you please try restarting the workflow?

Just in case, remove any asset from https://github.com/JoyMoe/OpenData/releases/tag/nightly starting with tmp.*.

[kinosang]

@eine after remove the release, it works well now. I'll keep watching for some days.

[lazka]

we have the same problem here https://github.com/msys2/msys2-installer/runs/3980189142?check_suite_focus=true

this started ~18 day ago

[kinosang]

It works well for 8 days now. Seems no other action need to take.

[stnolting]

Same issue over here: https://github.com/stnolting/neorv32/runs/3995838174?check_suite_focus=true

The problem started yesterday; four days ago everything was still working fine.

[umarcor]

@stnolting, I cleaned the assets of the nightly release in NEORV32 and I restarted the Documentation workflow. It's green now.

[stnolting]

@umarcor
That's all? 😅 Awesome, thank you very much!

[lazka]

yeah, deleting assets before the upload seems to work around the issue

[eine]

The main problem here is that GitHub's internal connections seem not to be very stable, so rather frequently uploading artifacts as assets does produce failures. Until recently, tip could not handle the broken state, and that's why the recommended workaround was to remove the assets manually and restart the workflow. Most of the time, that works. However, it is undesirable, because assets are not available for the duration of the workflow (which can take up to 6h). So, users willing to retrieve tip/nightly assets do get errors during that period.

In order to maximise the availability of assets, tip first uploads new versions with a different name, then removes the old one and last it renames the new:

tip/tip.py

Lines 160 to 166 in fb0c52c

	print(f" - uploading tmp.{aname!s}...")
	new_asset = upload_asset(artifact, name=f"tmp.{aname!s}")
	print(f" - removing...{aname!s}")
	asset.delete_asset()
	print(f" - renaming tmp.{aname!s} to {aname!s}...")
	new_asset.update_asset(aname, label=aname)
	artifacts.remove(artifact)

Until some days ago, when the first step failed ("uploading tmp."), all subsequent executions of the Action would fail, because there was no procedure for cleaning it. So, a possible less intrusive solution was to manually remove the assets shown as tmp.... and then restart the workflow. I fixed that and now the Action should handle it automatically:

tip/tip.py

Lines 139 to 152 in fb0c52c

	def upload_asset(artifact, name):
	try:
	return gh_release.upload_asset(artifact, name=name)
	except GithubException as ex:
	if "already_exists" in [err["code"] for err in ex.data["errors"]]:
	print(f" - {name} exists already! deleting...")
	delete_asset_by_name(name)
	else:
	print(f" - uploading failed: {ex}")
	except Exception as ex:
	print(f" - uploading failed: {ex}")
	print(f" - retry uploading {name}...")
	return gh_release.upload_asset(artifact, name=name)

Therefore, most of the problems you had should not happen again, as long as they were related to this "uploading of tmp files failing".

However, I still found some failing cases that required me to manually remove all assets (not the release, just the assets), and not only the tmp. ones, which the Action was already handling properly. That means there might be some other cause povoking the release to be in a broken state, but I'm unsure about the root. Please, let me know if you keep having issues.

On the other hand, users with option rm: true should not be affected by this issue at all.

[lazka]

Tried again, still fails :( https://github.com/msys2/msys2-installer/runs/4202718077?check_suite_focus=true

Likely the problem is with github, still annoying :(

[lazka]

Could this be an alpine related issue? searching for the SSL error gives me various alpine user reports.

Maybe we could try the default docker image instead (python:3.10 or something)?

[eine]

@lazka, absolutely! If that is the case, that'd be an awesome catch! Let me run some local tests and I'll update the dockerfile.

[eine]

So, on the one hand I changed the base image from python:alpine to python:slim-bullseye. That's twice the size (142MB vs 64 MB), but let's hope it solves the problem. On the other hand, I added a variant of the action to subdir composite. As the name suggests, that's a Composite Action instead of a Docker Action. That will install the dependencies (PyGitHub) on the workflow, instead of using an isolated container. However, it will let us know whether the problems are due to using containers.

@lazka, @stnolting, @kinosang, if you want to try the composite variant, just changing the name should be enough: eine/tip/composite@master.

[lazka]

That's twice the size (142MB vs 64 MB), but let's hope it solves the problem.

Just wanted to point out that despite it being larger it is still faster to run since there are Python wheels for Debian while it compiles packages on alpine.