Add install script option to install dependencies

[wli3]

Per @richlander :

Open question ... Should the fine folks working on / using the GitHub Actions Runner use the install script to install .NET dependencies?

https://github.com/actions/runner/blob/master/docs/start/envlinux.md

[wli3]

I think so. Arcade is essentially using install script to bootstrap SDK. Is there anything special for Github Actions?

[jkotas]

The install script tells you about dependencies that need to be installed, but it does not install any dependencies for you. You have to figure out how to install them yourself. Side-note: There are bugs in what it tells to install that makes it even harder to figure out what you need to do.

The install script should have an option to install the dependencies for you, so people do not have to roll their own scripts to do that.

Arcade bootstrap does not have this problem. It assumes that the dependencies are installed. E.g. if you run arcade bootstrap on vanilla Ubuntu, it is going to fail.

[wli3]

I see. It would be a good feature to add. I think the biggest problem is the cost and the potential alternative.

Adding dependencies to the install script would be very costly in the long run. Especially considering now we also have to consider the servicing of all our dependencies across all distros. We are still struggling with our own servicing today. I would not take this on lightly. Although we might utilize some existing work for docker @mthalman

The existing bash and powershell install scripts are proven to be fragile. I suggest we don't add any more complexity before we have our existing engineering quality under control.

@jkotas do you see any alternatives? We also have rpm and deb install that would include the dependencies as well as using docker in GitHub Actions.

Back to the original question, if we should use install script for github actions. We may need more investigation. I am not familiar with github actions. We need to looking into if github action with docker can satisfy the build scenario considering most of the customer would only build in 1 distro. And if we should also provide build definition for github actions (just like Azure Devops).

@donJoseLuis @marcpopMSFT @KathleenDollard @richlander

[jkotas]

Adding dependencies to the install script would be very costly in the long run.

The install script does have the list of dependencies in it today. It uses this list to check for the presence of the dependencies. I assume that this check is there for a reason - diagnosing crashes caused by missing dependencies later is hard.

Yes, this list needs updating every once in a while (and the list is outdated currently as I have pointed out above).

It does not sound like a too big of a step to make the script install the dependencies for you when you ask it to, in addition to telling you what is missing.

do you see any alternatives? We also have rpm and deb install

We provide number of ways to bring down the bits to the machine, and let people choose the best one depending on the context. I do not see rpm, dep, docker or snap to be a viable replacement for situations where the dotnet-install script is typically used today.

[wli3]

Yes, this list needs updating every once in a while (and the list is outdated currently as I have pointed out above).

This list need to be actively monitored for any security issue. And we don't have this infrastructure today.

This list would be long considering the we should support all distros we support today. We also need to test this script regularly for all supporting distros. This is also very costly. We are struggling to even have few up-to-date distros for sanity check in SDK today.

[mthalman]

I see this as being related to dotnet/runtime#13291 which says there should be a machine-readable master location of the native dependencies.

[donJoseLuis]

@bozturkMSFT can you discuss with Kathleen how this feature request fits with our short-term goals?

[donJoseLuis]

The need tracked in this issue should is tracked as a lower priority item under the re-engineering effort. Moving to the re-engineering project.

[bekir-ozturk]

Hi,

The scripts are being put into "maintenance mode". This means that the scripts and their ecosystem (i.e. website and feeds) will continue to be monitored, but no new features will be delivered. We are still committed to maintaining the scripts’ high availability and we will quickly respond to any incidents.

As part of this effort, we are closing the issues that aren't planned to be delivered. Unfortunately, this issue is one of those that didn't make the cut, and therefore will be closed.
If you think this is a must-fix issue before maintenance mode begins, please feel free to comment.

Thanks

[mthalman]

I've added this feature in the overall plan of work for dotnet/core#5651. We can revisit funding for this when the time comes.