Ensure RHEL tests use a valid version of Management Center [DI-422]

[JackPGreen]

The RHEL publish tests the build by connecting an Management Center instance to it.

In #847 this was changed to use a matching version of Hazelcast & Management Center - which isn't correct in all cases (e.g. 5.5.2 Hazelcast & 5.6.0 Management Center)

Before this change, it used the latest version of Management Center - derived by inspecting the tags of the (archived) https://github.com/hazelcast/management-center-openshift repo - but the last tag here was 5.3.2 so it wasn't really the latest at all.

In consultation with the Management Center team, latest is the best option.

Changes:

• rolls back to something inspired by the previous implementation - choses latest based on tags
• tags are scraped from the hazelcast/management-center repo
• tags are queried using the gh cli tool to avoid checking out the whole repo

I don't think we should backport this change, as while it's not correct in earlier versions, it doesn't cause an issues.

Fixes: DI-422

[nishaatr]

Just had a thought about sorting. Might not work with double digits e.g. v5.5.32
Not sure tbh but has cropped up before
MC tend to do more releases so there is chance this might happen so worth testing
you could use sort -V or something similar.

[JackPGreen]

Just had a thought about sorting. Might not work with double digits e.g. v5.5.32 Not sure tbh but has cropped up before MC tend to do more releases so there is chance this might happen so worth testing you could use sort -V or something similar.

The tags are returned in date order. I've taken the sort out to avoid adding any extra logic there.

[JackPGreen]

Just had a thought about sorting. Might not work with double digits e.g. v5.5.32 Not sure tbh but has cropped up before MC tend to do more releases so there is chance this might happen so worth testing you could use sort -V or something similar.

The tags are returned in date order. I've taken the sort out to avoid adding any extra logic there.

Actually changed my mind - if we do a patch release of (say) 5.1.1, that shouldn't be considered better to use than (say) 5.6.0. Now uses the sort as you suggested.

374765e

[nishaatr]

Actually changed my mind - if we do a patch release of (say) 5.1.1, that shouldn't be considered better to use than (say) 5.6.0. Now uses the sort as you suggested.

Sorry where in the regex test("^v\\d+(\\.\\d+)*$")) is this done i.e. should it not end with .0?

I guess we can limit to major/minor but not sure why we should not consider PATCH. Any good reason?
This is just for internal testing so perhaps MANOR/MINOR should be fine

[JackPGreen]

Actually changed my mind - if we do a patch release of (say) 5.1.1, that shouldn't be considered better to use than (say) 5.6.0. Now uses the sort as you suggested.

Sorry where in the regex test("^v\\d+(\\.\\d+)*$")) is this done i.e. should it not end with .0?

I guess we can limit to major/minor but not sure why we should not consider PATCH. Any good reason?

This is just for internal testing so perhaps MANOR/MINOR should be fine

It's not checking for 0 - that was just an example of the kind of scenario where it could've gone wrong.

I was trusting GitHub returning the most recent tag would be the latest version - but when we say latest we really mean highest - so added an explicit semver-aware sort to assert that.