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

Make doctests part of Pkg.test("Oscar") #1768

Merged
merged 7 commits into from
Nov 28, 2022
Merged

Make doctests part of Pkg.test("Oscar") #1768

merged 7 commits into from
Nov 28, 2022

Conversation

thofma
Copy link
Collaborator

@thofma thofma commented Nov 25, 2022

This allows for the downstream testing in our upstream packages GAP, Hecke, Polymake, etc., to also run the doctests by default (the downstream tests are run by default on julia version 1.6, so we are good in this regard).

A minor disadvantage is that the default julia version for https://github.com/oscar-system/OscarDevTools.jl and the Oscar
doctest julia version need to be kept in lockstep.

(In an ideal world, we would make the doctests julia version agnostic and then these remarks about versions would all be unnecessary.)

CC: @fingolfin @benlorenz

@thofma thofma changed the title Make doctests part of Pkg.test() Make doctests part of Pkg.test("Oscar") Nov 25, 2022
@benlorenz
Copy link
Member

We do run the Oscar doctests already for the Singular and Polymake OscarCI tests, they failed e.g. here.

@thofma
Copy link
Collaborator Author

thofma commented Nov 25, 2022

Ah, that would also be an option. At the moment all those config files need to be updated across all packages once we change the Oscar doctest julia version?

Does speak something against doing it directly in Pkg.test()? Should also make it faster since then the doctests are run in the same julia session.

test/runtests.jl Outdated Show resolved Hide resolved
@fingolfin
Copy link
Member

I see no obvious downsides (we also do this for GAP.jl). Perhaps @benlorenz can think of some?

On the upside, it makes ]test Oscar more comprehensive.

@fingolfin
Copy link
Member

Tests fail due to some actual (minor) issues. I've pushed a fix (hopefully)

Copy link
Member

@benlorenz benlorenz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the main reason for this should not be the OscarCI downstream tests as we already have code for that in place which is working fine (and I think also reasonably easy to add to any repository).
I prefer to have different test-steps separate in the CI to make it easier to spot where a failure occurs, and also to make it easier to spot that the tests are running correctly. With the current setup I can directly see when the doctests are running for a job and when they are skipped. With this PR I would need to open the job log for the tests block, scroll to somewhere in the middle (after the installation / precompilation but before the other tests) and look for some @info block.

At least, I think we should swap the tests and run the doctests after the proper testsuite, which (at least in theory) should contain the more specific and more reliable tests that make it easier to pinpoint any failure. Parsing failures in the doctests is in my opinion way more annoying than parsing normal test failures.

PS: Just recently I did notice that the Run tests-step was running in about 10 minutes instead of 35 minutes because of many accidentally disabled tests. Including the doctests in that step would have made it less likely to be spotted that way, I could have blamed it on some of the usual fluctuations in the github actions performance instead.

test/runtests.jl Outdated Show resolved Hide resolved
@benlorenz
Copy link
Member

Ah, that would also be an option. At the moment all those config files need to be updated across all packages once we change the Oscar doctest julia version?

Currently yes, but we could probably put that version number in an environment variable instead which is set by OscarDevTools.jl, then we can just write it once in that repo (or we might even parse it from some file in the oscar repository).

@thofma
Copy link
Collaborator Author

thofma commented Nov 26, 2022

I have no strong opinion. I am also happy to just amend the OscarCI.yml in the other packages and leave everything as is.

It is just a bit odd in my opinion, that for the purpose of coverage we count also the doctest(Oscar) run, but we do not consider it part of the official tests. I believe it would simplify the development, since no one would need to remeber Oscar.doc_build(;doctest = true) for running the doctests (in yet another julia session).

@benlorenz
Copy link
Member

benlorenz commented Nov 26, 2022

I would be fine with running the doctests within the normal tests (but please move them after the other tests), and using something like && !haskey(ENV,"oscar_run_doctests") (or some other variable name) to skip them in the CI where we want to run them separately.

Also, I think it would be preferable to cover all code with normal tests as this makes sure that it runs correctly with all julia versions.

@thofma
Copy link
Collaborator Author

thofma commented Nov 26, 2022

Agreed. I will make the changes.

thofma and others added 3 commits November 26, 2022 20:53
Co-authored-by: Benjamin Lorenz <benlorenz@users.noreply.github.com>
Co-authored-by: Max Horn <max@quendi.de>
@thofma
Copy link
Collaborator Author

thofma commented Nov 26, 2022

Thanks for your feedback. I have moved the doctests to the end.

@benlorenz
Copy link
Member

Thanks for your feedback. I have moved the doctests to the end.

Thanks! Fixes for the doctests are (almost) ready to merge in #1769 (it will merge into this PR here).

* tests: reset abelian_closure variable name after printing test

* tests: StraightLinePrograms put tests in submodule to avoid polluting main namespace too much
@thofma thofma merged commit cbd47bc into master Nov 28, 2022
@thofma thofma deleted the th/doctest branch November 28, 2022 16:33
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

Successfully merging this pull request may close these issues.

3 participants