Dangermattic Setup

[iangmaia]

What does it do?

Setting up the use of Dangermattic checks in the project, in addition to the already existing Danger setup. As Ruby 3 is a pre-requisite, this PR should be merged after #517.

These are the checks implemented:

• Fail if Gemfile.lock version is different than version.rb (already existing)
• Warn if CHANGELOG.MD hasn't been changed (already existing)
• Rubocop via Danger
• Gemfile / Gemfile.lock modified together check
• Labels check
• Diff size check
• Milestone due date check
• No reviewers check

How to test

You should see a comment stating the warnings / errors present in this PR. As a test, I've also added a "do not merge" label so that Danger also issues an error, and that error should also be reported on CI.

To run Danger yourself:

1. Checkout this branch
2. Run bundle install
3. Run:

DANGER_GITHUB_API_TOKEN=<github_token> bundle exec danger pr <PR_URL>

You should get in the console the same errors / warnings reported in this PR.

Checklist before requesting a review

• Run bundle exec rubocop to test for code style violations and recommendations
• Add Unit Tests (aka specs/*_spec.rb) if applicable
• Run bundle exec rspec to run the whole test suite and ensure all your tests pass
• Make sure you added an entry in the CHANGELOG.md file to describe your changes under the appropriate existing ### subsection of the existing ## Trunk section.
• If applicable, add an entry in the MIGRATION.md file to describe how the changes will affect the migration from the previous major version and what the clients will need to change and consider.

[dangermattic]

	2 Warnings
⚠️	Please add an entry in the CHANGELOG.md file to describe the changes made by this PR
⚠️	PR is not assigned to a milestone.

Generated by 🚫 Danger

[AliSoftware]

❓ Does this still make sense given that we have check_gemfile_lock_updated? In other words, if bundle install ends up changing the Gemfile.lock for some reason(†), wouldn't check_gemfile_lock_updated already error and fail at that point, meaning that we'll only get to that point if Gemfile.lock has not been modified by bundle install in the first place?

(†) Though maybe there are cases where the Gemfile.lock would be modified by bundle install that are not related to it not being up-to-date with Gemfile, but for other reasons… I'm especially thinking about the potential addition of a PLATFORMS entry…? 🤔

[iangmaia]

Does this still make sense given that we have check_gemfile_lock_updated?

My first thought was: this won't hurt, so I just kept it. But at the same time, that being the case, it is also noise, so looking at it again, I'm now thinking of removing it 🤔

I'm especially thinking about the potential addition of a PLATFORMS entry…?

Good point, I think this can happen.

[AliSoftware]

💭 I think the reason this was initially added under the from 10.0.0to11.0.0` section is that we maybe considered that the Ruby version bump would be a breaking change?

I mean, technically it is, because by definition a breaking change is when the new version of a dependency will require you to make (breaking) changes to your project before being able to adopt it. And indeed, updating the release-toolkit in your client projects will require you to update your projects to Ruby 3 (or ensure they've migrated already, while before the Ruby version requirement was lower).

It's always an open debate if things like that (Ruby version, or thinks like the Swift Version or target_deployment_version bumps for iOS pods, etc) should be taken into account when considering breaking changes and the need for a major version bumps.

So I'm open to the other POV of this not being considered a breaking change, especially since we are the sole users of this lib (I don't think anyone outside a8c uses release-toolkit 😛 ) and we know that all our clients of that lib (all our apps projects) have migrated to Ruby 3 (except maybe Simplenote… yet, due to its maintenance mode?), we just need to all agree on our stance on this.

[iangmaia]

💭 I think the reason this was initially added under the from 10.0.0to11.0.0` section is that we maybe considered that the Ruby version bump would be a breaking change?

I actually see it as a breaking change (as, for example, it will break a Gem import if you're on Ruby 2.x), but in this case this move was a mistake from my side as I just added the 11.0.0 entry but didn't realize we're still on 9.x, going to 10.0.0 on the next release.

[AliSoftware]

Asked the team for their thoughts about it being considered breaking or not in our team channel, btw
p1707414498911939-C02KLTL3MKM-slack