-
-
Notifications
You must be signed in to change notification settings - Fork 95
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
Fix frozen string literal issue for ruby 3.4 #300
Conversation
|
Thanks for your continued efforts here.
|
@@ -12,5 +12,21 @@ permissions: | |||
contents: read | |||
|
|||
jobs: | |||
Shared: | |||
uses: fog/.github/.github/workflows/[email protected] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Once this has settled, I think we'll want to go back to the shared action probably, so just noting that here so I don't forget.
Looks good so far, just let me know when you need me to take another look. |
I was about submitting PR to drop the base64 and found it here (would be nice if it was independent PR IMHO). And I just wanted to point out that while fog-core does not use |
@chaadow I'm forgetting now exactly where we left this (sorry). Is this where you wanted it to be, or was there still some work in progress? Just trying to figure out who should be waiting for whom since I can't quite remember. Thanks again for the help! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewing this change, it looks good to me. The only thing I can't answer is on the CI side.
The difference is that it passes RUBYOPT="--enable-frozen-string-literal"
which the shared flow doesn't. There's a bit of a chicken-and-egg situation, though head
is currently allowed to fail. So you could submit the change already. head
is broken anyway (as can be seen in fog-libvirt
) so it probably wouldn't get worse.
Other than that, it doesn't trigger CI. That is because it uses a schedule in the same job, so it gets deactivated if there's no change for 60 days.
Looks like it's enabled again so I'd at least advise rebasing it.
@ekohl thanks for taking another look. I rebased and force pushed, which did in fact trigger CI, which passed. So I think we are (hopefully) in good shape now. I'll bring this in, just let me know if you'd like to work on any of the other libraries on related things, otherwise I suspect someone will get to it in time (and/or the upcoming Rubies will force the point early next year probably). |
@geemus Hey, sorry i was on vacation, thanks for merging. I will take a look on the other related PRs that I've opened this weekend probably. Thanks again for your time! |
@geemus Related to fog/fog-aws#711