Add a mechanism to ensure scylla version is not outdated

[sylwiaszunejko]

Add a workflow that checks if scylladb version used in CI is not outdated and fails if it is. We should update scylladb version every minor for oss and for enterprise we should target latest lts minor.

[Lorak-mmk]

Can't you use the same script that is used in java driver CI? It checks and prints selected amount of latest versions of chosen type.

Script: https://github.com/scylladb/java-driver/blob/scylla-3.x/ci/version_fetch.py
Usage in CI: https://github.com/scylladb/java-driver/blob/701b745a553d118cc865f009f57c38767b049d66/.github/workflows/tests%40v1.yml#L103-L123

[sylwiaszunejko]

@Lorak-mmk the problem is for the extended CI we need to use specific branches of sct e.g. branch-6.1 or branch-2023 for the jenkins job. So when we want to update from 6.1 to 6.2 we need to create manually a new job for that. We need some kind of reminder that new minor of scylladb is released so we would update hardcoded minor in CI and create a new job.

Script: https://github.com/scylladb/java-driver/blob/scylla-3.x/ci/version_fetch.py
Usage in CI: https://github.com/scylladb/java-driver/blob/701b745a553d118cc865f009f57c38767b049d66/.github/workflows/tests%40v1.yml#L103-L123

This mechanism after some modification would be used to get a latest patch release for a given minor

[roydahan]

I'm not sure what you mean by "need to manually create new job".

I also don't think this mechanism is necessary.

IMO the CI should use 2024.1 as Scylla_version and the SCT branch is branch-2024.1.
This promises to test on latest 2024.1 which LTS and make sure there are no regressions.

In addition, we can have another CI job if we think is necessary that points to "scylla_version: master:latest".
This job can be used with SCT branch master and should be used in order to test our driver with the latest and greatest Scylla features.
It won't be as stable as the first one, but it will be a good addition to get an additional data point on client stability.

[dkropachev]

I'm not sure what you mean by "need to manually create new job".

It is about jenkins job, every sct branch we target needs separate job for it.

I also don't think this mechanism is necessary.

it is not clear from the description but @sylwiaszunejko proposes the following:

1. Have sct branches and minor+major for OSS and ENTERPRISE_LTS staticly defined on CICD.
2. Have a separate step that would just tell us to update to next OSS (and potentially ENTERPRISE_LTS) version (and branch) when it is released. To make sure we are always on top version.