relax major version match regex in find_related_easyconfigs using for --review-pr

[migueldiascosta]

motivated by discussion on slack where eb --review-pr 19271 is showing only a very old related easyconfig, because it's the only one that has a .patch (as in major.minor.patch) version component

[smoors]

for maximum flexibility it would be nice if we could somehow tell EB: "please don't filter any versions, i will do the filtering with --review-pr-filter".

[smoors]

why not just like this:

Suggested change

	version_patterns.append(r'%s\.[\d-]+(\.\w+)*' % parsed_version[0]) # major version match
	version_patterns.append(r'%s\.\w+' % parsed_version[0]) # major version match

[migueldiascosta]

@smoors this makes test_find_related_easyconfigs fail, at least as it is now, because it also matches easyconfigs with different toolchains and versionsuffixes (note that these version_patterns are only part of the actual regex, the toolchain and versionsuffixes patterns are inserted in the next block)

to be clear, although my suggestion doesn't make the tests fail, I'm also not sure if it won't change the behaviour in some unintended way, which is way I marked the PR as draft :)

[migueldiascosta]

for maximum flexibility it would be nice if we could somehow tell EB: "please don't filter any versions, i will do the filtering with --review-pr-filter".

I suppose we can do that, it should be just a matter of passing filter_ecs when calling find_related_easyconfigs from review_pr and when it's not None use only that to filter the potential_paths

[migueldiascosta]

for maximum flexibility it would be nice if we could somehow tell EB: "please don't filter any versions, i will do the filtering with --review-pr-filter".

I suppose we can do that, it should be just a matter of passing filter_ecs when calling find_related_easyconfigs from review_pr and when it's not None use only that to filter the potential_paths

@smoors indeed, it's trivial to do, but note that when a PR includes many easyconfigs, we would be replacing eb's filtering per easyconfig with a filter that is the same for all easyconfigs in the PR, it may end up being counterproductive...

[smoors]

@smoors indeed, it's trivial to do, but note that when a PR includes many easyconfigs, we would be replacing eb's filtering per easyconfig with a filter that is the same for all easyconfigs in the PR, it may end up being counterproductive...

indeed, my idea was to make this optional, as you don't always want this.

to avoid having to define yet another cmd line option for this, maybe we can do something like --review-pr-filter=full:<regex> to indicate that the user wants full control over the filtering?

this is just an idea of course, doesn't need to be in this PR

[boegel]

@migueldiascosta Any reason why this is marked as draft?