search

actions / runner-images

GitHub Actions runner images
MIT License
9.17k stars 2.84k forks source link

Add MSYS2 to Windows #30

Closed kaylangan closed 3 years ago

kaylangan commented 4 years ago

Tool information

Virtual environments affected

Can this tool be installed during the build? Yes, via choco install msys2.

Are you willing to submit a PR?

eine commented 4 years ago

Ref actions/starter-workflows#95 (/cc @krcroft @andymckay)

Ref numworks/setup-msys2 1138-4EB/setup-msys2 (/cc @Ecco)

eine commented 4 years ago

I suggest to download and extract the available MSYS2 tarball, instead of using chocolatey. This is because chocolatey requires ~5min but the tarball is extracted in 30s. Please, see https://github.com/actions/toolkit/pull/165#issuecomment-566247350 for other references related to current workarounds for this issue.

rgl commented 4 years ago

@eine that time difference is probably because one is updating the base tarball binaries and the other is not.

eine commented 4 years ago

@rgl, although it might be the case, I don't think it is the only reason. Precisely, an option is available in setup-msys2 which allows to not only extract the tarball, but also execute pacman -Syu. Extraction time is ~40s (https://github.com/numworks/setup-msys2/runs/348237664) and extraction plus update requires ~70s (https://github.com/numworks/setup-msys2/runs/348238118). Conversely, choco install msys2 takes 270s (https://github.com/eine/ghdl-packaging/commit/069ae680c38a1832950a377618dc4a1798d6ccf3/checks?check_suite_id=231637124) at least.

Nevertheless, I think that installation time is not revelant in this specific request. Chocolatey package mingw is outdated (frozen to say the least) and msys2 should be installed instead. It is not reasonable to expect users to install MSYS2 through an action (which is already available), because it has many limitations. Provided that a proper MSYS2 installation is included in windows-latest, I don't really care how GitHub decides to do it.

MSP-Greg commented 4 years ago

The base MSYS2 install is mostly just command line tools, which are very similar to the tools provided with Git for Windows.

I think most users are looking for the main install along with the groups 'base' and 'base-devel', and probably mingw-w64-x86_64-gcc and mingw-w64-x86_64-cmake. Since the tarballs are not updated frequently, pacman -Syu should be done at some point.

Beyond that, packages like OpenSSL, libyaml, etc, but they can installed in the workflows...

dreamer commented 4 years ago

I think most users are looking for the main install along with the groups 'base' and 'base-devel', and probably mingw-w64-x86_64-gcc and mingw-w64-x86_64-cmake.

There's no reason to presume that. We are using MSYS2 to test Windows compilation of our project using GCC and Clang (in parallel to MSVC) and depend on following packages: pkg-config libtool libpng zlib ncurses SDL2 SDL2_net opusfile autogen autoconf automake-wrapper.

MSP-Greg commented 4 years ago

Many of the packages you mentioned are part of base-devel. pacman -Qg base-devel...

CLang/LLVM could be added.

We can't and shouldn't expect Actions to have every package. What I'm proposing is what I mentioned and any addition compiler toolsets (as you've mentioned CLang).

MSP-Greg commented 4 years ago

@kaylangan

  1. Is C:/msys64 ok for location? This is the standard location.

  2. What language would be best for an install script?

1480c1 commented 4 years ago
  1. Is C:/msys64 ok for location? This is the standard location.

That is the default on a lot of systems

2. What language would be best for an install script?

Since this for windows, I would assume powershell

MSP-Greg commented 4 years ago

I created an Install-MSYS2.ps1 file similar to the files in images/win/scripts/Installers. I did not create a Validate-MSYS2.ps1 file, but I suppose one could check bash, make, gcc, pacman, etc for output with a version argument.

See the output in the 'Install MSYS2' step in https://github.com/MSP-Greg/msys2-action/runs/396221571. It took 6 minutes. The bottom of the output contains lists of MSYS2 & MinGW64 packages.

The script only installs both 32-bit and 64-bit tools.

