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

Container archive produces tar - not gzip tar?! #518

Open
sebader opened this issue Nov 14, 2023 · 7 comments
Open

Container archive produces tar - not gzip tar?! #518

sebader opened this issue Nov 14, 2023 · 7 comments

Comments

@sebader
Copy link

sebader commented Nov 14, 2023

I'm trying the new option to produce the docker image as a compressed archive (#283). In general this seems to work, however, the file seems to be a tar file, not a tar.gz

When trying to use gunzip (on Linux or MacOS) it fails with:

gunzip sdk-container-demo.tar.gz
gunzip: sdk-container-demo.tar.gz: not in gzip format

When trying to open the file on MacOS with 7z (7z x sdk-container-demo.tar.gz), it succeeds, but just because 7z just falls back to untar-only.

Extracting archive: sdk-container-demo.tar.gz
WARNING:
sdk-container-demo.tar.gz
Can not open the file as [gzip] archive
The file is open as [tar] archive

Produced the file with:

dotnet publish ./src/myproject/myproject.csproj -p ContainerArchiveOutputPath=./images/sdk-container-demo.tar.gz -p PublishProfile=DefaultContainer

dotnet --version
8.0.100-rc.2.23502.2

cc @Danielku15

@Danielku15
Copy link
Contributor

Currently this behavior is intended and aligned with what docker save does. docker load would support also compressed archives. I was working and planned to contribute further functionalities around this feature but they didn't make it into net8.0 and seem to be a bit on hold due to the .net team entering the release phase of net8.0. With this functionality here there would be a new setting to control what kind of output archive is written and tar.gz could be a second extension. dotnet/sdk#35204

If the other extensions make it to the SDK I would guess also DockerTarGz could easily be an additional format that can be supported.

Of course there might be always the possibility to gzip the tar manually if this is required for your workflow.

It might be a wrong expectation that the archive format and compression is auto-detected by the file extension, this is not the case.

@sebader
Copy link
Author

sebader commented Nov 14, 2023

I'm totally fine if the behavior is right now that it produces a tar file instead of a gzip. But then the docs must not refer everywhere to it with .tar.gz. That is just wrong. It raises false expectations and creates confusion (and failed CI pipelines in my case...)

@Danielku15
Copy link
Contributor

That's indeed wrong. The feature I made added "tar" writing aligned with docker save, not yet "tar.gz" which is mentioned at various places 😱

@baronfel Please let me know if I should prepare a code change around this feature (e.g. to auto-detect tar vs tar.gz or whether to always write tar.gz)

@baronfel
Copy link
Member

Excellent catch folks - I think it's best to try and fix doc mentions of tar.gz in the docs first, then add explicit support for toggling compression as a separate feature.

Do you have some links to where you've seen the incorrect docs?

@Danielku15
Copy link
Contributor

@sebader
Copy link
Author

sebader commented Nov 14, 2023

Yeah I came across it in the announcment blog - which links to the issue #283 as well as the PR, both say "tar.gz" dotnet/sdk#35151

@sebader
Copy link
Author

sebader commented Jan 3, 2024

Excellent catch folks - I think it's best to try and fix doc mentions of tar.gz in the docs first, then add explicit support for toggling compression as a separate feature.

Do you have some links to where you've seen the incorrect docs?

just a ping on this @baronfel The links don't seem to have been updated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants