This repository has been archived by the owner on Jan 18, 2021. It is now read-only.
[Tests-Only] Implement separate expected-failures files for OC and EOS storage #444
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
phil-davis
force-pushed
the
create-expected-failures-on-EOS-storage
branch
from
5b58547 to
02264a5
Compare
phil-davis
force-pushed
the
create-expected-failures-on-EOS-storage
branch
from
02264a5 to
719c96c
Compare
individual-it
approved these changes
Aug 18, 2020
|
Merging this. This is also in cs3org/reva#1083 for It is very easy to adjust this system if someone wants/needs to. |
|
The related |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
In preparation for running API acceptance tests with EOS storage, have 2 expected-failures files. These can contain the expected-failures on each storage.
Note: the 2 files will have many scenarios listed that are the same, for things that fail on both OC and EOS storage. IMO that is OK, because as things get fixed they might get fixed on one storage first, and then the other. So the lists can be reduced independently when needed.
If we find that it would be better to have a common-expected-failures.txt and 2 smaller expected-failures files for specific OC and EOS storage then we can do that. But it will require changes to the core
run.shscript to support combining multiple expected-failures files.If this PR is OK then I will do similar in
owncloud/ocisandcs3org/reva