Note that if this is added to Windows images, the toolcache Ruby installs will no longer require embedded MSYS2 installs, which reduces their size considerably, and also allows install from a signed *.7z file.

As to whether to install any other packages, that's another issue.

dreamer commented 4 years ago

As to whether to install any other packages, that's another issue.

I would suggest adding clang; it can coexist with mingw.

MSP-Greg commented 4 years ago

@dreamer

How do you install from pacman? As below? It installs llvm as a dependent package...

pacman -S mingw-w64-x86_64-clang

Running pacman -Ss clang shows a few packages. I just want to make sure to install what's needed...

dreamer commented 4 years ago

In dosbox-staging we use mingw-w64-x86_64-clang and mingw-w64-i686-clang.

MSP-Greg commented 4 years ago

I updated the file mentioned above and the link to a workflow run. It now installs both 32 & 64 bit tools.

MSP-Greg commented 4 years ago

@eine @lazka

Do you have any suggestions for what packages should be installed in the MSYS2 install?

The script I provided installs base-devel and compression groups on MSYS2, and clang, cmake, gcc, and ragel on mingw64 / mingw32.

There's a lot of packages, Appveyor currently has these installed. Any suggestions for the most popular packages that could be included to the above?

Ecco commented 4 years ago

@MSP-Greg Why install any package by default anyway? Just do the base install and let developers install whatever package they want. Otherwise you'll uselessly slow things down for a lot of people…

MSP-Greg commented 4 years ago

@Ecco

Sorry you disagree.

It depends on your reference.

My reference is CI that also runs on Ubuntu & macOS, where the equivalent of MSYS2, compiler tools, and many packages are already installed.

Between GitHub issues and GitHub Community, there seem ot be many people asking for MSYS2, and many people trying to do their own install and unhappy with time it takes.

Otherwise you'll uselessly slow things down

I suspect having the packages installed on the 'virtual-environment' image is much faster than downloading them and installing. Again, I'm not suggesting adding a lot of packages, just what would be commonly used.

What have you used MSYS2 for?

1480c1 commented 4 years ago

@MSP-Greg Why install any package by default anyway? Just do the base install and let developers install whatever package they want. Otherwise you'll uselessly slow things down for a lot of people…

@Ecco By not providing any default installs, the amount of time spend per person needing to install the whole entire gcc toolchain and clang+llvm etc would be huge and cost extra time for each VM needing to be on. Plus the trade off of initial time spend installing and size increase is worth the amount of time saved later on when you don't need to host the vm for a few more minutes and time spend downloading the packages again.

Finally, if everyone who wanted to test mingw-w64 on windows needed to download every single package every time, I'm afraid that msys2.org will probably not be able to handle it.

That would essentially be handing a person a clean arch install and expecting them to install everything needed to run a ci every single time they want to test their software

eine commented 4 years ago

@MSP-Greg, thanks for providing an example installation script! I hope that employees pick it ASAP.

Regarding the discussion about which specific packages should or should not be installed, IMHO it is an interesting but absolutely irrelevant discussion in the current context. I don't mean to cut the discussion, but to bring the attention so that we can focus on the features that are necessary and useful for all of us.

Precisely, I think that installing MSYS2 is not enough and it can break the environment, as it would conflict with mingw. We need GitHub employees to confirm that MSYS2 is going to replace MINGW, and that the default bash will be the one provided by MSYS2. This has several effects:

I think most users are looking for the main install along with the groups 'base' and 'base-devel'

I do think that all users that want MSYS2 are looking for pacman. That's the only certainty we have. I agree with you that having base, base-devel, etc. can be useful for a majority of users, and I would not oppose to having them installed by default. Nevertheless, as said, I think this details are not relevant. Specially for open-source projects, where those extra minutes are not charged. That's something GitHub needs to worry about, to optimize their own infrastructure. Given the current performance penalty of Windows environments, that seems not to be something prioritary for them.

pacman -Syu should be done at some point

I think this is a different issue from installating default packages. This is about providing a "stable" environment or an "edge" set of packages. A first execution of the shell is recommended anyway. Hence, it's a matter of deciding which that first command should be. We had this discussion in setup-msys2 before: numworks/setup-msys2#7.

