Clean up contents from previously-sb tarball post binary-cleanup #19632
Conversation
|
One thing I am a little confused about: when I use |
I think it's because the rebootstrapping uses the working dir? I'm not sure if that can be used for this tool. If it can, that feels like the better solution consistency-wise. Otherwise, the changes you've made LGTM. Thanks for fixing this, Omair! |
Bootstrap is an optional process. So we will need a code path for binary-cleanup that works without it anyway. I think we should keep this simple and always assume bootstrap was not run. |
omajid
force-pushed
the
prep-remove-extracted-tarball-packages-post-binary-cleanup
branch
from
a7bcabf
to
e3da9c4
Compare
Sorry, I wasn't clear with what I meant. I was suggesting that the binary tool should follow the same pattern that the bootstrapping tool uses with the working_dir, not reuse the working_dir from the bootstrapping. That is, the binary tool would create a temporary working_dir that gets cleaned up after. That said, it's a very similar solution to what you have already included in this PR. I'm personally fine with using the "extracted_tarball" switch as you have done. |
If we extracted the previously-source-build tarball only for running the binary cleanup tool, clean up the extracted contents. This undo's the extraction operation that was only performed for running the binary-cleanup tool. I am creating a tarball for building .NET offline post-prep. In that scenario, I run `./prep-source-build.sh --bootstrap`, and then package up the entire VMR directory into a tarball. Without this cleanup, there are a ton of duplicated binaries in the tarball, since the nuget packages are both in previously-source-built archive and in an extracted form. With this change, the archive size goes from just over 4GB to just over 2GB.
omajid
force-pushed
the
prep-remove-extracted-tarball-packages-post-binary-cleanup
branch
from
e3da9c4
to
f92d698
Compare
|
I have updated this PR to use a temporary working directory for extracting files before running the binary tool. And like the other usage of working directory, it is cleaned up. |
There was a problem hiding this comment.
As part of the installer->sdk repository consolidation we are already switching the VMR over into dotnet/sdk. ETA: today or tomorrow. The last manual code sync happened today and we don't plan on doing another sync. Please close this PR and submit it into dotnet/sdk. Sorry for the inconvenience.
|
Re-opened as dotnet/sdk#40772 |
If we extracted the previously-source-build tarball only for running the binary cleanup tool, clean up the extracted contents. This undo's the extraction operation that was only performed for running the binary-cleanup tool. I am creating a tarball for building .NET offline post-prep. In that scenario, I run ./prep-source-build.sh --bootstrap, and then package up the entire VMR directory into a tarball. Without this cleanup, there are a ton of duplicated binaries in the tarball, since the nuget packages are both in previously-source-built archive and in an extracted form. With this change, the archive size goes from just over 4GB to just over 2GB. This is a port of dotnet/installer#19632 from installer repo to sdk.
If we extracted the previously-source-build tarball only for running the binary cleanup tool, clean up the extracted contents. This undo's the extraction operation that was only performed for running the binary-cleanup tool.
I am creating a tarball for building .NET offline post-prep. In that scenario, I run
./prep-source-build.sh --bootstrap, and then package up the entire VMR directory into a tarball. Without this cleanup, there are a ton of duplicated binaries in the tarball, since the nuget packages are both in previously-source-built archive and in an extracted form. With this change, the archive size goes from just over 4GB to just over 2GB.