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

Enable GitHub Actions with updated Rubocop and Danger #2143

Merged
merged 1 commit into from Dec 29, 2020

Conversation

anakinj
Copy link
Contributor

@anakinj anakinj commented Dec 26, 2020

Did this migration for the ruby-jwt gem a few weeks back and it has been great. The speed compared to Travis CI is super and having a CI run on forks really give you the chance to polish everything before opening a PR.

Took the liberty of trying to improve the developer experience for this gem also. Unfortunately this was not that straightforward and noticed some issues in the process.

What was done:

  • GitHub actions for all the gemfile+ruby combinations that were present in the travis.yml
  • Updated to use the latest from the 2.7 branch instead of the pinned 2.7.1
  • Dropped rbx-3 test (Did not see any value in investigating how to get that working for the Actions)
  • Re-enabled RuboCop on CI. It has not been running since Add Truffleruby head to CI #2099 was merged!!!
  • For some reason RuboCop was having issues running locally and in the actions so just updated the gem to the latest version to fix those issues.
  • A lot of exceptions were added to .rubocop_todo.yml due to the update and because it had been disabled on CI for a few months.
  • The Danger related components were updated to a version that supports the Actions
  • Needed to disable one test related to XML generation. I suspect the TravisCI setup had some extra dependencies that made it work.

Still think this needs a little tuning related to the Coveralls integration, some secrets needs to be added to the repository secrets and maybe some ENV variables for the action that is in charge of pushing the results to Coveralls.

@grape-bot
Copy link

grape-bot commented Dec 26, 2020

1 Message
📖 We really appreciate pull requests that demonstrate issues, even without a fix. That said, the next step is to try and fix the failing tests!

Generated by 🚫 Danger

@anakinj
Copy link
Contributor Author

anakinj commented Dec 26, 2020

Tried this out on my own fork if you're interested in how it looks:

anakinj#1

@LeFnord
Copy link
Member

LeFnord commented Dec 26, 2020

IMHO, I'm not a big fan moving all to GH (Microsoft) and see no reason to do it.

Travis is supporting OSS since years, then Microsoft see it as evil, maybe you remember,
so why should it be moved now? And possible destroying other companies and make M$ even richer?

@anakinj
Copy link
Contributor Author

anakinj commented Dec 26, 2020

I think since TravisCI got bought the support for OSS projects has not been that good. Just looking at the queues for OSS CI jobs does not look that good.

Waiting 5 hours to get feedback on your changes is not really motivating.

@anakinj
Copy link
Contributor Author

anakinj commented Dec 26, 2020

Also travis-ci.org is getting deprecated to be replaced with travis-ci.com. Think this is happening when the year changes. The new travis-ci.com is supporting OSS but only some thousand minutes of CI time a month for free, this is what is happening.

I don't think Idera is any better than M$ when it comes to money and many OSS projects will have CI that is not responding in the beginning of 2021.

Copy link
Member

@dblock dblock left a comment

Choose a reason for hiding this comment

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

I'd like to merge this because builds are taking forever on Travis-CI these days, GH actions are blazing fast, have better UX, etc. We can always go back if needed in some future. Right now a bunch of other projects I am involved with are moving for the reasons @anakinj has outlined above.

Can we also please delete .travis.yml in the same CR, and make sure the badges are updated?

Good catch on Rubocop, thank you.

it 'array' do
# Temporary skipped
# XML generation for an array behaves differently when Rails (or something else) is loaded
xit 'array' do
Copy link
Member

Choose a reason for hiding this comment

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

We should fix this. How differently?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I will try to figure out what causes this change in behaviour. Probably some 3rd party dependency when RuboCop and friends got updated.

Copy link
Contributor Author

@anakinj anakinj Dec 28, 2020

Choose a reason for hiding this comment

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

I think i've figured it out. The problem is that grape is not directly requiring active_support/core_ext/array/conversions that adds the Array#to_xml method. It has worked out of luck because activesupport internally loads the file when active_support/time is loaded.

Now the latest 6.1 version of activesupport changes this internal loading, more precisely rails/rails@12959de#diff-f805b1a36e26831e5eee78fb55549de44fb842f78443b178d5d5438105152017

I will revert this change and fix the issue in a separate PR

@anakinj
Copy link
Contributor Author

anakinj commented Dec 28, 2020

I will continue on this a little later today.

@anakinj
Copy link
Contributor Author

anakinj commented Dec 28, 2020

Did what was suggested:

Related to Coveralls something needs to be done to get the token in use for the workflow. Added to the repository and somehow passed as a env variable to the action.

@anakinj
Copy link
Contributor Author

anakinj commented Dec 28, 2020

If seen valuable we could add a daily build for the master branch to ensure the compatibility with 3rd party dependencies.

When working on a gem you tend to have a local Gemfile.lock from whenever you did the initial bundle install and then when CI fails you immediately start blaming the changes you did even if the issue could be in the differences in dependencies.

@dblock
Copy link
Member

dblock commented Dec 29, 2020

If seen valuable we could add a daily build for the master branch to ensure the compatibility with 3rd party dependencies.

When working on a gem you tend to have a local Gemfile.lock from whenever you did the initial bundle install and then when CI fails you immediately start blaming the changes you did even if the issue could be in the differences in dependencies.

Let's do that separately, feature creep ;)

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.

None yet

4 participants