childprocess
childprocess copied to clipboard
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?).
