Add continuous integration tests with SageMath (multi-platform)
See https://trac.sagemath.org/ticket/29091
Preview of a successful run on raspbian-buster-armhf-standard at https://github.com/mkoeppe/fplll/runs/805921434
I think a five hour wait time for CI is asking a bit too much. Also, this should be for FPyLLL not FPLLL?
You can configure it to run only on pull requests and tags, rather than on every commit. See commented out stuff at the beginning of the file.
Here's a better version. Does not use a private repository any more (gets a branch from trac.sagemath.org instead), runs on pull requests and tags only, and adds macOS testing (homebrew + conda)
Codecov Report
Merging #433 into master will increase coverage by
4.52%. The diff coverage isn/a.
@@ Coverage Diff @@
## master #433 +/- ##
==========================================
+ Coverage 68.54% 73.06% +4.52%
==========================================
Files 67 70 +3
Lines 4994 6549 +1555
==========================================
+ Hits 3423 4785 +1362
- Misses 1571 1764 +193
| Impacted Files | Coverage Δ | |
|---|---|---|
| fplll/pruner/pruner_optimize_tp.cpp | 35.00% <0.00%> (-65.00%) |
:arrow_down: |
| fplll/hlll.h | 58.97% <0.00%> (-41.03%) |
:arrow_down: |
| fplll/pruner/pruner_optimize.cpp | 66.00% <0.00%> (-34.00%) |
:arrow_down: |
| fplll/householder.h | 68.64% <0.00%> (-31.36%) |
:arrow_down: |
| fplll/pruner/pruner_cost.cpp | 73.11% <0.00%> (-26.89%) |
:arrow_down: |
| fplll/pruner/pruner_optimize_tc.cpp | 78.61% <0.00%> (-21.39%) |
:arrow_down: |
| fplll/pruner/pruner_util.cpp | 82.25% <0.00%> (-17.75%) |
:arrow_down: |
| fplll/pruner/pruner_prob.cpp | 92.42% <0.00%> (-7.58%) |
:arrow_down: |
| fplll/nr/nr_Z_d.inl | 0.00% <0.00%> (ø) |
|
| fplll/nr/nr_rand.inl | 100.00% <0.00%> (ø) |
|
| ... and 27 more |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing dataPowered by Codecov. Last update d10963a...b8ee002. Read the comment docs.
We've switched to GitHub Actions now. I'd be up for merging this triggered manually only, i.e. on workflow_dispatch.
We've switched to GitHub Actions now. I'd be up for merging this triggered manually only, i.e. on
workflow_dispatch.
Sounds good. Would you like me to update the pull request?
That would be great!
Oh, another thing: shouldn't this be against FPyLLL? Typically, we release new versions of FPLLL and FPyLLL together and the latter depends on the former.
Oh, another thing: shouldn't this be against FPyLLL? Typically, we release new versions of FPLLL and FPyLLL together and the latter depends on the former.
OK, I'll send you a pull request against fpylll and update this one. You can then decide whether you want both or only one of them.