Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Use versioned sourceset for REST compat testing #78418
Use versioned sourceset for REST compat testing #78418
Changes from 11 commits
a29644b
afa5451
ef2b65b
4ddbae0
251433d
5ef319d
0cba9f0
0a6e178
1f4d065
69d2450
342516c
cd33601
23b8c62
cf7b457
b267512
cdf7dab
2a8fc87
00a15e1
e45d9a1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If we are having version-specific source sets, do we still need to capture the version here in the file path as well. As it is now we have files like
src/yamlRestTestV7Compat/resources/rest-api-spec/test/v7compat/foo/bar.yml
. We probably don't need to track the version twice now. Also begs the question whether we need this change in the first place if we are already managing per-version test resources. How will this affect backporting, etc?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.
src/yamlRestTestV7Compat/resources/rest-api-spec/test/v7compat/foo/bar.yml
uses a 4 part path to keept it from colliding with the actual v7test/foo/bar.yml
if it exists. (Both the real v7 tests and the custom test in this source set are on the same classpath, and there quite a bit of re-use of file names).v7compat
in the path is just a convention and included the v7 to help demark these are intended for compatibilty with v7. The fact this is just a convention and without any teeth (i.e. these would execute when master is v9) is a motivating factor for this PR.I can remove the
v7
from thev7compat
convention in this PR since I agree it doesn't make sense now. I think I could also remove this extra directory entirely and ensure uniqueness of the files between the two sources of tests (with validation in Gradle). Thoughts ?Since our REST compatilbity only supports 1 major version, these should never be backported and anything in this sourceset should be removed in the next major version.
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.
Yeah, I think that makes sense. It's just less stuff to try and keep in sync.
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.
example of failure:
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'm wondering if it might be better (and simpler) to implement this in the yaml testing framework code instead. It could be as simple as checking the result of the call to
add()
here and throwing an exception if it returnsfalse
.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.
These duplicate fails are not actually needed for this PR, but I realized while adding the custom duplicate check to the compat testing task, it would be good to add a duplicate check here too.
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 don't think this is necessary since
FAIL
is now the default behavior in Gradle 7.0 and later.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.
ah.. it is. gradle/gradle#15759 I will remove this.