Overall, as long as a base MSYS2 is provided, all other features (updating, installing (cached) packages, etc.) can be managed by an Action such as setup-msys2. That's why I think we should focus on the features that are not easily achievable with an action right now.

Do you have any suggestions for what packages should be installed in the MSYS2 install?

Personally, I want mingw-w64-x86_64-llvm, mingw-w64-x86_64-clang, mingw-w64-x86_64-z3, mingw-w64-*-toolchain, since I'm building PKGBUILD files in an MSYS shell, before testing them in MINGW32 and MINGW64 shells. Anyway, once again, this should not be about what each of us in this thread wants. None of us has any data/statistics to justify the inclusion of any specific package.

Otherwise you'll uselessly slow things down for a lot of people…

This installation script is for the base image that GitHub has cached in their servers. Theoretically, when a workflow/job is started, all it needs to do is copy it to memory. That's the whole point of supporting a single Windows environment. Therefore, the penalty of having more packages installed by default should not be relevant at all. OTOH, not installing them is slow for sure, because they need to be retrieved each time. As a result, I think that GitHub is the one that should be worried about their HD/RAM footprint and network quote. That's something defined by their product strategy: do they want to take care of larger storage costs or do they want to charge paid users by forcing an slower environment?

Finally, if everyone who wanted to test mingw-w64 on windows needed to download every single package every time, I'm afraid that msys2.org will probably not be able to handle it.

I assume that GitHub has some internal caching that would prevent msys2.org from being hit too hard.

That would essentially be handing a person a clean arch install and expecting them to install everything needed to run a ci every single time they want to test their software

Well, this is the state of the art, since that's the essence of containers. Sure, you can have your own image built on top of a clean arch. However, pulling a large docker image in a GNU/Linux job is not very different from running a pre-install script in MSYS2. Most, if not all, practical use cases will need some kind of pre-install configuration, no matter how complete the default environment tries to be.

MSP-Greg commented 4 years ago

Precisely, I think that installing MSYS2 is not enough and it can break the environment, as it would conflict with mingw

That's dependent on what you have in PATH. Ever check to see all the OpenSSL dlls in path?

One thing you may not be aware of is that there are four basic MSYS2 installs right now on the image. Each Ruby version has an embedded install. For one of the versions, see the MSYS2 Package Info step in: https://github.com/MSP-Greg/github-actions-ruby-info/runs/395672983

So, given that, I stand by what I've suggested for inclusion in the base image, as it would allow removal of the embedded MSYS2 installs.

Finally, we all use MSYS2 in different ways. I work with Ruby, and MSYS2/gcc is needed for CI with extension gems. As an example, one gem that compiles with OpenSSL, compile is 0:23, test is 0:39, but updating gcc tools and installing OpenSSL takes 1:48.

With MSYS2 included in the images, and updated as the images are, that time of 1:48 might become almost zero, as it might just be doing an -Sy...

MSP-Greg commented 4 years ago

BTW, is there a preference for mingw-w64-*-toolchain instead of mingw-w64-*-gcc. toolchain has a few more pacakges...

eine commented 4 years ago

That's dependent on what you have in PATH. Ever check to see all the OpenSSL dlls in path?

I mean the default, which should not depend on any other additional tools in the PATH.

One thing you may not be aware of is that there are four basic MSYS2 installs right now on the image.

AFAIK, there is a single one that can be used by default with shell: bash, and that's MINGW not MSYS2. Apart from that, each packager/user can decide to embed (and thus duplicate) whichever tools they want. The case with Ruby is an example of poor packaging, not something we should generalise.

So, given that, I stand by what I've suggested for inclusion in the base image, as it would allow removal of the embedded MSYS2 installs.

There might be other constraints that would prevent Ruby packages from dropping their internal copy. Unless you are a maintainer, to assume that including a given set of packages in a rolling environment will avoid duplication, is to assume too much. Ruby packages can drop their copies as long as a bare outdated MSYS2 installation exists. Furthermore, Ruby packages can currently share a single copy of MSYS2.

