Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add test CI flow for various Rubys on Github actions #908

Merged

Conversation

wildmaples
Copy link
Contributor

Change

Travis CI has been down for a while now and we'd like to switch to Github Actions. This change introduces a new CI build on Github Actions that runs tests on Ruby implementations and also mark some Ruby failing implementations as experimental so the build still passes.

It does not contain all the requirements from the previous Travis CI yet, but it's a good start.

Currently, tests pass on these Ruby implementations:

  • 2.7, jruby, jruby-head, truffleruby-head

These Ruby implementations are marked experimental as they are failing:

  • head (ruby-head), truffleruby

Missing Functionalities

There are some functionalities that exist in the previous CI (travis CI) that is missing from this change.

  • Specifying jdk for JRuby implementations
  • Running order of Ruby implementations based on importance/relevance
  • YARD uptodate in docs (rake yard:master:uptodate)
  • Running tests on Rubinius (currently, ruby/setup-ruby does not support Rubinius)

Questions

Would this change still be useful?

The truffleruby-head is a flaky build, it passes sometimes but fails most. Should we mark it experimental (so the build will still be green if it fails)?

Travis CI has been down for a while now and we'd like to switch
to Github Actions. This change introduces a new CI build on Github
Actions that runs tests on Ruby implementations and also mark
some Ruby failing implementations as experimental so the build
still passes.

It does not contain all the requirements from the previous Travis
CI yet, but it's a good start.
@chrisseaton chrisseaton self-assigned this May 6, 2021
@chrisseaton chrisseaton self-requested a review May 6, 2021 14:29
Copy link
Member

@chrisseaton chrisseaton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks - we should indeed probably be switching to Actions and this is a good first step. It will need some iteration over time but we can do that from this start.

@chrisseaton chrisseaton merged commit 9b4269e into ruby-concurrency:master May 6, 2021
bundler-cache: true # runs 'bundle install' and caches installed gems automatically
- name: Run tests
run: |
gem install bundler --version 1.17.3

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don’t know that gem install bundler achieves anything really (other than making CI slower). Per the ruby/setup-ruby docs:

Note that any step doing bundle install (for the root Gemfile) or gem install bundler can be removed with bundler-cache: true.

At this point the gems have already been installed so it doesn’t really matter what version of Bundler we then install.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes it's probably good to copy what Travis did first and then simplify and refine.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps more helpfully: the right way to control the Bundler version is to provide a bundler: input to the ruby/setup-ruby action.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed, it's counter-productive to install bundler here, and will probably be more confusing than helpful.
Also Bundler 1 is basically not really supported on Ruby 2.7+ (no longer maintained AFAIK).

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

=> #916

@pitr-ch
Copy link
Member

pitr-ch commented Jun 4, 2021

Thank you for the migration!
I am not yet familiar with Github actions so I cannot help with it at the moment, though.
I've also tried to request credits for OSS on travis-ci.com, we'll see if they grant us some allowing to stay c-r on travis avoiding the migration.

@pitr-ch
Copy link
Member

pitr-ch commented Jun 5, 2021

The old CI runs in travis.com with granted OSS credits for now. Let me know if you run into problems.

@pitr-ch
Copy link
Member

pitr-ch commented Jun 5, 2021

To clarify, If you would like to set up the Github actions based CI to fully replace the Travis based CI I will be for it. However, I won't be able to help with the migration at the moment. Migrating to Travis.com with granted OSS credits was a simple and pragmatic thing to do at the moment to keep the CI running as is even after travis.org shutdown until everything is ready on GH-actions. Thanks again for working on the migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants