RFC: The number of compatibilities that show up in "checking" status is way too high

[etagwerker]

Context

When I submit a Gemfile.lock or a gem, the system takes a considerable amount of time checking for compatibility with every single Rails release.

I'd like to know why this is happening.

Open Questions

• Do we need to add more resources to our Heroku account?
• Do we need to improve the way that our strategies are executed?
• Are there speedier strategies that could be attempted before GitHub Actions CI? (See RFC: Integration with next_rails gem?  #111)
• Are compatibility checks "getting stuck" in production?

Feedback

If you have any ideas or comments, please post them as a comment. Thanks in advance! 🙏🏼

[mateusdeap]

So, I was actually speaking to @arielj about this and actually am of the opinion that integrating with next_rails might be a good idea.

If we provide a lockfile, the app initially just shows us the compatibility with what seems to be the 2 last versions it has in it's database? Not sure. But I think that if we integrated with next_rails we could have this main flow show the compatibility for the next version of rails besides the current one in the lockfile. It will likely be way more useful to users and quicker.

We can then resort to CI actions for versions of rails farther away since that's when usually we get a lot of false positives due to improper gemspec files.

[etagwerker]

@mateusdeap @arielj That'd be great to see. I submitted this issue a while ago: #111

If you want to add it as another strategy (before using the checker project) that would be very helpful.