internal/testrunner/script: add script testing package#3012
internal/testrunner/script: add script testing package#3012efd6 merged 15 commits intoelastic:mainfrom
Conversation
411a39e to
bc55805
Compare
|
/test |
d9e0c1a to
8433c67
Compare
| return cmd | ||
| } | ||
|
|
||
| func testRunnerScriptCommandAction(cmd *cobra.Command, args []string) error { |
There was a problem hiding this comment.
The logic in this function is rudimentary and only intended to allow an MVP to be demonstrated. In order to be able to render reports and redirect to file output this needs enhancement.
7f4815f to
fdc0951
Compare
jsoriano
left a comment
There was a problem hiding this comment.
Thanks! This is a pretty interesting feature.
I haven't checked the implementation in detail, added by now some comments and questions about the overall behavior.
internal/testrunner/script/script.go
Outdated
| if err != nil { | ||
| return err | ||
| } | ||
| workRoot := filepath.Join(home, filepath.FromSlash(".elastic-package/tmp/script_tests")) |
There was a problem hiding this comment.
Config directory should be obtained using the location manager. It can be customized with ELASTIC_PACKAGE_DATA_HOME.
The tmp directory can be obtained with loc.TempDir().
| workRoot := filepath.Join(home, filepath.FromSlash(".elastic-package/tmp/script_tests")) | |
| workRoot := filepath.Join(home, loc.TempDir(), "script_tests") |
| // root is non-zero, so just let testscript put it where it wants in the | ||
| // case that we have not requested work to be retained. This will be in | ||
| // os.MkdirTemp(os.Getenv("GOTMPDIR"), "go-test-script") which on most | ||
| // systems will be /tmp/go-test-script. However, due to… decisions, we |
There was a problem hiding this comment.
What decisions are you referring to? 🙂
There was a problem hiding this comment.
The use of file system jailing prevents using other paths.
There was a problem hiding this comment.
Maybe this should be part of the coment 🙂
test/packages/other/with_script/data_stream/first/_dev/test/scripts/agent_up_down.txt
Show resolved
Hide resolved
| # Only run the test if --external-stack=true. | ||
| [!external_stack] skip 'Skipping external stack test.' | ||
| # Only run the test if the jq executable is in $PATH. This is needed for a test below. | ||
| [!exec:jq] skip 'Skipping test requiring absent jq command' |
There was a problem hiding this comment.
It looks like several sample tests here depend on jq to compare fields in JSON files. If this is going to be frequent, maybe we can provide a function to do these comparisons? And maybe the same with basic http requests to avoid depending on curl.
This would help to avoid depending on external tools that may not be installed, specially on Windows.
There was a problem hiding this comment.
If it becomes necessary, those can be added. Both curl and jq are available in CI and I'd prefer to avoid having to reimplement and maintain tools that already exist.
There was a problem hiding this comment.
Agree this can be added later.
I am not so worried about the current CI, but about future deployments where we might forget to install jq (or curl in Windows) if not required for other things, and the test would be silently skipped. Same thing for local execution.
jq and curl are powerful tools, in no case I would think on re-implement them, but the limited logic that we need, also reusing existing tools, in the form of Go code.
mrodm
left a comment
There was a problem hiding this comment.
Added a comment about CI scripts.
The error raised in the latest Buildkite build should be fixed now, since it has been merged the new spec version #3049
| PACKAGE_TEST_TYPE=other ./scripts/test-check-packages.sh | ||
|
|
||
| test-check-packages-independent-script: | ||
| elastic-package test script -C test/packages/other/with_script --external-stack=false --defer-cleanup 1s |
There was a problem hiding this comment.
I would create a new folder for this test package like test/packages/independent-script/ and just keep (move) that new test package into this new folder.
The reasoning of this is that currently, this with_script test package is being tested twice in Buildkite builds. In these two steps:
Integration test: otherIntegration test: independent-script
So, I would create a new folder and update this target:
| elastic-package test script -C test/packages/other/with_script --external-stack=false --defer-cleanup 1s | |
| elastic-package test script -C test/packages/independent-script/with_script --external-stack=false --defer-cleanup 1s |
There was a problem hiding this comment.
I would create a new folder for this test package like
test/packages/independent-script/and just keep (move) that new test package into this new folder.
The twice use of this is intentional.
There was a problem hiding this comment.
The twice use of this is intentional.
Why is it needed? Within the other step, what is it different from the other CI step (independent-script)?
Maybe it is tested with the stack triggered by the CI itself ? I mean not using this external-stack=false ?
There was a problem hiding this comment.
When external-stack=false, the script brings up a stack. This would fail if a stack is already running due to port collision. The external and non-external stack tests need to be in the same package to ensure that the conditional is correctly implemented.
d5eced9 to
054ae48
Compare
|
/test |
andrewkroh
left a comment
There was a problem hiding this comment.
LGTM. I left a few minor comments and have two questions:
-
When we run
dump_logs, it captures logs like$WORK/logs/elastic-agent-internal/elastic-agent-YYYYMMDD.ndjsonand$WORK/logs/elastic-agent-internal/cel/cel-UUID-URL.ndjson. Will these less predictable file names make it difficult to write assertions on their file contents from testscript? -
Can we add a mechanism to capture the registry files from the Elastic Agent container? I would like to be able to run assertions on their contents, like checking that the httpjson cursor contains a specific timestamp or pagination token after test completion.
It will to a degree; from what I can see elastic-package's testing was not written with a concern for bit-reproducible testing. The filenames there are a consequence of the way that logs are written by the underlying routines in elastic-agent though AFAICS. At the moment, the way to handle these would be to have a helper shell script or maybe The current situation does not make it impossible, but depending on the threshold for "difficult", yes, no or maybe.
We can; in fact that is one of my unchecked TODO boxes. Would you like that added in this change, or can it be added in a follow-up? |
I've done this. |
|
In a follow-up would be best. |
docs/howto/script_testing.md
Outdated
| While the testscript package allows reference to paths outside the configuration | ||
| root and the package's root, the backing `elastic-package` infrastructure does | ||
| not, so it is advised that tests only refer to paths within the `$WORK` and | ||
| `$PKG_ROOT` directories. No newline at end of file |
There was a problem hiding this comment.
Looking into the environment variables listed above, should this be PACKAGE_ROOT?
| `$PKG_ROOT` directories. | |
| `$PACKAGE_ROOT` directories. |
|
|
||
| While the testscript package allows reference to paths outside the configuration | ||
| root and the package's root, the backing `elastic-package` infrastructure does | ||
| not, so it is advised that tests only refer to paths within the `$WORK` and |
There was a problem hiding this comment.
Should WORK be added as part of the environment listed here?
💚 Build Succeeded
History
cc @efd6 |
This adds script testing for data streams. This is the MVP, future versions can be generalised to operate on input packages.
The current implementation supports:
Not supported:
Depends on a v3.5.1 of package-spec (currently shimmed in via a go.mod replace directive, to be removed)
Please take a look.
For #2944