With MSYS2 included in the images, and updated as the images are, that time of 1:48 might become almost zero, as it might just be doing an -Sy...

With a bare MSYS2 included and with you caching your custom dependencies, the time of 1:48 will also become almost zero, and it would not require to update anything each time. I feel that you are trying to purposely constrain the alternatives you have so that it seems that having packages installed by default is the only solution. It is not. It is your preference and it might be a sensible general approach. But there are definitely possible solutions that would perfectly fit with a bare MSYS2.

MSP-Greg commented 4 years ago

AFAIK, there is a single one that can be used by default with shell: bash, and that's MINGW not MSYS2

I think I made it clear that I was referring to MSY2. There are four copies. The copies are being used to build and test ruby master.

There might be other constraints that would prevent Ruby packages from dropping their internal copy.

There are not, as long as it's install to C:/msys64. I'm pretty familiar with Ruby, both popular extension gems/repos, and the language itself. I've contributed to both, in particular build scripts/workflows for building on MSYS2 gcc and MSVC.

I would also point out what AppVeyor has installed, which is far more than I've proposed. Somewhere above I've got a link to the packages they have installed. I doubt they would have added them without a good reason...

eine commented 4 years ago

I think I made it clear that I was referring to MSY2.

Then, I beg to differ. There is not a single MSYS2 environment that can be used by default in the following step:

shell: ????
run: |
  uname -a

See actions/runner#240.

There are four copies. The copies are being used to build and test ruby master.

If I don't get it wrong, those four copies (at least three of them) are included with Ruby packages. Hence, those are irrelevant for the majority of users of this environment.

Moreover, as said, having four copies is a decission of the packagers. They could use a single one, without requiring any modification to the existing environment.

There might be other constraints that would prevent Ruby packages from dropping their internal copy.

There are not, as long as it's install to C:/msys64.

Requiring it to be installed in C:/msys64 is, by definition, an additional constraint to "having a working MSYS2 environment (one that provides pacman) available by default", which is what this issue is about.

I'm pretty familiar with Ruby, both popular extension gems/repos, and the language itself. I've contributed to both, in particular build scripts/workflows for building on MSYS2 gcc and MSVC.

Then, I recommend to either suggest or contribute an alternative packaging procedure to avoid duplicating MSYS2 installations. Note that this is independent from the matter at hand.

I would also point out what AppVeyor has installed, which is far more than I've proposed. Somewhere above I've got a link to the packages they have installed. I doubt they would have added them without a good reason...

As said, this is a product strategy decission. AppVeyor not only includes more packages by default, it is also faster to start and run. This is specially so with file-intensive tests. However, jobs in AppVeyor are sequential, while GHA supports parallel execution. Anyway, I don't think this issue is the best place for a product comparison.

MSP-Greg commented 4 years ago

You keep second guessing about how you think things are set up. Please stop.

Prebuilt Ruby versions are available with and without an embedded MSYS2 install. The decision to use the 'packages' with embedded MSYS2 installs was made by GitHub/MSFT/Azure.

jobs in AppVeyor are sequential

I've seen accounts where three jobs spin up. Nothing to do with this discussion.

it is also faster to start and run

I think that's what this is all about. Making it faster for repos that need to use MSYS2 compile tools for their CI.

eine commented 4 years ago

You keep second guessing about how you think things are set up. Please stop.

Sure. Why not move the discussion about Ruby to a better place where all the relevant info/context is properly explained? It is hard to guess possible solutions for an out-of-topic issue which is vaguely described.

Prebuilt Ruby versions are available with and without an embedded MSYS2 install. The decision to use the 'packages' with embedded MSYS2 installs was made by GitHub/MSFT/Azure.

