[APM] E2E: Zero config for running e2e locally#59152
[APM] E2E: Zero config for running e2e locally#59152sorenlouv merged 9 commits intoelastic:masterfrom
Conversation
There was a problem hiding this comment.
Enabling Security and ES and APM Server on non-default ports to avoid clashing with local development
3ca9e26 to
1dfe5a3
Compare
There was a problem hiding this comment.
Refer to e2e specific config file (instead of moving it around)
There was a problem hiding this comment.
This is now specified in kibana.e2e.yml. Not something the user has to worry about.
There was a problem hiding this comment.
Running kibana on a non-default port to avoid clashing with local development
There was a problem hiding this comment.
Added all apm configurations to ensure they don't break without us noticing
There was a problem hiding this comment.
Provide credentials to Cypress via environment vars
|
retest |
There was a problem hiding this comment.
kibana_system_user didn't work when I tried, so maybe admin could be a good one, what do you think?
| elasticsearch.username: 'kibana_system_user' | |
| elasticsearch.username: 'admin' |
There was a problem hiding this comment.
Kibana shouldn't connect to ES with superuser privileges. According to the docs kibana_system_user should exist.
I can confirm that kibana_system_user can access ES like:
curl --user kibana_system_user:changeme -X GET "localhost:9201/_security/user/_has_privileges?pretty" -H 'Content-Type: application/json' -d'{ "cluster": [ "monitor", "manage" ] }'
which returns:
{
"username" : "kibana_system_user",
"has_all_requested" : false,
"cluster" : {
"monitor" : true,
"manage" : false
},
"index" : { },
"application" : { }
}There was a problem hiding this comment.
Can you try running that and LMK if it works?
smith
left a comment
There was a problem hiding this comment.
👍 once conflicts resolved and up to date and tests pass.
Co-Authored-By: Victor Martinez <victormartinezrubio@gmail.com>
|
Hi @sqren I'm helping to triage high-priority issues for @elastic/observablt-robots . Just so I understand, are the |
e2dbda9 to
4e8d51a
Compare
|
Hey @cachedout, I've just pushed a commit that fixes most of the issues. Only remaining issue is that apm-integration-testing does not return a non-zero exit code upon error. This should be fixed in https://github.com/elastic/apm-integration-testing but not something that should block this PR. I'll merge this as soon as CI is green |
|
@sqren Do exist an issue for that on the https://github.com/elastic/apm-integration-testing? I do not see any. Would you mind fill one with the details of what happens? |
|
retest |
| ## Might help to avoid FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory | ||
| export NODE_OPTIONS="--max-old-space-size=4096" | ||
| nohup node scripts/kibana --no-base-path --csp.strict=false --optimize.watch=false> kibana.log 2>&1 & | ||
| nohup node scripts/kibana --config "${E2E_DIR}/ci/kibana.e2e.yml" --no-base-path --optimize.watch=false> kibana.log 2>&1 & |
There was a problem hiding this comment.
What's the difference with https://github.com/elastic/kibana/pull/59152/files#diff-ccfe59ee0ec66fe86f6596aaf1fce60cR24? Are those flags also required in the CI?
There was a problem hiding this comment.
This starts in dev mode
node ./scripts/kibana --no-base-path --dev --no-dev-config --config x-pack/legacy/plugins/apm/e2e/ci/kibana.e2e.yml
This starts in prod mode
node scripts/kibana --no-base-path --optimize.watch=false --config "${E2E_DIR}/ci/kibana.e2e.yml"
I think we should choose whatever is faster on CI. I guess we can test by running it 100 times or so on the CI in each mode.
I imagine dev compiles faster (because it doesn't need to compress resources) but prod has faster browser load times because assets are smaller. So could go both ways.
The reason I opted for using dev mode locally is because this is what developers is normally running, and I saw some issues when running prod mode without cleaning up after having run dev mode.
There was a problem hiding this comment.
Thanks for the clarification, I'd say to use the same as the local one to avoid any misleading, then it will be easy to reproduce it anyway. Thanks again
|
@elasticmachine merge upstream |
then we don't need to trap the errorlevel
💚 Build SucceededHistory
To update your PR or re-run it, just comment with: |
Changes
--configto loadkibana.e2e.ymlinstead of the user'skibana.dev.yml.run-e2e.shscript to automatically setup environment and run testsTODO:
--devmode. This is currently not possible because it disables the--configflag.Helpful error messages
