[MGNLCE-125] Untie test environment deployment from Maven config Created: 12/Jan/18  Updated: 23/Feb/18  Resolved: 23/Feb/18

Status: Closed
Project: Community Edition
Component/s: None
Affects Version/s: None
Fix Version/s: 5.5.10, 5.6.2

Type: Improvement Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Aleksandr Pchelintcev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Epic Link: Improve QA setup
Story Points: 5

 Description   

If we start using the complex scenarios with parallel test execution, Fabic8 Maven plugin won't be powerful enough to do the trick:

  • Selenium Grid usage implies varying amount of the Selenium nodes
  • Forked JVM execution might also require more than one Mgnl app server container to be started. Configuring that with XML in pom file is not feasible and bulky.
  • Managing the Docker networking from within pom.xml is bulky and adds lot's of noise.

The alternative solution is to do all the test environment manipulations from the code. We can implement the JUnit rules make sure that the test have all they need and manage containers and networks via Docker API for Java and TestContainers library. Note: this should be implemented primarily so that the developer would be able to run the integration and UI test builds locally without having to provide test environment by hand.

In case of CD/CI the test environment should be provided externally (the whole cluster of mgnl and selenium containers running on different machines). Such environment should be managed by e.g. Jenkins pipeline and it shouldn't be an mvn's or test implementation's concerns. That should be an easily available option.

As a side effect of phasing out the test env config from pom.xml we lose the need to duplicate such configuration in e.g. EE integration test pom.xml (the Java code is essentially shared, external deployment is managed externally). What we do for CE automatically propagates onto EE (we should make sure that flexibility is not lost and EE can e.g. configure own ports, Docker images etc).


Generated at Mon Feb 12 00:06:31 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.