Fix keyword arguments in the change nickname event and fixing task

[ahukkanen]

🎩 What? Why?

After merging #8792 the build is broken because it was developed against Ruby 2.7 and meanwhile we merged Ruby 3.

This should fix the keyword argument issues introduced by that PR.

📌 Related Issues

• Related to Fix nicknames uniqueness with different cases #8792

Testing

See the CI green or:

$ cd decidim-core
$ bundle exec rspec spec/events/decidim/change_nickname_event_spec.rb
$ bundle exec rspec spec/tasks/decidim_tasks_fix_nickname_uniqueness_spec.rb

📋 Checklist

• ❓ CONSIDER adding a unit test if your PR resolves an issue.
• ✔️ DO check open PR's to avoid duplicates.
• ✔️ DO keep pull requests small so they can be easily reviewed.
• ✔️ DO build locally before pushing.
• ✔️ DO make sure tests pass.
• ✔️ DO make sure any new changes are documented in docs/.
• ✔️ DO add and modify seeds if necessary.
• ✔️ DO add CHANGELOG upgrade notes if required.
• ✔️ DO add to GraphQL API if there are new public fields.
• ✔️ DO add link to MetaDecidim if it's a new feature.
• ❌AVOID breaking the continuous integration build.
• ❌AVOID making significant changes to the overall architecture.

[andreslucena]

Should we ask for merging with develop, so we can catch this on the PR before merging?

[ahukkanen]

Should we ask for merging with develop, so we can catch this on the PR before merging?

Yep, it was my bad as I didn't realize that. I'm not even sure if there's any easy way to spot that without going to the PR branch and looking at its state, so I wouldn't be surprised if I miss another one (unless you know a good way to spot it?).

[andreslucena]

Yep, it was my bad as I didn't realize that.

No problem, I didn't catch that neither.

I'm not even sure if there's any easy way to spot that without going to the PR branch and looking at its state, so I wouldn't be surprised if I miss another one (unless you know a good way to spot it?).

Other alternatives on the top of my head would involve checking the branch locally, merging with develop and running the specs ourselves. This could be running the full test suite, only for the relevant modules or for the spec files that changed/were introduced; the tradeoff between these options would be between the speed and the confidence that it isn't breaking anything else.

I prefer the merge with develop approach, though, as that sounds cleaner and less brittle.

[andreslucena]

👍🏽

[ahukkanen]

Other alternatives on the top of my head would involve checking the branch locally, merging with develop and running the specs ourselves.

Yes, this is what I do sometimes but its quite tedious to do for all PRs before merging. I was thinking if there is an automated way to spot this but I guess not other than forcing the PR to be in sync with develop before merging. But that would be a major problem for the community contributions that we cannot rebase ourselves.

There is a GH action that would force the PR to be in sync when it is opened/reopened but it wouldn't have prevented this particular situation.