-
Notifications
You must be signed in to change notification settings - Fork 101
Add support for recording requests in integration acceptance tests #2720
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
Conversation
…sting of the feature itself
# hello, world\n base64 encoded in windows | ||
[[Repls]] | ||
Old = "aGVsbG8sIHdvcmxkDQo=" | ||
New = "[HELLO-WORLD]" |
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.
Where does this nuance show up?
I see the comment about newlines in the .wsignore
file, but shouldn't the output always be verbatim?
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.
but shouldn't the output always be verbatim?
The difference I believe is \n
vs \r\n
that's being printed on the console. I did not actually decode and inspect it byte by byte though. Running the base64 deserializer through both returns "hello, world(newline)"
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 get that. What I wonder is, where does the \n
or \r\n
come from, if the fs cat
command outputs file contents verbatim, and the input file doesn't have a newline.
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.
The input file here does have a newline. The one in volume-io file test does not, because the new line was hard to normalize in the API request payload.
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.
It's worth making this behave in a single way instead of accounting for the differences in the test itself.
We're likely seeing this: https://docs.github.com/en/get-started/git-basics/configuring-git-to-handle-line-endings
I suspect we can fix this by configuring everything under acceptance
to use eol=lf
.
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.
Good point, trying to address that in #2865.
## Why Based on feedback in #2720 (comment). We should always treat new lines in acceptance tests in windows as `\n`. This is important because the characters itself can be semantically important in tests. For example, an additional `\r` character in windows changes the upload payload if you are uploading the file's content to a workspace. ## Tests Existing workspace-io test should no longer need a custom override for windows.
Changes
This PR adds support for recording API calls made during an integration acceptance test by setting
RecordRequests = true
in the test.toml file.This PR adds a new struct
ProxyServer
which is a server that sits in between a client and a real Databricks workspace. Having a server in between allows us to record requests as they are sent to a real Databricks workspace in our integration tests.Why
Other than being a useful feature in itself, this also unlocks migration away from Terraform in DABs since we can now record the API requests made by Terraform and ensure that our custom library makes the same API requests in all cases.
Tests
A bunch of new acceptance tests for the new feature.