adding gh workflows os specific installation

[rcmlz]

I needed to know if users can (currently) install this module in Linux, MacOS and Windows. Maybe other users like to know that as well.

[ugexe]

I’m a bit confused. There is appveyor and circle ci tests covering all OS. Additionally, those CI are using a much more thorough set of tests, whereas this just seems to try and install zef. What benefit does this PR have over the existing workflow?

[ugexe]

Note I also have a gh-actions branch that tests the same things as existing CI tests, but there is something about the gh-action runner itself that doesn’t work well with it.

[rcmlz]

The main point of this PR is to make transparent to potential users of zef whether zef can be installed on the OS under consideration using 'raku -I. bin/zef install .' - as the documentation suggests. It is not ment to be testing from the developers point of view. I do not have a WIndows system to test on, still need to know if a package (currently) installs on windows. Forking and doing it on my own github account is ok, but a waste of time (for potential users having the same question).

Having these three .yml allows to display OS specific badges. So it is clear on first view. The schedule allows keeping an eye on "rotting repos" - sometimes also dependencies break.

PS1: zef/ is not a rotting repository, however, it serves as a role model as it has much focus.

PS2: Your current test.yml in your gh workflow branch is not working because you use wrong path separators for windows e.g. "bin/zef" instead of "bin\zef". Same for xt/repository.rakutest. If you set the path separator dynamically, depending on the OS running, then it works (in my tests). Also TMPDIR: /tmp will not work for windows, for the same reason. maybe TMPDIR: ${{ github.workspace }}tmp - using absolute paths, is better.

[ugexe]

The main point of this PR is to make transparent to potential users of zef whether zef can be installed on the OS under consideration using 'raku -I. bin/zef install .' - as the documentation suggests.

There is a green checkmark shown on the main repository page. If you click the green check mark you will see circle-ci and appveyor checkmarks. Appveyor is windows, circle-ci is macos and linux. And those tests do far more than just test if zef can install itself, and that is important because zef uses external tools that vary across platforms (for example using curl or wget to fetch distributions, something just installing itself wouldn't exercise, but the existing appveyor CI tests set up a test for). Since we also won't merge commits that break any given OS, it is a bit redundant to need badges for each OS. We used to show separate badges for each OS years ago, but there wasn't much point once it had worked on all OS for years and years.

PS2: Your current test.yml in your gh workflow branch is not working because you use wrong path separators for windows e.g. "bin/zef" instead of "bin\zef". Same for xt/repository.rakutest. If you set the path separator dynamically, depending on the OS running, then it works (in my tests). Also TMPDIR: /tmp will not work for windows, for the same reason. maybe TMPDIR: ${{ github.workspace }}tmp - using absolute paths, is better.

But this isn't true. That gh action doesn't work due to some weird combination of rakudo precompilation and the limited resources of the gh action runner. If I rerun my own gh action workflow enough times it will eventually pass, which would disprove any notion of the slash being the issue. 😕

[rcmlz]

OK