-
Notifications
You must be signed in to change notification settings - Fork 148
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pass go test flags to integration tests #3109
Pass go test flags to integration tests #3109
Conversation
This pull request does not have a backport label. Could you fix it @pchila? 🙏
NOTE: |
/test |
🌐 Coverage report
|
Pinging @elastic/elastic-agent (Team:Elastic-Agent) |
038ff44
to
4c0a8b9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change looks good to me.
1bb7bc8
to
5c32270
Compare
ok, now integration tests are running correctly after a small change in 5c32270 /cc @ycombinator |
@@ -232,11 +232,10 @@ func GoTest(ctx context.Context, params GoTestArgs) error { | |||
) | |||
} | |||
|
|||
testArgs = append(testArgs, params.ExtraFlags...) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious: why was this change needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the incoming wall of text 😅
TL;DR: This was needed to make sure that a -test.run
flag specified in the GOTEST_FLAGS
environment variable does not interfere with the batching done by the framework.
Full explanation:
The integration test framework runs the tests twice:
- the first time we pass a special tag that make all the
define
statements in the tests skip the test and dump the requirements. This output is processed by the integration test framework to discover the tests and the set of environments/machines we will need to spawn and allocate the tests to the various machines. - the second time we run the tests (here) the integration test framework adds a
-test.run
flag when launching go test on the remote machine to make sure that only the tests corresponding to that batch are executed.
By specifying the extra flags before the -test.run
for the batch we make sure that the last flag definition "wins" (have a look at the unit test in batch_test.go
) so that whatever run
constraint is specified in GOTEST_FLAGS participates in the discovery and batching (1st go test
execution) but doesn't override the actual execution on the remote machine (2nd go test execution).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should definitely be a comment in the code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added the comment just above the change.
@@ -1491,7 +1506,7 @@ func integRunner(ctx context.Context, matrix bool, singleTest string) error { | |||
return nil | |||
} | |||
|
|||
func createTestRunner(matrix bool, singleTest string, batches ...define.Batch) (*runner.Runner, error) { | |||
func createTestRunner(matrix bool, singleTest string, goTestFlags string, batches ...define.Batch) (*runner.Runner, error) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we get rid of the singleTest
argument and the corresponding mage integration:single
target now that developers could set GOTEST_FLAGS="-test.run ^SingleTestName$
instead? I think it would be less confusing to have just one way to specify which test(s) to run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could... I am leaving it in, in case the new flags do not behave like we want but we can deprecate them and create a separate issue to clean up
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like mage integration:single [testName]
it is much clean CLI command to run a test than all the ENV flags being set. I wish we could get mage to take command line arguments for targets. I would prefer to see something like:
mage integration:test -short -name SingleTestName -platform linux/amd64
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, then could we eliminate just the singleTest
argument to this function and have mage integration:single [testName]
internally setup goTestFlags
appropriately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of questions and suggestions.
Co-authored-by: Shaunak Kashyap <ycombinator@gmail.com>
/test |
1 similar comment
/test |
buildkite test this |
* Pass go test flags to integration tests * Update docs/test-framework-dev-guide.md * Add clarification about ExtraFlags and RunExpr ordering in devtools.GoTest --------- Co-authored-by: Shaunak Kashyap <ycombinator@gmail.com> (cherry picked from commit e54b0a2)
* Pass go test flags to integration tests * Update docs/test-framework-dev-guide.md * Add clarification about ExtraFlags and RunExpr ordering in devtools.GoTest --------- Co-authored-by: Shaunak Kashyap <ycombinator@gmail.com> (cherry picked from commit e54b0a2) Co-authored-by: Paolo Chilà <paolo.chila@elastic.co>
What does this PR do?
Why is it important?
It allows to propagate go test flags to the actual go test command allowing for finer control over the test execution.
The
-test.short
is also important for allowing a quicker execution for PRs, for example while maintaining a full integration test run in other contexts.Checklist
[ ] I have made corresponding change to the default configuration files[ ] I have added tests that prove my fix is effective or that my feature works[ ] I have added an entry in./changelog/fragments
using the changelog tool[ ] I have added an integration test or an E2E testAuthor's Checklist
How to test this PR locally
Try to run integration tests (both locally and remotely) with some custom go test flags. There are some examples listed in the dev-guide, for example:
We pass a
-test.run
flag along with the names of the tests we want to run in ORRelated issues
Use cases
Screenshots
Logs
Questions to ask yourself