How to Use Danger on GitlabCI for a RoR Project

Written by pinkyone | Published 2023/10/28
Tech Story Tags: coding | ruby-on-rails | gitlab-ci | automated-code-quality-checks | rubocop | why-do-we-need-rubocop | coding-tools | pronto

TLDRCode quality is a cornerstone of successful software development. effective code reviews play a vital role in maintaining it. We often encounter challenges managing outdated comments within our code review process. In this article, I'll share our journey from using Pronto to automating code quality checks using Danger with RuboCop and GitLab CI.via the TL;DR App

Code quality is a cornerstone of successful software development, and effective code reviews play a vital role in maintaining it. However, as we strive to improve our code, we often encounter challenges managing outdated comments within our code review process.

In this article, I'll share our journey from using Pronto to automating code quality checks using Danger with RuboCop and GitLab CI. We'll discuss the limitations of our previous approach, why we transitioned to Danger, and the steps to set up Danger effectively in your GitLab CI pipeline.

Let's dive in!

Before Danger

Our solution used to use Pronto, but Pronto had an issue with removing outdated comments. So, I’ve done some research and decided to move to the Danger.

Let's Start

  1. We need to read the Danger documentation.

  2. Perform the required actions for GilabCI.

  3. Then install danger-rubocop.

  4. Now, we need to create ./Dangerfile with the next content:

github.dismiss_out_of_range_messages

rubocop.lint include_cop_names: true, inline_comment: true, force_exclusion: true

This config will add detailed info about a failed cop and comment. And a little more info about force_exclusion - this option is needed for exclusion files and other things that you muted in your rubocop config.

Let’s Test It

After testing, this solution shows that Danger has a similar issue with removing outdated comments created before fixes. You know, that comments like "UserName changed this line in version X of the diff N time ago."

This is because Danger skips comments with a position. After some research, I’ve found that the value of this key is the position of a comment in a thread (thanks Captain).

So, now this looks better than Pronto. First of all, we can resolve manually outdated comments (you can’t do this with Pronto comments). If you want to remove comments like this forcibly, you can do it by monkey pathing delete_old_comments! and remove this check. But I don’t recommend doing this. On the other side, we can automate resolving these comments.

Just add the monkey patch delete_old_comments! and use

client.resolve_merge_request_discussion(
            ci_source.repo_slug,
            ci_source.pull_request_id,
            raw_comment['discussion_id'],
            resolved: true)

Finally, we have a solution that will clear your MR from outdated rubocop comments, but, you should not use the remove_previous_comments Danger option (this will create a lot of garbage in your MR).

Conclusion

After some hacks, Danger can be used more effectively than Pronto. This solution has been in “production” for a few months, and all my teammates rated it as a better solution than previous.


Written by pinkyone | Ruby on Rails developer.
Published by HackerNoon on 2023/10/28