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

[24.0] Backport #16094 Missing outputs should be recorded as test errors #17873

Conversation

bernt-matthias
Copy link
Contributor

@bernt-matthias bernt-matthias commented Apr 1, 2024

Ref: #16094

How to test the changes?

(Select all options that apply)

  • I've included appropriate automated tests.
  • This is a refactoring of components with existing test coverage.
  • Instructions for manual testing are as follows:
    1. [add testing steps and prerequisites here if you didn't write automated tests covering all your changes]

License

  • I agree to license these and all my past contributions to the core galaxy codebase under the MIT license.

bernt-matthias and others added 11 commits April 1, 2024 17:36
from planemo the verify_tool function is called from
[within an try-except block](https://github.com/galaxyproject/planemo/blob/1aa3eb05a97ad20c0be6f6560ab5cec090e76612/planemo/engine/galaxy.py#L109)
which silently catches any exception.

Thus any exception raised from within verify_tool will not be
detected, i.e. the assertion needs to be moved into
`_verify_outputs` (which also seems to make sense by name)
in order to make verify_tool record the problem properly.
thereby we implicitly make the assumption that a test needs to produce
an output

also make message more specific
otherwise the tool test will just return a list out of bounds exception
which is unclear to the user
Co-authored-by: Marius van den Beek <[email protected]>
then it might be clearer what's going on here
@jdavcs
Copy link
Member

jdavcs commented Apr 1, 2024

@bernt-matthias Would you like to use this one instead of #16094? That one has one extra commit. If so, we can rename this PR, merge it and close 16094 (I assume the extra commit would be added here?). Otherwise, we could just retarget 16094 and merge it into the release_24.0 branch, and close this one. Or are they different? (in which case we can merge both)

@bernt-matthias
Copy link
Contributor Author

Lets go with #16094 and retarget .. I got confused.

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

Successfully merging this pull request may close these issues.

2 participants