-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Improve Docker tag component detection and comparison #11679
Improve Docker tag component detection and comparison #11679
Conversation
components = [] | ||
|
||
common_components.each do |component| | ||
components << component if tag_name.match?(/\b#{Regexp.escape(component)}\b/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe that can be changed into?
components << component if tag_name.include?(component)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to use word boundaries to ensure we only match complete component names, not partial substrings. If we have a component like "ruby" and we use include?, it will incorrectly match in tags like "rubygem" as substrings. I don't know if there is going to be a real world scenario where this would happen, but it's a possibility and I want to play it safe to avoid potentially creating issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@robaiken, I’ve added a few suggestions, but overall, this looks good to me! 👍 If you’re considering a feature flag, it could help with a smoother rollout in case any issues arise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Nice idea!
e54450d
to
4692acc
Compare
* Improve Docker tag component detection and comparison * lint * Adding `:docker_tag_component_comparison` feature flag * lint * fixing rubocops catch 22 between explicit and implicit subject * refactoring code
What are you trying to accomplish?
I'm improving how Dependabot selects Docker images for updates by enhancing the tag comparison logic. Currently, we sometimes incorrectly select images with different component patterns - for example, suggesting an update from
image:3.3-apache
toimage:4-apache-alpine
when we should only be matching images with identical components (just "apache" in this case).This refactoring makes tag comparison more intelligent by analyzing patterns in image tags to identify their key components (like OS, packages, etc.) and using those patterns as a basis to filter out images that don't match the original structure. By dynamically identifying these components across all available tags, we can ensure we only suggest updates that maintain the same component structure as the original dependency.
Related issues: #8648, #390
Anything you want to highlight for special attention from reviewers?
I've taken a component-based approach to image selection rather than the previous method of stripping characters. The key strategy involves:
alpine
,apache
,amd64
)apache
doesn't match withapache-alpine
)This approach makes more semantic sense for Docker tags and better respects their internal structure. I've also split the logic into smaller, focused methods for better maintainability. The refactoring preserves all existing functionality while adding more precise tag filtering.
How will you know you've accomplished your goal?
We'll see more accurate image selection during updates, particularly:
When updating from
owasp/modsecurity-crs:3.3-apache-202209221209
we won't incorrectly selectowasp/modsecurity-crs:4-apache-alpine-202502070602
(addingalpine
)Users should experience more predictable and semantically correct Docker dependency updates.
Checklist