Repeated invocations of dotnet-install.sh will fill TMP directory

[sfoslund]

---

Issue moved from dotnet/sdk#11858

• Please respond to @MattGal.

---

From @MattGal on Tuesday, June 2, 2020 5:43:10 PM

See https://github.com/dotnet/sdk/blob/master/scripts/obtain/dotnet-install.sh#L822

We had all the test machines run out of disk space overnight from just running too many tests. (in the case I investigated it was about 900 tests on one machine leading to 21 GB of SDKs in the TMP folder).

Thoughts on how to fix:

• At a minimum, when the job is done successfully the zip_path file should be deleted if it exists regardless of content
• Could consider also a more distinct temp file name and cleaning up someDistinctDotNettyName.* in TMP every time.

[bekir-ozturk]

Thank you for the issue @MattGal & @sfoslund . I agree with you that at least the archive should be deleted.

@MattGal Can you give me a bit more info on your use case? Some questions:

• Why is it that you install the SDK for each test, can't you install once at the beginning?
• In your build definition, did you consider checking if SDK is already installed and run the script only otherwise?
• Would it help you if script detected the existing SDK and didn't install it again? There is a similar request here Cache & reuse previously downloaded SDK #15 , please feel free to comment on it.

[bekir-ozturk]

@sfoslund Just a tip: You can actually transfer an existing issue within the same organization (right column, near the bottom). That would transfer all the comments, links etc. and you wouldn't need to do any copy/pasting.

[sfoslund]

It looks like I don't have the right permissions to transfer it directly, so I used the hubbup issue mover instead (which makes it uglier but gets the job done :/ )

[MattGal]

@MattGal Can you give me a bit more info on your use case? Some questions:

• Why is it that you install the SDK for each test, can't you install once at the beginning?

This isn't "me" doing it, it's users of the .NET Helix work infrastructure running their test payloads. If these were my Helix work items, I'd bring the SDK along as a correlation payload, guaranteeing one download per job and guaranteeing cleanup after the next 2 jobs ran. I have shared this feedback with the team that brought this to my attention.

Regardless, when running on a clean machine the work in question does need one copy of the SDK and they run the script. Compound that over several hundred jobs running on the same machine, plus the machine's base OS starting with only 30 GB free before dependencies and other payloads, and the space gets used up fast.

• In your build definition, did you consider checking if SDK is already installed and run the script only otherwise?

As noted above there's lots of better ways to do this, we just don't tend to force Helix users to do things a specific way; this allows users to basically "wedge in" their old test infrastructure and take their time doing an improved version of this as they desire more perf and fewer filled hard disks.

• Would it help you if script detected the existing SDK and didn't install it again? There is a similar request here Cache & reuse previously downloaded SDK #15 , please feel free to comment on it.

Sure, if a usable version is present and find-able, using that instead would be great. Probably would want to be a new behavior and a new flag in case this is not what some folks want.