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

Run 3.4 build with frozen string mutation detection #3104

Closed
wants to merge 1 commit into from

Conversation

pirj
Copy link
Member

@pirj pirj commented Aug 7, 2024

@pirj pirj self-assigned this Aug 7, 2024
@pirj pirj requested review from JonRowe and removed request for JonRowe August 7, 2024 17:04
if is_ruby_34_plus; then
export RUBYOPT="$RUBYOPT -W:deprecated"
export RUBYOPT="$RUBYOPT --enable=frozen-string-literal --debug=frozen-string-literal"
fi
Copy link
Member

Choose a reason for hiding this comment

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

I think this needs to be applied only to our specs

Copy link
Member Author

Choose a reason for hiding this comment

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

It’s the purpose to apply to everything:

This is going to be a community effort 💪.

To help in this transition, you can enable warnings in CI and note which gems issue warnings. Then, report them to the gem maintainers.

Copy link
Member

@JonRowe JonRowe Aug 19, 2024

Choose a reason for hiding this comment

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

Our CI should not be failing because other gems raise warnings, in particular I think this is why the yard check is failing.

I'm basicalling proposing we do the equivalent of:

RUBYOPT="$RUBYOPT -W:deprecated --enable=frozen-string-literal --debug=frozen-string-literal" rspec ...

So that its only running RSpec that flags issues

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, the intention wasn’t to fail our 3.4 build job when any of the (including development) dependencies mistakenly introduces a string literal mutation. But rather have such a build job as optional. If we’d observe a red one, that would tell us to check if it’s coming from the PR changes or from dependencies.
But it wouldn’t prevent from merging if it’s not our code.
For that reason, I planned to add two 3.4 build jobs, one with this check, and one conventional, required one.

A justification for this is to help the ecosystem.
We can probably even add this build yo main only and skip for PRs.

Copy link
Member

@JonRowe JonRowe Aug 19, 2024

Choose a reason for hiding this comment

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

I want all checks on our repos to pass because my experience is that having a failing build, even just ruby-head, becomes to easy to ignore when there are actual failures "oh it always fails so its fine syndrome".

If you want to have something that looks for warnings in the wider ecosystem, I'd recommend setting something up with a cron action in your own repo away from rspec, we don't actually use a lot of the ecosystem especially given our pinning of gems to older versions

@pirj
Copy link
Member Author

pirj commented Aug 19, 2024

I can’t recall why I decided to put this PR off for now, most probably Ruby 3.4 failures I didn’t want to deal with until it’s almost released.

@JonRowe
Copy link
Member

JonRowe commented Aug 19, 2024

I'm going to close this for now, at some point I would like us to ensure that all our code is compatible with these flags, but hopefully the monorepo will be done before Ruby 3.4

@JonRowe JonRowe closed this Aug 19, 2024
@pirj pirj deleted the detect-frozen-string-mutation branch August 19, 2024 20:05
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.

2 participants