Skip to content
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

[2/2] Make k6 cloud run --local-execution upload test archive #3931

Merged
merged 12 commits into from
Sep 13, 2024

Conversation

oleiade
Copy link
Member

@oleiade oleiade commented Sep 4, 2024

What?

This Pull request modifies the behavior of the k6 cloud run command when using the --local-execution mode. It makes uploading the test archive to the cloud a default. This is meant to support our internal efforts to improve the UX of our cloud offering.

This Pull Request also adds support for an additional --no-archive-upload flag to the k6 cloud run command, which enables users to prohibit uploading their test archive to our cloud.

Review

Archive upload

Following a recently published change in our platform, creating test runs now supports providing the test archive along the test run parameters. To provide an archive when creating a test run, the request is expected to be a multipart form instead of the traditional JSON body. Creating test runs without archives does not change and works as before. To support this change you will find that we had to modify some of the behavior of the cloud API client CreateTestRun method.

Configuration aspects

We developed this PR hand-in-hand with @joanlopez and particularly struggled to set up its configuration aspects. We took the approach that felt the most convenient and practical to us, in lack of a better approach. If you have ideas or insights on how to handle that particular part specifically, please let us know 👍🏻

Checklist

  • I have performed a self-review of my code.
  • I have added tests for my changes.
  • I have run linter locally (make lint) and all checks pass.
  • I have run tests locally (make tests) and all tests pass.
  • I have commented on my code, particularly in hard-to-understand areas.

Related PR(s)/Issue(s)

#3904

@oleiade oleiade added this to the v0.54.0 milestone Sep 4, 2024
@oleiade oleiade self-assigned this Sep 4, 2024
@oleiade oleiade changed the base branch from master to new_cloud_run_local_execution September 4, 2024 14:16
@oleiade oleiade force-pushed the cloud_run_local_execution_upload_archive branch 2 times, most recently from a6082ee to f99b7ad Compare September 4, 2024 15:43
@oleiade oleiade changed the title [2/2] Implement the --local-execution mode for k6 cloud run [2/2] Make k6 cloud run --local-execution upload test archive Sep 5, 2024
@oleiade oleiade marked this pull request as ready for review September 5, 2024 14:52
@oleiade oleiade requested a review from a team as a code owner September 5, 2024 14:52
@oleiade oleiade requested review from mstoykov and joanlopez and removed request for a team September 5, 2024 14:52
@oleiade
Copy link
Member Author

oleiade commented Sep 5, 2024

Heads-up I tried to run the tests on my windows machine, and I can't reproduce the issue that's reported by the tests, if you folks have any ideas, I'll take it 🙇🏻

Base automatically changed from new_cloud_run_local_execution to master September 10, 2024 14:37
@oleiade oleiade force-pushed the cloud_run_local_execution_upload_archive branch from 044d6f2 to 4d2636d Compare September 10, 2024 15:10
@oleiade
Copy link
Member Author

oleiade commented Sep 11, 2024

The tests are now green. There is a test in the cloudapi package that's very flaky on windows because it expects log lines in a given order, and is time based.

I created a dedicated PR (#3943) to try and cater to that flakiness. Commit 4d2636d will, as a result, be dropped when merged.

In the meantime, please still consider this ready for review 🦾

cmd/cloud_run.go Outdated Show resolved Hide resolved
oleiade and others added 12 commits September 11, 2024 15:05
This commits aligns the handling of the --no-usage-report option in the
context of the k6 cloud run command with the following agreed upon
behavior:
* k6 cloud run --no-usage-report should ignore the flag, and make
sure we don't send the report.
* k6 cloud run --local-execution --no-usage-report  should take the
flag in consideration, and act accordingly.
Co-authored-by: Ivan <2103732+codebien@users.noreply.github.com>
@oleiade oleiade force-pushed the cloud_run_local_execution_upload_archive branch from 4f26cbe to b179a5d Compare September 11, 2024 13:05

exp := `{"name":"test","vus":0,"thresholds":null,"duration":0}`
assert.JSONEq(t, exp, string(b))
t.Run("creating a test run should succeed", func(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I am not a big fan of having a test with subtests jsut for grouping as you can do that with only the name of the test. Additionally it doens't add a level of identation.

In this case you also move a bunch of tests into subtests which makes the reviewing harder:(

Comment on lines +71 to +77
// WithArchive is an output that can receive the archive object in order
// to upload it to the cloud.
type WithArchive interface {
Output
SetArchive(archive *lib.Archive)
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the exact thing #3282 is trying to prevent - us keep adding "abstracitons" to the Output type that only makes sense for the cloud output and don't really make it better just make it do all the work.

IMO in this case k6 cloud run --local-execution probahly shouldn't just the output interface at all and use the cloud output directly.

Preferably it will make the test before cloud output Start gets called so it won't actually call CreateTestRun, but the k6 cloud run --local-execution does.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see your point, and I agree that it's a good idea. We actually considered a similar approach with @joanlopez. However, we encountered some challenges when trying to access the cloud output from the run entry point to handle the archiving and upload process as you described (before Start is called). Based on my understanding of your point, I think most of our implementation matches what you describe, besides indeed how we pass down "configuration" to the cloud output.

One of the reasons for this difficulty is that the cloud run command currently relies on the k6 run command internally but forces its output to cloud by overriding the loadConfiguredTest function. This setup makes it hard to achieve what you're suggesting without the workaround we've implemented here—adding an interface that the run command can detect and use to configure the cloud output.

Do you have any suggestions on how we could accomplish this (passing down a test archive to the cloud output) without the WithArchive interface and run command specific logic we've introduced?

Or, are you proposing that we should define the logic for local execution directly in the cloud run command, rather than relying on the run command? This would give us more flexibility and control, potentially avoiding changes to the output interface and the run command, as discussed in #3282, but would result in a much bigger and riskier change.

Please let me know if I’ve interpreted your suggestion correctly 🙇🏻

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately I don't have a 10 line fix that will make this possible.

As explained in the linked issue, this will only get worse and for logs AFAIK practically impossible to be done without refactoring how we run k6.

At this point it seems that the code in the "run" command will need to be refactored to be more composable and then reused in k6 cloud run --local-execution.

Looking at the cmd package it seems like it might be a good idea if the cmd packages deals more wiht the configuraiton and parsing of cli flags and less wiht actually running the k6 app. Currently both of those are very intertwined but that likely is not a good idea.

As mentioned privately I am okay with us merging this for the purposes of getting this released in 0.54.0, but will definitely prefer if work on the actual refactoring and working towards the mentioned issue goals of stop making the output interface just one big pile of one off editions and the cloud output in an omnipotent part of the code.

@@ -68,6 +68,13 @@ type WithThresholds interface {
SetThresholds(map[string]metrics.Thresholds)
}

// WithArchive is an output that can receive the archive object in order
// to upload it to the cloud.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// to upload it to the cloud.
// to upload it to the cloud.
// NOTE: This API is EXPERIMENTAL and may be changed, renamed or
// completely removed in a later k6 release.

@oleiade oleiade merged commit 31e3db7 into master Sep 13, 2024
22 checks passed
@oleiade oleiade deleted the cloud_run_local_execution_upload_archive branch September 13, 2024 17:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants