[Escalation] SPIKE: e2e pipeline blocker #30822
Assignees
Labels
Comments
sfreudenthaler
moved this from Current Sprint Backlog
to Next 1-3 Sprints
in dotCMS - Product Planning
Configuration Discrepancies and Testing StrategyContextCurrently, there is a discrepancy between the environment configuration used during CI (integration/Postman tests) and the Docker Compose setup provided for running dotCMS. While Maven-based configurations ensure consistency and repeatability in CI, the Docker Compose file, used for local development or example setups, does not undergo similar testing. This raises concerns about configuration drift, reliability, and how the environment aligns with what customers might use. Key Issues and Questions1. Configuration Consistency Across Testing and Deployment
2. Centralized Source of Truth for Configuration
3. Alignment Between Parent POM and Runtime Behavior
4. Testing the Delivered Docker-Compose Configuration
Key Decisions to Address
Possible Solutions1. Unified Testing Approach
2. Centralized Configuration
3. Environmental Profiles
4. Testing Workflow Refinement
5. Testing Delivered Docker Compose
Questions to Resolve
|
sfreudenthaler
changed the title
spbolton
moved this from Next 1-3 Sprints
to Current Sprint Backlog
in dotCMS - Product Planning
sfreudenthaler
moved this from Current Sprint Backlog
to In Review
in dotCMS - Product Planning
|
I think this PR resolved the e2e test issues. https://github.com/dotCMS/core/actions/runs/12172665490. As I suspected could be the cause there seems to have been a timing issue and the requests are being made before the system is running. https://github.com/dotCMS/core/actions/runs/12172665490. As I mentioned to Bryan though adding a delay or waiting for state may stop the tests from breaking, but It may also indicate that we are getting into a state on startup where the server is accepting requests but it is not really ready yet and whether we hit this state may have a level of randomness and based upon server performance. Without digging in more it is hard to debug this exactly, I have a suspicion from indecations in the log that we may be asking for system notifications very early in the process during startup and it is returning an error, this error may be breaking the js causing side effects like the login button not being enabled. using e2e to test some of the complex behavior here when it relies on the server having just started up may be a little tricky. This is where we may be able to simulate the requests throwing error in the logs with jmeter, and validate the timing on starting up, as well as validating ui impact on a failure. We seem to be asking for the notifications quite a lot ( i know in the cloud this is cached by bunny ) and maybe the client should impose a minimum delay in requesting, but also it is possible we should better handle failover here where a failure in notifications should not break other js in the browser and just look like there are non (if in fact this is the case) It does seem at least though that we are may not be blocked by this issue any more. |
|
Log in failure before change showing login requests and requests for anoncements for reference. |
|
Awaiting on this PR if this works in CI then we are good for now #30932 |
|
sounds like @bryanboza is unblocked. It came up in a 1:1 discussion with him earlier today |
github-project-automation
bot
moved this from In Review
to Done
in dotCMS - Product Planning
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
TIMEBOX 1 day (fix if you can)
Placeholder
Raised by @bryanboza, his e2e rock is blocked because he's having trouble getting them into the pipeline. This needs significant refinement before we can pick it up.
possibly a spike if it's not an easy fix.
Need to pair on it live with someone because there's knowledge gaps on the team.
The text was updated successfully, but these errors were encountered: