upload-artifact zips .tar.gz archive #109
Comments
|
If you currently upload an any archive file ( This is a limitation of our APIs and our UI, some of my earlier comments go into more details #39 (comment) and #39 (comment) If you also look at our public api to download an artifact, you'll notice that we currently require a zip |
|
@konradpabjan is this behavior going to change at some point or we are stuck with it for life? It's unclear from your comments. (I get that it's not a limitation of this action, but this is where users are affected, so I think it would make sense to post some updates here or envolve someone who works on the API.) |
|
We absolutely have plans to address this, it's on our backlog but there are other priorities that are currently preventing us from picking up the work. Our public roadmap has some high level priorities for Actions for those curious: https://github.com/github/roadmap/projects/1 The experience right now leaves a lot to be desired and an overhaul for the Artifacts UI + better API support has come up in internal discussions multiple times. We're definitely planning on addressing this. |
* chore: update fragmenter package * build: use PR action for testing * build: revert fragmenter and don't use dev-env for zip build * build: upload modules as artifact * fix: typo in lftp options * build: remove ascii option * build: use fragmenter output for artifacts * build: remove fragmenter from PR action * fix(ci): remove ascii option * build: zip before artifact upload refs: actions/upload-artifact#109
The upload workflow within github actions leaves a lot to be desired. There were many initial assumptions with GITHUB_WORKSPACE, paths from test repos, etc. that were originally left here. These more or less have been vetted now and this is the best result I have found to date for scale-network. Additionally, I am watching a few upstream stories in the upload actions repo just to see if it improves things for us in the near term: - actions/upload-artifact#109 - actions/upload-artifact#21
The upload workflow within github actions leaves a lot to be desired. There were many initial assumptions with GITHUB_WORKSPACE, paths from test repos, etc. that were originally left here. These more or less have been vetted now and this is the best result I have found to date for scale-network. Additionally, I am watching a few upstream stories in the upload actions repo just to see if it improves things for us in the near term: - actions/upload-artifact#109 - actions/upload-artifact#21
|
+1 on this, I compress all my artifacts to .tar.xz but I have no choice but to download them as .zip files that I have to unzip to recover the already-compressed .tar.xz artifact. Is this going to be fixed anytime soon? It's a pain |
The upload workflow within github actions leaves a lot to be desired. There were many initial assumptions with GITHUB_WORKSPACE, paths from test repos, etc. that were originally left here. These more or less have been vetted now and this is the best result I have found to date for scale-network. Additionally, I am watching a few upstream stories in the upload actions repo just to see if it improves things for us in the near term: - actions/upload-artifact#109 - actions/upload-artifact#21
|
This is basically a duplicate of: The solution for both would be to avoid zipping "compressed archives" |
Yes, it's a tarball. But due to limitations in the GH API, at present it will be wrapped in a zip file. cf. actions/upload-artifact#109
Yes, it's a tarball. But due to limitations in the GH API, at present it will be wrapped in a zip file. cf. actions/upload-artifact#109
It was originally thought that by adding the extension .img.gz would allow for the downloaded artifact to not be double zipped. However, this seems to be a bug in github, which can be tracked via: actions/upload-artifact#39 actions/upload-artifact#109 Signed-off-by: Matt Struble <mattstruble@outlook.com>
Describe the bug
Uploading a
.tar.gzartifact results in the archive being.zipped. Many (if not probably most) projects on GitHub tend to prefer the.tar.gzextension, rather than.zip, so it most likely isn't a good idea to archive them again under a different format and/or forcing maintainers to use a specific version.Version
Environment
Screenshots
Run/Repo Url
As I may take down or otherwise modify my tree at any given moment, here's the pull request in question.
How to reproduce
.tar.gzarchive in a workflow.Additional context
Also see: #39
The text was updated successfully, but these errors were encountered: