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

Generate a rubocop todo #40

Merged
merged 1 commit into from
Oct 18, 2022
Merged

Conversation

hennevogel
Copy link
Member

We don't have a Gemfile.lock and only loosely specify the rubocop version in our gemspec, so we get new rubocop versions in CI all the time...

We don't have a Gemfile.lock and only loosely specify the rubocop
version in our gemspec, so we get new rubocop versions in CI all the
time...
@hennevogel
Copy link
Member Author

See all the other failing PRs before this...

@dmarcoux
Copy link
Contributor

What speaks against pinning a specific version of RuboCop as a development dependency? This would ensure we have a reproducible CI.

@hennevogel
Copy link
Member Author

What speaks against pinning a specific version of RuboCop as a development dependency?

Bitrot? :)

Copy link
Contributor

@dmarcoux dmarcoux left a comment

Choose a reason for hiding this comment

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

After sleeping on it, I think this is at least a step in the right direction. It does mean that we need to regenerate the RuboCop TODOs whenever there's a new RuboCop version.

If we end up pinning RuboCop, we can always do it in another PR.

@dmarcoux dmarcoux merged commit cea1435 into openSUSE:main Oct 18, 2022
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

2 participants