Add github workflow running jenkins job

[sylwiaszunejko]

This workflow pushes scylla-bench docker image using gocql version from the PR and triggers jenkins job that uses this image of scylla-bench.

[sylwiaszunejko]

v2:

• user changed to org level JENKINS_USERNAME
• added the logic to get latest scylla oss and enterprise release (as in cpp-rust-driver)
• added extra parameter to jenkins-client to be able to configure timeout for waiting in the queue (needed when we want to trigger two jobs for oss and enterprise release and one have to wait for the other to finish)
• changed email to scylla-drivers@scylladb.com

Things that still need to be addressed:

• creating scylladb fork of jenkins-client, now this PR uses my fork
• what branch should Jenkins job target
• is running asymmetric-cluster test the right choice or should we choose different one?

@dkropachev @roydahan @fruch

[sylwiaszunejko]

https://github.com/scylladb/gocql/actions/runs/11157393428/job/31011588519?pr=263 I am not sure why the second workflow gets interrupted even though the timeout has not passed yet and the job was still running when it happened

[sylwiaszunejko]

@dkropachev is https://github.com/scylladb-actions/jenkins-client an official location for this action?

[sylwiaszunejko]

what branch should Jenkins job target
is running asymmetric-cluster test the right choice or should we choose different one?

@roydahan @fruch could you help with this questions?

[dkropachev]

@dkropachev is https://github.com/scylladb-actions/jenkins-client an official location for this action?

It is not, but it shouldn't matter since it is an GitHub action.

[roydahan]

what branch should Jenkins job target

is running asymmetric-cluster test the right choice or should we choose different one?

@roydahan @fruch could you help with this questions?

I'm working on stabilizing another shorter test for CI (1h test that is based on this test).
+
My comment from a different related issue:

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.

[roydahan]

Tested the new job for CI with various nemesis_seeds (in order to fix it with a specific one later): https://argus.scylladb.com/tests/scylla-cluster-tests/1adffeeb-28ac-432c-a6f8-8477b70fa557
For now it seems like the CI job is very stable (suspiciously too stable).

[dkropachev]

Tested the new job for CI with various nemesis_seeds (in order to fix it with a specific one later): https://argus.scylladb.com/tests/scylla-cluster-tests/1adffeeb-28ac-432c-a6f8-8477b70fa557 For now it seems like the CI job is very stable (suspiciously too stable).

Great, what is the next step for the job ? do you want to merge it ? should we finally merge this PR pointing to a job with temporary sct repo/branch ?

[sylwiaszunejko]

I have changed the logic to use https://github.com/scylladb-actions/get-version/tree/main to get scylladb latest version

[sylwiaszunejko]

Tested the new job for CI with various nemesis_seeds (in order to fix it with a specific one later): https://argus.scylladb.com/tests/scylla-cluster-tests/1adffeeb-28ac-432c-a6f8-8477b70fa557 For now it seems like the CI job is very stable (suspiciously too stable).

Great, what is the next step for the job ? do you want to merge it ? should we finally merge this PR pointing to a job with temporary sct repo/branch ?

@roydahan ?

[roydahan]

I was working to add more partitions to the test so the workload will be more balanced across the shards, but now I need to stablize it a bit since the load is higher now.
I'll try to get done with it by early next week, so we can use it from the beginning.

[sylwiaszunejko]

@roydahan should we use new test as scylladb/scylla-cluster-tests#9137 is merged?

[roydahan]

Yes, this is the new job: https://jenkins.scylladb.com/view/scylla-drivers/job/scylla-drivers/job/gocql/job/extended-ci/job/longevity-large-partitions-with-network-nemesis-1h-test/

[sylwiaszunejko]

It keeps failing on provisioning resources, when I changed the instance type from spot to on_demand it works.
@roydahan is it a good idea to change instant type to on_demand as a default?

[roydahan]

It's probably a transient issue with spot availability.
IIRC, we should have an automatic fallback in this case, I can check that.

Another option is to trigger it for now with on_demand.

[roydahan]

Sent scylladb/scylla-cluster-tests#9180 to add the fallback by default.