Virtual-environments: Deprecation of old Haskell, Cabal versions on Ubuntu images

[maxim-lobanov]

Hello everyone,
Recently, actions/setup-haskell v.1.1 was released. This version started to support installation of Haskel, Cabal, Stack on-demand. Considering this fact, we are planning to deprecate old versions of ghc and cabal from the image to release free space for new software.

In future, we are planning to pre-cache 3 latest releases of ghc (currently, 8.10.1, 8.8.3, 8.6.5) and 1 latest release of cabal (currently, 3.2) on the image. Any other versions can be installed in runtime using actions/setup-haskell action.
The full list of versions that will be deprecated:

• ghc: 8.0.2, 8.2.2, 8.4.4, 8.6.2, 8.6.3, 8.6.4, 8.8.1, 8.8.2
• cabal: 2.0, 2.2, 2.4, 3.0

These versions will be removed on May, 28.
Please let us know if you have any concerns or objections.

[rbellamy]

This brings up a point that I am continually confused by - all the sample workflows suggest using an action to "setup" your respective environment (e.g. Python, Node, Java, Haskell, etc), and yet the runners come with those preinstalled - in the case of Java, it's got 7, 8, 11, and 12.

What is the policy (if there is one) and best-practice of pre-installed vs "action-setup" for language toolchains? Is there a document that explains the thinking?

[maxim-lobanov]

Hello @rbellamy , you should always use setup actions to configure your environment if it is possible.

The most of the setup-* actions (at least, official actions) works the following way:
1) Check if specified version is pre-installed on the image. If it is pre-installed, action switches version immediately (without any delay).
2) If version is not pre-installed, it downloads it and install in runtime. But it can take some time to download and install.

So I would say that pre-installed versions is some kind of caching level for actions to speed up configuring environment.

Our policy is pre-installing the most popular versions (N versions) to make sure that the first way is used for the most of the builds.

One more advantage of using actions is that your builds won't be broken if we deprecate particular version. Build can be slow down because version will be installed in runtime but build will continue to work.

[rbellamy]

@maxim-lobanov I'm not sure I've found that the official setup actions leverage the preinstalled versions. Maybe I'm wrong, but from what I can tell, they ONLY leverage those items that have been installed in the tool cache.

Java setup action

  let toolPath = tc.find(javaPackage, version);

toolcache-1804.json

{
    "@actions/toolcache-ruby-ubuntu-1804-x64": [
        "2.4", "2.5", "2.6", "2.7"
    ],
    "@actions/toolcache-pypy-ubuntu-1804-x64": [
        "2", "3"
    ],
    "@actions/toolcache-boost-ubuntu-1804-x64": [
        "1.69", "1.72"
    ]
}

So, in order for the Java setup action to leverage the pre-installed versions of Java, wouldn't they have to be installed in/opt/hostedtoolcache?

[maxim-lobanov]

@rbellamy , I am not familiar with actions/setup-java action so I was talking about setup-haskell, setup-node, setup-python, and etc. But after quick look, you are right about setup-java.

We install Java to these locations from the very beginning and actions/setup-java was appeared later. So I think it is the question for maintainers of actions/setup-java action why they are not looking for pre-installed versions and download Java every time in runtime. May be there is a strong reason to download Java in runtime every time.
You can raise issue in this repository to consider moving Java to tool-cache directory but I am not sure that we can do that because it will be a breaking change for people who use hardcoded paths (unfortunately, such people exist). So I would consider extending setup-java action to look at additional directories as more perspective option.

[AlenaSviridenko]

image with the changes was fully deployed, closing this issue.