feat: Introduce force re-deploy option

[AndrienkoAleksandr]

What does this pull request do:

Introduce force re-deploy option. This PR introduces a way to redeploy RHDH with modified configuration without full teardown, while reusing existing merge logic.

[AndrienkoAleksandr]

@subhashkhileri, what do you think about this pull request?

[AndrienkoAleksandr]

@subhash Khileri,

I hope you’re doing well. I’d really appreciate your thoughts on this PR:
#87

Along with that, I wanted to share some use cases I encountered while working on e2e tests.

I’ve recently worked on two e2e-related pull requests:

• feat(e2e): introduce e2e tests for bulk-import plugin rhdh-plugin-export-overlays#1972
• feat(rbac-e2e): Add rbac default permissions e2e test rhdh-plugin-export-overlays#2066

In both cases, I had separate test.describe sections that required RHDH to be deployed with different application or plugin configurations.

Currently, rhdh.deploy uses the runOnce strategy. Because of that, when I need to redeploy RHDH with a different configuration, I have to rely on either scaleDownAndRestart or teardown. However, both approaches have some drawbacks:

• scaleDownAndRestart – There’s no ready-to-use logic available for merging application or plugin configurations. This logic is currently outside the scope of rhdh.configure and encapsulated in private methods. As a result, for each new PR, I either need to reimplement this merging logic for plugin tests or ask for those private methods to be exposed.
• teardown – This completely removes the RHDH namespace. When used together with rhdh.configure and rhdh.deploy, it significantly increases test execution time, since we have to wait for the namespace to be fully deleted and then for a full redeployment.

Given these limitations, do you think the approach proposed in this PR makes sense? Or would you recommend continuing with the existing methods?

Thanks in advance for your feedback!

[subhashkhileri]

Hey! Thanks for working on this — the bulk-import e2e tests look great. I have some thoughts on the forceUpdate approach that I wanted to share.

Only one describe block needs forceUpdate

Looking at the consumer PR (#1972), only the orchestrator mode describe uses forceUpdate. The other three describes all share the same RHDH configuration (app-config-rhdh.yaml + values.yaml) and already work fine with runOnce deduplication. So the entire new API is driven by a single describe block.

Suggested approach: split into two spec files

The orchestrator mode tests are fully independent — they create their own test data (scoped by Date.now()), clean up in afterAll, and don't share mutable state with the other describes. So we could split into just two files:

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: "bulk-import", testMatch: "bulk-import.spec.ts" },
    { name: "bulk-import-orchestrator", testMatch: "bulk-import-orchestrator.spec.ts" },
  ],
});

• bulk-import.spec.ts — the three existing describes (same config, one deploy shared via runOnce)
• bulk-import-orchestrator.spec.ts — orchestrator mode only, its own namespace and deployment

They run in parallel, each with full runOnce protection. No new API needed, and the orchestrator tests don't block the standard tests — so it should be faster overall too.

If they must stay in one file — existing APIs already work

If there's a reason to keep everything in one spec file, the existing public API already supports updating RHDH config mid-test. Just make sure to wrap it in runOnce so it's protected against worker restarts:

await test.runOnce("bulk-import-orchestrator-config", async () => {
  await rhdh.k8sClient.applyConfigMapFromObject(
    "app-config-rhdh",
    newAppConfig,
    rhdh.deploymentConfig.namespace,
  );
  await rhdh.scaleDownAndRestart();
  await rhdh.waitUntilReady();
});

This makes the intent clear to anyone reading the test — the existing deployment is being updated and restarted with a new configuration, rather than a full redeploy happening behind the scenes. And wrapping it in runOnce ensures it won't repeat on worker restarts.

Why I'm cautious about forceUpdate bypassing runOnce

The reason runOnce exists is to protect against Playwright worker restarts. When a test fails, Playwright kills the worker and spins up a new one, which re-runs beforeAll including deploy(). Without runOnce, that triggers a full RHDH redeployment (~10+ min) on every worker restart.

With forceUpdate: true, that protection is gone. If any test in the orchestrator describe fails and triggers retries, each retry spins up a new worker, hits deploy({ forceUpdate: true }), and does a full redeployment from scratch. With the 5 retries configured in CI (retries: process.env.CI ? 5 : 0), what should be a quick retry could turn into 20-30+ minutes of waiting for redeployments.

What do you think?

[AndrienkoAleksandr]

Hello, thanks for the suggestions!

I initially tried the following approach, and it works:

await rhdh.k8sClient.applyConfigMapFromObject(

However, this requires maintaining a full copy of the app-config-rhdh ConfigMap with test-specific modifications. I would also need to keep this copy in sync in case something changes in future RHDH releases or in the e2e test framework’s deployment logic. Additionally, this ConfigMap would duplicate configuration already present in other tests/config files.

Alternatively, I could implement a patch/merge strategy for this configuration (for example: https://github.com/redhat-developer/rhdh-plugin-export-overlays/pull/2066/changes#diff-10779869d96a728a6ddfa11481c33c55ff1a4d1ad211b612b73b89e45174f4bbR29
). However, one important detail is that configuration merge logic is already implemented in the framework:

#76

So ideally, it would be great to reuse that instead of reimplementing similar logic in tests.

Suggested approach: split into two spec files

I can take a look at this approach. However, I noticed in another PR that using a single file was previously recommended:
redhat-developer/rhdh-plugin-export-overlays#2052 (comment)

So I assume that using multiple files may also have some limitations or trade-offs.

For example, I’m not sure how test suites from multiple files are expected to run in parallel. In my case, for the bulk-import plugin, I need to test two different modes (open pull request and orchestrator). To run them in parallel, the framework would likely need to deploy two separate RHDH instances.

Additionally, I have an open issue to implement a third mode (scaffolder template execution). Would that mean having three separate spec files?

Given the current limitations, it seems that parallel execution may not be feasible unless the framework supports multiple independent RHDH deployments. So in my case, I would likely need to use multiple spec files and run them sequentially...

P.S. Sorry for the long message — I’m trying to understand the recommended best practices for more complex test scenarios. It’s possible I’m overthinking this since we’ve just started using the framework.

[AndrienkoAleksandr]

Suggested approach: split into two spec files

@subhashkhileri, few files really works in parallel, thank you very much!