Fix dependency tag filtering to use exact prefix matching

[robaiken]

What are you trying to accomplish?

I am fixing an issue with dependency tag filtering in our release notes finder process. Currently, the system incorrectly identifies releases when unrelated tags contain the package name. I'm changing the tag filtering method from included? to start_with? to ensure more accurate matching.

This change prevents false positives in release identification, ensuring that our automated dependency update process works correctly and doesn't miss important updates or include irrelevant ones.

Anything you want to highlight for special attention from reviewers?

The key change is in the tag filtering logic:

# Old approach
.select { |r| r.tag_name.included?(dep_prefix) }

# New approach
.select { |r| r.tag_name.start_with?(dep_prefix) }

I chose this approach because it provides a more precise match for dependency tags. While using included? was too broad and led to false positives, start_with? ensures we only match tags that explicitly start with the dependency name.

Please pay special attention to the updated test cases, particularly the new fixture file releases_with_mixed_tag_formats.json, which aims to cover the tag naming scenarios.

How will you know you've accomplished your goal?

1. The automated tests pass, particularly the new/updated tests that check for correct tag retention.
2. In real-world scenarios, we see a reduction in incorrectly identified releases.
3. The system correctly identifies releases even when unrelated tags contain the package name elsewhere in the tag.

Checklist

• I have run the complete test suite to ensure all tests and linters pass.
• I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
• I have written clear and descriptive commit messages.
• I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
• I have ensured that the code is well-documented and easy to understand.

[markhallen]

LGTM

[jakecoffman]

Any reason we wouldn't want to use an exact match?

[robaiken]

@jakecoffman It looks like the original intention of this code was to check for a prefix, rather than check the whole string. Although all examples I've seen checking the exact text would work, checking it as a prefix seems to be the safer choice.