[docs] Doc about testing infra #215
Conversation
|
|
||
| # How to use testing infra | ||
|
|
||
| ## How test file looks like? |
There was a problem hiding this comment.
I'm not sure it is worth to reiterate what is effectively the contents of cranelift/filetests/README.md. Just link to that instead.
I would also perhaps consider contributing improvements to that and related files directly upstream (so long as they don't have much specific to zkasm.) I'm sure they'd appreciate more thorough docs.
There was a problem hiding this comment.
Hmm, don't think I wrote something better that cranelift docs have, but I replaced it by link to docs, thanks
docs/zkasm/test-infra.md
Outdated
|
|
||
| # CI policy | ||
|
|
||
| In CI we have two types of tests. One of them are written\generated by us, or adopted from existing tests and we expect that each PR passes 100% of this tests. Also, we run all tests in `filetests/filtests/runtests` as well, but don't expect all of them pass. If some test have `pass` status in main branch, and other status in the incoming branch, our CI will post a message with this diff in PR discussion, and author with reviewers will decide merge this PR or not. During project development, tests will gradually migrate from second category to the first one. |
There was a problem hiding this comment.
Can we instead disable/not enable tests that are not yet passing on zkasm and keep all enabled tests always green? This way we don't need any new CI machinery and conventions during PR review.
There was a problem hiding this comment.
I was thinking it will be nice to not disable test, but make it not mandatory and still know it's status. But maybe it is really not worth creating any new CI machinery
No description provided.