Then, I think it deserves its own issue, which, once again, is independent from this. Actually, this is an additional constraint for your specific use case (see https://github.com/actions/virtual-environments/issues/30#issuecomment-575926148), which is beyond requiring MINGW to be replaced with MSYS2 (see https://github.com/actions/virtual-environments/issues/30#issue-505849504).

Nothing to do with this discussion.

That's the point.

I think that's what this is all about. Making it faster for repos that need to use MSYS2 compile tools for their CI.

Windows jobs on GHA are up to 3.5 times slower than AppVeyor (see https://github.community/t5/GitHub-Actions/Performance-on-Windows/m-p/39195#M3708), regardless of the startup time, which is negligible. It was an example of a vaguely related issue that is better handled separately.

As said, first we need to make it possible to use MSYS2 by default in YAML files, which is not an option ATM. That alone will make it faster for thousands of users, and absolutely all of us agree on that. Any further discussion, although interesting, is just a distraction ATM. Of course, if you have any statistics that prove how convenient it'd be to preinstall specific packages (including HD, RAM, net usage), please, do not hesitate to bring them to the discussion.

MSP-Greg commented 4 years ago

Ruby was mentioned only because of the embedded MSYS2 installs. You then implied that I was mistaken about it, then you implied that it might be an issue with packaging, etc.

I'm was responding accordingly. If four installs were acceptable, one would think that a somewhat larger single install would be better in many ways.

JFYI, building Ruby, the time varies quite a bit on AppVeyor, but the fastest configure/compile takes a bit over 12 minutes, but can be double that. Actions takes a bit longer than AppVeyor at its fastest, but the time is much more consistent.

The fastest total time on AppVeyor is about 34 minutes. At the wrong time of day, I've had some build jobs timeout, and hence, run for 60 minutes without finishing.

eregon commented 4 years ago

@eine This issue is about adding MSYS2 to Windows image (not just a MSYS2 Bash shell). Considering the use of MSYS2 by tools already part of the image seems very relevant to this issue.

eine commented 4 years ago

Ruby was mentioned only because of the embedded MSYS2 installs. You then implied that I was mistaken about it, then you implied that it might be an issue with packaging, etc.

By the same token, I replied about Ruby only to argue that it is a specific use case beyond this issue; hence, it is likely to have many other constraints and implications, which has proven to be true. You have repeatedly asked for a certain list of packages based on your specific use case. It feels that you are ok with installing any packages beyond what you need, but not less than that. That's what I think that is fundamentally mistaken and what I've been to trying to argue.

Overall, it might feel that there is something to be discussed/evaluated for this issue to be taken care of. And there is not. All we need is employees with access to the required sources to modify them.

I'm was responding accordingly. If four installs were acceptable, one would think that a somewhat larger single install would be better in many ways.

Absolutely nothing to argue about it. The message is clear. It is clear in this thread. Also in #234. Also in #229. Repeating it again won't make it louder. However, acknowledging that the fact that Ruby includes unwanted embedded installs of MSYS2 is irrelevant to replacing MINGW with MSYS2 would definitely help us move forward with this issue. Ideally, you would acknowledge that there are multiple other issues that better fit your specific requirements.

AppVeyor: I explicitly said that it is a problem with file-intense tests. Again, nothing to do with this discussion.

This issue is about adding MSYS2 to Windows image (not just a MSYS2 Bash shell).

Unfortunately, it is not. It is precisely about adding just a replacement for the current shell, which provides pacman. See https://github.com/actions/virtual-environments/issues/30#issue-505849504.

Considering the use of MSYS2 by tools already part of the image seems very relevant to this issue.

It is. As said, the message is clear already. Moreover, there are other two specific issues about Ruby and MSYS2 (#234, #229). There are other nine issues about Ruby (#287, #281, #229, #209, #95, #73, #233, #230, #186). All of these are now explicitly linked to this issue. Do you really think it is justified to keep taking over this single issue to discuss the replacement of a single package (MINGW) with another single package (MSYS2)?

MSP-Greg commented 4 years ago

You have repeatedly asked for a certain list of packages based on your specific use case. It feels that you are ok with installing any packages beyond what you need, but not less than that.

You have mentioned having a bash shell. Git does that, MSYS2 does that, etc. Which one is enabled by the default path should be made clear in CI docs, but shouldn't affect what's installed on the system.

I want MSYS2 for compile tools, and I think most other people do also. When the time it takes to install compile tools takes longer than the CI would take on Ubuntu, something should change.

Installing bare MSYS2, initializing it, and updating it takes about a minute. Installing all the above mentioned compile tools (both 32 & 64-bit) takes an additional five minutes.

eine commented 4 years ago

Git is not a shell. MSYS2 provides a shell AND pacman. MINGW provides a shell without pacman. No one is asking for bash shell, which we already have and which is available through WSL too. We are asking for pacman in order to access MSYS2's package repository. Please, carefully read this issue from the begining.

Apart from that:

Absolutely nothing to argue about it. The message is clear. It is clear in this thread. Also in #234. Also in #229. Repeating it again won't make it louder.

EDIT

My workflows need ~30s to setup MSY2, ~75s to install common dependencies and ~75s to install toolchains. That's ~3min. Do you want to discuss how to bring it down to zero too?

dreamer commented 4 years ago

(…) There is not a single MSYS2 environment that can be used by default in the following step:

shell: ????
run: |
  uname -a

Well, as long as MSYS2 is not going to be bundled it won't be fixed. As for now, the following workaround is possible:

  - name: Step name
    shell: python scripts\msys-bash.py {0}
    run: |
      uname -a

msys-bash.py

eine commented 4 years ago

@dreamer, thanks! I am aware of that trick, as I kind of reverse engineered the paths in actions/runner#240. Still, there are some limitations with using an intermediate file (be it *.py, *.cmd or *.sh): numworks/setup-msys2#22.

dreamer commented 4 years ago

@eine please note I don't use the same trick as msys2do - my script is used as shell replacement. I think we use or used && in the past (without issues); using replacement shell solved an issue with using cmd1 "$(cmd2)" in bash for us.

There are other problems around using msys2 bash though, e.g. env variable CHERE_INVOKING needs to be defined for a job otherwise msys2 bash forcefully cd's into home dir (which is super-annoying in CI and would be nice if MSYS2 just stopped doing it). But I guess they could be addressed after MSYS2 is pre-installed on Windows images :).

eine commented 4 years ago

@dreamer, I will have a better look, because I didn't catch up after actions/runner#240 was closed. Nevertheless, I'd say that the following procedures are equivalent:

# From your comment above
  - name: Step name
    shell: python scripts\msys-bash.py {0}
    run: |
      uname -a
# From actions/runner#240
  - name: Step name
    shell: ./msys2.cmd {0}
    run: |
      uname -a

At the same time, msys-bash.py is somehow equivalent to msys2.cmd as defined in actions/runner#240:

    fs.writeFileSync('C:/hostedtoolcache/windows/Python/3.6.8/x64/msys2.cmd', [
      `setlocal`,
      `@echo off`,
      `set "args=%*"`,
      `set "args=%args:\\=/%"`,
      cmd + ` %args%`
    ].join('\r\n'));

Note that this is not the procedure that is explained in the README of setup-msys2. This is discussed in numworks/setup-msys2#8 and numworks/setup-msys2#21.

Summarizing, there are two possible syntaxes that any trick needs to support:

  - shell: TRICK
    run: |
      uname -a
  - run: TRICK uname -a

and other two that are likely not to be possible:

# From numworks/setup-msys2#19
  - run: |
      TRICK uname -a
      TRICK uname -a
  - run: TRICK uname -a && uname -a
# or
  - run: TRICK uname -a && TRICK uname -a

Your approach supports the first use case only. The approach in setup-msys2 supports the second use case only. numworks/setup-msys2#21 is about mimicking your approach (with a different language) so that setup-msys2 supports the first two use cases. By the same token, you could extend you script.

For now, the best approach is for users to write their commands in a shell script and reduce the YAML syntax to executing that single file. Using the YAML syntax for multiline commands works, because that single file is implicitly created by the runner. Hence, I'd say that yours is, although limited, the safest approach ATM.

Still, all these are partial (ugly) fixes for something that can be more easily solved by GitHub. MSYS2 should not be considered a custom shell. And the same YAML syntax that works for other shells should work.

There are other problems around using msys2 bash though, e.g. env variable CHERE_INVOKING needs to be defined for a job otherwise msys2 bash forcefully cd's into home dir (which is super-annoying in CI and would be nice if MSYS2 just stopped doing it).

Alternatively, in setup-msys2 cd $OLDPWD is executed as the first command in the wrapper script. But, yes, I do also find it annoying.

zbeekman commented 4 years ago

This would make tooling with gcc compilers easier on Windows (C, C++, Fortran, etc.)

1480c1 commented 4 years ago

I personally don't think it's necessary to set up msys2 past just installing it to a sane place ( Like the default C:\msys64 for 64-bit msys2) and mentioning it along with the path in the software installed for the virtual environments. Rather, by trying to introduce special shell: just for msys2 bash would only really complicate the situation for people only wanting to compare or replace appveyor (travis-ci currently also does not supply msys2 with their windows images it seems) with testing mingw-w64+msys2 compilation on github actions.

The only thing I could see in that direction would be replacing the git bash shell that is currently being provided by the shell: bash on windows since that also uses a msys2 bash, just not with pacman and the rest of the tooling that people like to use.

eine commented 4 years ago

@dreamer, in the end, I extended my fork of setup-msys2 to support both formats. Anyway, it seems that this issue will be fixed soon: #342.

The only thing I could see in that direction would be replacing the git bash shell that is currently being provided by the shell: bash on windows since that also uses a msys2 bash, just not with pacman and the rest of the tooling that people like to use.

Please, see https://github.com/actions/virtual-environments/pull/342#issuecomment-580969845

AlenaSviridenko commented 4 years ago

PR with added MSYS2 was merged, fix should be available on the next rollout in a week or two.

SlySven commented 4 years ago

Can I lob a stone into this pond and ask what the feelings are as to providing the Qt 5 SDK libraries for both 32 and 64 bits in this environment, i.e. the Mingw-w64 packages called:

I would note that there are also the debug and static versions of the Qt libraries which can be useful in some circumstances but the former are quite large (over 0.5 GByte downloads each) which can take a while to download and install for some cases and may be too much from a cost/benefit viewpoint here:

:question:

The benefit to having a full Qt setup integrated into the MSYS2/Mingw-w64 environment is that it is a very useful configuration for cross-OS C++ F.O.S.S. projects... :smiley:

maxim-lobanov commented 4 years ago

@SlySven , we don't have plans to pre-install these packages for now because of the size (we had an incident with image capacity recently so we have to be very careful about adding new software. But feel free to raise the separate issue to discuss it.

eine commented 3 years ago

@SlySven, you can use eine/setup-msys2 as a workaround, while the windows environment is fixed, stabilized and rolled out with documentation.

Regarding your request for arbitrary packages, I suggest to use caching options to avoid explicitly installing them again and again. That's a possible enhancement to setup-msys2. As discussed above, I think that the base image should have not included any extra package, as it leads to opinionated selection.

@AlenaSviridenko, @maxim-lobanov, is there any PR related to the documentation of #632? It seems that no additional shell is added. As the maintainer of eine/setup-msys2, I'd like to decide whether the Action will be useful to improve UX.

AlenaSviridenko commented 3 years ago

Hi @eine, we are going to update docs with a proper note on a next image deployment, which is approximately next week. But we don't have plans to add MSYS2 to PATH in future.

vadi2 commented 3 years ago

Qt can be installed with https://github.com/jurplel/install-qt-action.

1480c1 commented 3 years ago

As msys2 was added under C:\msys64 now with windows-2019 does this issue still need to stay open?

maxim-lobanov commented 3 years ago

Yep, we have one more opened PR to improve installation stability: #928 . We are planning to close issue after that

1480c1 commented 3 years ago

I see, it's probably best to link those prs and stuff to here so it's more visible without needing to go through the PR page,

MSP-Greg commented 3 years ago

Install script in master Install-Msys2.ps1

andreasdotorg commented 3 years ago

I'm missing pacman in the MSYS2 install on windows-2019. Is that a deliberate omission or an oversight?

1480c1 commented 3 years ago

Where are you looking for pacman?