enkessler
Use GitHub Actions for CI testing
Since Travis CI seems to be going the way of the dodo and having multiple CI services (i.e. needing both Travis and AppVeyor) can be a hassle, I figured that now was a good time to try and switch over to GitHub Actions because it can do everything all in one place.
TODO
- [x] Expand the test matrix to include the various ENV permutations used in the current CI testing
- [x] Add JRuby or any other flavors/versions in addition to the base Ruby set
- [ ] Get the Windows portion passing
- [ ] Remove config file for unused CI services
- [ ] Travis CI
- [ ] AppVeyor
- [ ] Get the tests passing on Ruby 3 (optional, see https://github.com/enkessler/childprocess/issues/173)
@sds Unfortunately, I am having a case of "Doesn't work on my machine" and am unable to really investigate the test failures. :/
@sds Well, it's better but still not quite there yet. Rubinius is right out and JRuby doesn't work on Windows but, in the old CI configurations, Rubinius was already allowed to fail JRuby wasn't being tested on Windows anyway. We weren't testing against Ruby 3 before, so even having it at all is an improvement but it would be nice if the remaining Ruby 3 fails could be fixed too.
FYI, anyone who was fiddling with this branch too: I'm going to have to rebase this branch and get the commits cleaned up.
FYI, anyone who was fiddling with this branch too: I'm going to have to rebase this branch and get the commits cleaned up.
Scratch that. Now that dev and master have synced up again, my extra merges don't make any difference anymore and so no cleaning is needed.
fwiw @enkessler, was trying to work around similar CI failures for our own work (relevant ticket in puppetlabs/pdk#1083) and then doing some further local investigation today, I found that the issue is when running in a remote session - GHA runs in a remote context on Windows where Appveyor does not (which is, as best I can tell, why your appveyor tests continue to pass while windows all blows up). In our testing, when we stopped setting process.leader = true we were able to get things working again.
That doesn't seem ideal but does imply there's something about the Win32 API for processes in a remote context that works differently from local, I haven't been able to run down exactly what's going on myself. Ideally processes with leader set to true would work in remote sessions, ofc, but this might be a separate bug to raise (or just end up as a known limitation?).
Tests were converted to GitHub Actions in #175. Can we remove the required Appveyor check when you get a chance, @enkessler?
@sds So, I'm not seeing the config files for AppVeyor around in the repo anymore and I see that the old CI badges have already been removed from the README in #194. I think that the only thing left to do is to delete the project in AppVeyor itself and remove the webhooks from this repository. I can go ahead an kill the webhooks so that builds don't keep triggering ove there. Do you want me to delete the project in AppVeyor now or do you want to hang on to it for a little bit in case we need to look at an old build for something?
Edit: I went ahead and removed the old TravisCI webhook as well.
@enkessler I'm fine with just removing the AppVeyor webhooks for now if that's possible. Would be nice to keep the project around so links to builds still work for now. If that sounds good to you, go for it!