You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #318 we introduced the ability to run our CI locally via act. This is extremely helpful, but currently very slow to run the unit/system/integration tests all together, since they need to be run serially. The integration tests also still use the same cluster names as the defaults in the quick-start, meaning any cluster spun up manually will be destroyed when running the integration tests locally.
To enable proper parallelisation, there are a couple of things left to do, detailed below...
Parametrise ports to enable parallelisation
The work for #318 included parametrising the platform/worker cluster names in the system tests (e.g. from kind-platform -> kind-system-test-platform) so that each suite would have its own cluster spun up independently. However, we discovered that the ports we expose also clash between suites and manually-provisioned quick-start clusters (e.g. 31340 for Backstage, 31333 for Gitea).
These ports will need to be unique per test suite, and passed in as parameters to the system/integration tests (with the current values used as defaults).
Use unique cluster names for integration tests
The system tests already use the system-test- prefix for cluster names, but the integration tests don't. We'll need to introduce a similar integration-test- prefix to the cluster names to prevent clashing with the quick-start defaults.
The text was updated successfully, but these errors were encountered:
richcooper95
changed the title
chore: enable local CI to run in parallel
chore: enable local CI to run in parallel and leave quick-start clusters alone
Feb 18, 2025
In #318 we introduced the ability to run our CI locally via
act
. This is extremely helpful, but currently very slow to run the unit/system/integration tests all together, since they need to be run serially. The integration tests also still use the same cluster names as the defaults in the quick-start, meaning any cluster spun up manually will be destroyed when running the integration tests locally.To enable proper parallelisation, there are a couple of things left to do, detailed below...
Parametrise ports to enable parallelisation
The work for #318 included parametrising the platform/worker cluster names in the system tests (e.g. from
kind-platform
->kind-system-test-platform
) so that each suite would have its own cluster spun up independently. However, we discovered that the ports we expose also clash between suites and manually-provisioned quick-start clusters (e.g.31340
for Backstage,31333
for Gitea).These ports will need to be unique per test suite, and passed in as parameters to the system/integration tests (with the current values used as defaults).
Use unique cluster names for integration tests
The system tests already use the
system-test-
prefix for cluster names, but the integration tests don't. We'll need to introduce a similarintegration-test-
prefix to the cluster names to prevent clashing with the quick-start defaults.The text was updated successfully, but these errors were encountered: