Use Github Actions for CI

[mlarraz]

Also tests against ruby-head and fixes a failure on it.

The ruby/setup-ruby action doesn't support Ruby 1.9 or 2.0, so dropping those. If support is still necessary, I can explore workarounds.

Sample build: https://github.com/mlarraz/timecop/actions/runs/496778019

[jwillemsen]

Would also recommend to add a .github/dependabot.yml to get automatic pull requests when used github actions or used rubygems are updated, see https://github.com/RemedyIT/ridl/blob/master/.github/dependabot.yml for an example

[joshuacronemeyer]

Hey thanks for the PR! A couple questions:

• do we need to switch to GitHub actions for CI? what is the benefit? Looks like travis supports ruby head so we could just add it there. I'm open to switching but would appreciate detailed discussion (because i don't know a lot about these products) and a separate PR just for this.

• what is that ruby2_keywords method you call? Is it from that gem? timecop doesn't have any dependencies and that is a nice feature we want to keep. Maybe you could teset this PR for us on your codebase Better: Add ruby 3.1 compatibility. #279

[jwillemsen]

In my experience the integration between github and actions is much better as travis, it is faster, more platforms, more parallel workers speeding up things, and as last, actions are used more and more

[jwillemsen]

See https://github.com/ruby/setup-ruby for the ruby versions that can be used on actions

[ylecuyer]

• do we need to switch to GitHub actions for CI? what is the benefit? Looks like travis supports ruby head so we could just add it there. I'm open to switching but would appreciate detailed discussion (because i don't know a lot about these products) and a separate PR just for this.

@joshuacronemeyer travis has been aquired last year and shut down travis.org (the free offer for opensource) now repos have been migrated to travis-ci.com, opensource projects have to ask for free credit to keep the build running. So the main pros for github action is that you won't have to ask for the free credits

[mlarraz]

* what is that ruby2_keywords method you call? Is it from that gem? timecop doesn't have any dependencies and that is a nice feature we want to keep. Maybe you could teset this PR for us on your codebase #279

This is a new method added in Ruby 2.7. It's designed to patch old code to handle the new keyword argument changes in Ruby 3.0. This will no-op on older versions. This is needed due to the method signature of Time.new changing in Ruby 3.1.

I've already monkeypatched this in a library to fix the specs on Ruby 3.1: https://github.com/instacart/makara/blob/9b34fee85d6a80c9c9f9778a6a6691e28e190b44/spec/spec_helper.rb#L22-L27

Edit: Full details of the Ruby change here

[joshuacronemeyer]

@mlarraz can you please split this into 2 PRs? I'm enabling ruby-head on our travis build so we can focus on getting the ruby 3.1 support, but I'm also interested in changing our CI over. My travis builds yesterday were taking 30 minutes, so if we could speed up our build with GitHub actions that would be great. I just want to treat these things as separate issues.

[mlarraz]

@mlarraz can you please split this into 2 PRs? I'm enabling ruby-head on our travis build so we can focus on getting the ruby 3.1 support, but I'm also interested in changing our CI over. My travis builds yesterday were taking 30 minutes, so if we could speed up our build with GitHub actions that would be great. I just want to treat these things as separate issues.

Done

[mlarraz]

https://github.com/mlarraz/timecop/runs/1857555803

[joshuacronemeyer]

@mlarraz thanks. Can you also bring back your ruby 3.1 fix as a separate PR? There is another PR, but it has a problem so I don't mind having another.

[mlarraz]

@mlarraz thanks. Can you also bring back your ruby 3.1 fix as a separate PR? There is another PR, but it has a problem so I don't mind having another.

Sure, but can you merge this as is? Should not be blocked by anything I think

[mlarraz]

FYI #288

[joshuacronemeyer]

I'm a bit paranoid that i'll need to do something in the GitHub settings for this repo that I don't have permission to do... and since this also deletes our travis stuff then we'll be without a build. I'd prefer to do a release to get stuff working for ruby-head folks and then we can fool around with the build and dependabot.

[mlarraz]

Got it, I just added back the .travis.yml. Can be removed in a later PR once Github Actions is vetted

[jwillemsen]

There are no special permissions needed to use github actions, at the moment you merge this PR the actions automatically run