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

tests: Test optional features #33

Open
jku opened this issue Jul 3, 2024 · 3 comments
Open

tests: Test optional features #33

jku opened this issue Jul 3, 2024 · 3 comments

Comments

@jku
Copy link
Member

jku commented Jul 3, 2024

Specification has a few optional features. This list is from memory so possibly not complete:

hashes & length in METAFILEs

The single-item dictionary in timestamp and the dictionary in snapshot may or may not contain hashes and/or length. We should check that at least both reasonable options are supported (neither hashes nor length included; and both hashes and length included)

Consistent snapshot

According to spec the "consistent snapshot" feature is SHOULD only. I don't think we're very interested in the "non-consistent" version: I think we should only possibly test it with security in mind -- but have no practical examples at the moment

EDIT: I believe all tests currently implemented require consistent snapshot. I think this is fine, in this aspect we'll be more opinionated than the spec itself: consistent_snapshot really makes much more sense. We should still accept an optional test for non-consistent snapshot... but it's not a priority

@jku
Copy link
Member Author

jku commented Aug 13, 2024

hashes/length: #131

@jku
Copy link
Member Author

jku commented Aug 26, 2024

hash algorithms is another unspecified thing (spec does not even recommend what to use): #170

keytypes are also similarly undefined #167

@jku
Copy link
Member Author

jku commented Aug 26, 2024

First, I'm not sure if we need both "xfails" and "optional features". Maybe we can first try to write all tests so "xfails" is enough and it's easy enough to configure even if there are multiple expected failures?

Assuming that is the case, a possible solution that would not require changes in the action API or CLI:

  • we could assume that if the client binary is /path/to/client then expected failures list may be found in /path/to/client.xfails

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant