-
Notifications
You must be signed in to change notification settings - Fork 9
Migrate to GitHub Actions. #10
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
Conversation
|
@apotonick friendly ping, new CI setup is one merge away :) |
|
@apotonick do you think there will be time to take a look? All changes in tests are 1:1, just testing the structure, not textual representation (which vary across Rubies). |
|
Hi @simi, thanks again! Could you rebase your PR and just add the CI setup? We have a utility method in |
|
@apotonick I swear this is the last PR from my side. I'll work on disconnecting uber + declarative from active usage after. :) I'm happy to migrate tests to that util also. Should I copy it here or make those utils dev dependency? |
|
Haha, you can send as many PRs as you want 😂 We have the Which gem are you thinking about liberating from |
|
@apotonick my current chain of fear is google-apis-core -> representable -> |
|
Ah, ok, we can make |
I'm happy to jump there also. Nothing huge is needed, just ensure gem has stable CI and it passes no modern Rubies. Also quick check on issues there is nothing serious reported. I can contribute all this if anyone is around to review and merge 😉. |
|
Is TRB still active thing? |
|
@apotonick the mentioned helper blew my mind, it doesn't support all usecases like nested hashes. See example: # original
_(schema.get("id").inspect).must_equal '#<Declarative::Definitions::Definition: @options={:name=>"id"}>'
# passing with helper, see options had to be changed anyway
_(Trailblazer::Core::Utils.inspect(schema.get("id"))).must_equal '#<Declarative::Definitions::Definition: @options={name: "id"}>'Wouldn't be possible to merge this version where no helper is needed actually? Or do you need to support ancient Rubies? PS: To answer your original question. I was clicking around, got to the https://trailblazer.to/2.1/pro#future-insights page with interesting future insight. 😸 |
|
@simi We try to support older Rubies as Trailblazer and all its gems are focusing on refactoring, we had a bunch of users who were really grateful they could use our stuff to upgrade to newer Ruby. I will update the helper. Yes, the TRB page is new, but some pages are still waiting to be "released" - coming soon. <insert construction worker animated GIF here, saying "this page is still under construction"> |
|
Could you remove the changed tests from your PR and only give me the updated CI, please? |
|
@apotonick done |
|
Thanks! 💚 let's see what CI says. |
|
@apotonick thanks a lot for your time and patience, ping me if there's anything I can help 🤝 |
|
Next move: removing |
If you agree on, I can try. |
|
It will be a bit tricky as we should replace it with |



Hello, I'm trying to upgrade gem to get stable CI. I have updated tests to be Ruby agnostic and I have migrated to GitHub Actions. I have included only supported Rubies for now to CI.
CI can be seen in action at RubyElders#1. Not sure why it doesn't start in here. Maybe needs to enable first. Happy to help setting up this. This gem was identified as one of the crucial for whole RubyGems.org ecosystem and would be nice to get stable CI setup.
PS: I understand this gem is not developed anymore and I'll do my best to update popular reverse dependencies to remove the need of this gem. But meanwhile, it will be appreciated to at least test current version on CI to ensure it works with current Rubies.