Make acceptance CI test matrix parallel#5295
Conversation
| workflow: test.yml | ||
| repo: hashicorp/consul-k8s-workflows | ||
| ref: main | ||
| ref: acceptance-test-crd-parallel |
There was a problem hiding this comment.
Why is this changed from main branch to acceptance-test-crd-install-flag branch ?
There was a problem hiding this comment.
It is done to test with the consul-k8s-workflows branch temporarily which hass dependent changes
There was a problem hiding this comment.
i hope this will be changed to main after workflows are merged to main in k8s-workflows ?
|
/rerun |
…nal, update helm_cluster_test
Splits 7 monolithic table-driven acceptance tests (38 cases total) into individual top-level Test* functions so each gets its own dedicated CI runner via the existing bin-packing sharding system. Drops the test ceiling from 55 min (TestPartitions_Connect, 6 cases) to ~11 min (TestWANFederationFailover per case). Updates test-timings.json with per-case estimates so the matrix generator can bin-pack correctly from the first run.
…pod readiness check
…for wan-federation
…ortServices (4 cases); add num-clusters:2 for partitions
…-clusters for api-gateway and peering
…rning from kind-cni-calico
7b3ed94 to
ade0809
Compare
There was a problem hiding this comment.
why was there a need to modify these files so much ? what benefit have we gotten with exposing test type to each test case now ? can we retry at case level or still package level only ? if not so why to make so many changes to the file.
There was a problem hiding this comment.
i believe this is part of ci workflows . then it could be in .github/scripts folder rather than build-support in control-plane.
| } | ||
| } | ||
|
|
||
| discovered := discoverTests(repoRoot, pkg) |
There was a problem hiding this comment.
rename variables sensibly . suggested discoveredTestsInPackage.
Changes proposed in this PR
Core feature
CI: Test matrix parallelization
CI: Reliability fixes
How I've tested this PR
How I expect reviewers to test this PR
Checklist
PCI review checklist
I have documented a clear reason for, and description of, the change I am making.
If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
If applicable, I've documented the impact of any changes to security controls.
Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.