oscar-system / oscardevtools.jl Goto Github PK
View Code? Open in Web Editor NEWTools for developing Oscar and for continuous integration
License: MIT License
Tools for developing Oscar and for continuous integration
License: MIT License
Running normal tests with depwarn=yes
is fine as they still succeed and only some additional output is printed. Normal doctests are run directly using doctest(Oscar)
(and not via Pkg.test
), so the default of depwarn=false
is applied here as well.
However, in Oscar there are some "fake doctests", e.g. https://github.com/oscar-system/Oscar.jl/blob/556be5ae27a4fe3d45dfd26e536101e535085d0b/test/Groups/group_characters.jl#L755. These are called via a doctest
command from the test job, and thus depwarn=yes
is set there. As the doctest compares output, the presence of deprecation warnings lets the tests fail, even though deprecation warnings shouldn't do that.
I really don't know if this can be avoided at all, and if the place to fix it is here in the way the tests are run, or in Oscar itself at the place where the fake doctests are called.
julia >= 1.3 can pass arguments to the test process by specifying the test_args::Union{Cmd, Vector{String}}
keyword arguments for Pkg.test
.
It would be great if the configuration toml would have a way to specify the arguments for the tests of an individual package. E.g.
[testoptions]
Hecke = ["short"]
The reason is that the Hecke tests are way too long to be useful for the upstream package testing. So I would like to limit them.
I can have a stab at it if we agree that this is a useful feature.
Right now to use this we copy & past the oscar.yml
file from here to each of our repositories and edit it as needed. Drawback is that tweaking anything in there now required updating several repositories. It can also be easy to miss difference between the different copies. And someone trying to understand the oscar.yml
has a lot on their plate.
We could create a GitHub Action (or multiple) to factor out some or even all of the duplicate code. E.g. right now, I think this sequence is repeated twice in our actions:
- name: re-using OscarDevTools checkout
if: github.repository == 'oscar-system/OscarDevTools.jl'
run: |
julia --project=oscar-dev -e "using Pkg;
Pkg.develop(PackageSpec(path=\".\"));
Pkg.instantiate();"
- name: fetch OscarDevTools
if: github.repository != 'oscar-system/OscarDevTools.jl'
run: |
julia --project=oscar-dev -e "using Pkg;
Pkg.add(PackageSpec(name=\"OscarDevTools\",version=\"0.2\"));
Pkg.instantiate();"
Well, this could be put into an action oscar-system/install-devtools
and then can be replaced by something like this:
- uses: oscar-system/[email protected]
Writing a simply GitHub Action (which basically acts like a "macro" that contains normal GH Actions YML, with a few parameters), is actually relatively simple. We did it for GAP, see e.g. here: https://github.com/gap-actions/setup-gap-for-packages -- the only thing that really matters there is the action.yml
which is mostly self-explanatory, I think. Of course adding a README, LICENSE, tests for the action we nice but not required. Nor is it required to put this into the marketplace.
Anyway, this is not urgent, I simply wanted to record this thought.
In AA, we test four packages (https://github.com/Nemocas/AbstractAlgebra.jl/blob/master/OscarCI.toml). Would it be possible to have the four tests in separate jobs? The problem we have at the moment is that the Oscar tests run first, but they might (and often do) fail for unrelated reasons. Then all the tests of the other packages are not run.
I am not sure we want to have separate jobs or handle it inside the julia command here: https://github.com/oscar-system/OscarDevTools.jl/blob/master/src/OscarCI.jl#L283
Thoughts?
Edit: Sorry, I just checked. The Oscar tests run last. But my problem is that I have to scroll through everything to spot which tests passed, which did not, and to find out which did not even run. I hope you get my point.
This issue is used to trigger TagBot; feel free to unsubscribe.
If you haven't already, you should update your TagBot.yml
to include issue comment triggers.
Please see this post on Discourse for instructions and more details.
If you'd like for me to do this for you, comment TagBot fix
on this issue.
I'll open a PR within a few hours, please be patient!
We should also run doctests of the involved packages: we just had a case where the regular tests worked, but a PR broke doctests of an upstream project.
One thing to remember for that is that usually our doctests require a specific Julia version; but it should be possible to deal with that (and I think basically Julia 1.6 is currently used for this by all our packages?)
[ We've discussed this before, elsewhere, I just wanted to note it down somewhere for easier reference -- so in particular I do not mean to say "why haven't you done this already" ! ]
Consider this scenario:
Ideally, we'd detect this situation: when doing tests for package A against release versions of packages B, C, ..., if the current version of A is not compatible with the latest versions of B, C, ... then don't run any tests and just mark the job as success (after all, there is no incompatibility).
I think the somewhat hard part may be to prevent Julia from downgrading packages B, C, ... to make things work.
Nemocas/AbstractAlgebra.jl#805 created 3^4 = 81 jobs, because there are four packages, each with master
, latest
and we also had a custom branch with the same name in every repository (on purpose).
I know there are different ways to handle this, but one thing that came to mind was that if I am working on package A on branch #bla, and dependency B has also a branch #bla, then restrict the version for testing B only to B#bla (or maybe B#bla and B#stable) and not to all three B#latest, B#master and #Bla.
This is just one suggestion. Happy to hear what you think about this.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.