Use GitHub Actions for CI testing #178
Conversation
Trying to get GitHub Actions going for the project.
Missed a closing quote.
Using SimpleCov directly and telling Coveralls after the fact, rather than using COveralls directly.
|
@sds Unfortunately, I am having a case of "Doesn't work on my machine" and am unable to really investigate the test failures. :/ |
Adding the CHILDPROCESS_UNSET and CHILDPROCESS_POSIX_SPAWN permutations to the build matrix.
Adding the non-Ruby rubies that we test against into the build matrix.
Including the value of POSIX_SPAWN to the set name so that code coverage results remain uniquely named for each permutation of the build matrix.
GitHub Actions don't seem to support it.
Trying out different versions.
Not testing JRuby on Windows for the time being.
Accidentally messed up the nesting level of something.
Got it this time.
|
@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. |
Added a manual trigger and a monthly trigger.
|
FYI, anyone who was fiddling with this branch too: I'm going to have to rebase this branch and get the commits cleaned up. |
This reverts commit b506920.
Scratch that. Now that |
|
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 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 |
| ruby-version: ['2.4', '2.5', '2.6', '2.7', '3.0', jruby-9.2] | ||
| posix_spawn: [true, false] | ||
| exclude: | ||
| # The action used seems to not fully support JRuby on Windows |
There was a problem hiding this comment.
What's the issue? The seems to imply it's an issue of ruby/setup-ruby, but I don't know of any.
There was a problem hiding this comment.
I think that that build combination just hung forever trying to even start up. No getting to the tests and failing just a lot of "why is this job still spinning and having no output after over an hour?". Although, now that I go back and look at the cancelled build in order to link it, it now has output. Still took me killing the process for that to happen, though.
https://github.com/enkessler/childprocess/runs/2755087269?check_suite_focus=true
There was a problem hiding this comment.
That seems a bug of GitHub Actions then, nothing to with ruby/setup-ruby (which I guess is meant by The action).
There was a problem hiding this comment.
A bit odd that a GitHub Action bug would only appear for JRuby but not for the other flavors, given that they all use the same underlying action. That could be the case, though.
Regardless, I just chucked it into the "stuff that I'm not going to worry about right now" bucket because there was no obvious reason for it to not work, that action not necessarily working for JRuby+Windows is a known issue, and not having JRuby + Windows build combination wasn't any worse than our current CI situation. If you want to try throwing JRuby back into the mix and seeing what happens, feel free to do so.
There was a problem hiding this comment.
Yeah, it's probably fine to ignore for now.
What I meant as a ruby/setup-ruby maintainer is I believe this issue has nothing to do with ruby/setup-ruby.
I guess it's either a bug of JRuby on Windows (e.g., the issue you linked), or of GitHub Actions.
There was a problem hiding this comment.
Oh. In that case, yeah, you'd have a better idea than most what the problem might be. ;)
Hello famous person. waves
|
Tests were converted to GitHub Actions in #175. Can we remove the required Appveyor check when you get a chance, @enkessler? |
|
@sds Sure, I can dust off the ol' keyboard contribute. |
|
@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! |
|
Done |
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