[MGNLCE-130] Let the whole CE be executed as a single pipeline Created: 12/Jan/18  Updated: 25/Apr/18  Resolved: 26/Feb/18

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

Type: Task Priority: Neutral
Reporter: Aleksandr Pchelintcev Assignee: Maxime Michel
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLCE-124 Parallelise Selenium UI test execution Closed
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:
Epic Link: Pipelines MVP
Sprint: Basel 133, Basel 134, Basel 135
Story Points: 13

 Description   

JUnit Maven integration allows the test classes to be executed in parallel, for that the fork options should be configured.

In our case it would be very beneficial - we could use some good hardware and run the UI tests on several forked JVMs reducing the execution time dramatically. However, the problem is that if we use a single Mgnl author-public pair, the level of entropy is way too high - the test classes may easily step onto each others toes.

To overcome this problem, we should have several Mgnl deployments that are connected to the JUnit forked JVM one-to-one. This way we would maintain the current stability.

The tests however, would need to know, which server they should deal with. There's a couple of ways how that can be achieved:
1) surefire.forkNumber property is available during the test execution and contains the index of the JVM. We could construct the server URL out of that (i.e. the test would connect to *http://server-1:8080* or *http://server-2:8080* and so on). This is an easy to implement option, but it would require us to manage the mgnl deployments ourselves, i.e. we won't be able to just tell Docker to deploy 5 Mgnl instances on three different machines and run tests with them.

2) We could run the instances as a Swarm service, which makes it harder to address an instance individually (because they will be behind Swarm load balancer), but it would be possible to provide a custom load balancing strategy to the swarm, which will implement the hard link between the IP used by a forked JVM and the Mgnl instance (check out related HAProxy article and Docker tutorial ). This way the Mgnl deployment access would be transparent to the tests completely. Drawback - we'd need to fiddle a bit with load balancers and proxies (each forked JVM would probably need another personal HAProxy instance to mimic the unique IP address).



 Comments   
Comment by Maxime Michel [ 26/Feb/18 ]

The pipeline needs polishing but is now running on Jenkins.

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