[MGNLTEST-303] self-tests of test-fwk::main should run against both test-webapps master and 6.2-branch Created: 25/Aug/22  Updated: 27/Oct/22

Status: Open
Project: Magnolia Test Framework
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Neutral
Reporter: Christoph Meier Assignee: Unassigned
Resolution: Unresolved 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)
Team: Foundation

 Description   

Context

We aim to keep only one version of the TF.

Currently the build of TF runs tests against 6.2-branch of the dx-core-test-webapp (author). That is fine since currently our "main releases" are coming from the 6.2 branch.

But we also want to ensure the TF works on master versions of dx-core-test-webapp: For PaaS, for SaaS, for upcoming 6.3 version ... AND ... typically when new POs are created, they are developped against the latest versions of the UI (aka latest versions of content-app and the like). But 6.2-branch of dx-core-(test)-webapp may still contain legacy app (though they have just been removed at least on the test-webapp, see MGNLEE-715).

How / when to trigger the tests?

Option a:
Trigger both sequentially in the same build.
Drawback: The build time will become very long.

Option b:
Have a default version of the test-webapp which is used for a "regular build".
Run the tests against the other version of the test-webapp once per day / nighttime.

Option b is preferable.

Developer notes

TF currently utilizes the pipeline-template moduleUiTestsPipeline

The version of the test-webapp is defined in the .env file. This file is used by docker!

The goal would be to stop defining the version in .env but to instead allow either the pipeline or the Docker compose file to supply it. Indeed, in case the pipeline didn't supply any version, Docker compose allows a fallback syntax that will default to 6.2-SNAPSHOT. This isn't possible in the env file. (See branch)

Talking of the pipeline, it should tolerate that MAGNOLIA_VERSION can change. Either it's 6.3-SNAPSHOT for overnight builds described above, or, in all other cases, it's 6.2-SNAPSHOT. The only difficulty is making this change to the pipeline template without affecting other modules that use it. Ideally the pipeline should become parameterized, but maybe that would bring consequences we don't want.


Generated at Mon Feb 12 07:47:33 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.