Config travis CI or another free CI
Zardoz89 opened this issue · comments
Config a travis CI, so could run the unit tests on every PR.
With travis, and getting some ideas from vibed configuration, could be something similar to this :
.travis.yml
language: d
dist: xenial
branches:
only:
- master
# Enable core dumps
before_script:
- ulimit -c unlimited -S
- sudo mkdir /cores/ && sudo chmod 777 /cores/
- echo "/cores/%E.%p" | sudo tee /proc/sys/kernel/core_pattern
after_failure:
- ./scripts/core-dump.sh
d:
# order: latest DMD, oldest DMD, LDC/GDC, remaining DMD versions
# this way the overall test time gets cut down (GDC/LDC are a lot
# slower tham DMD, so they should be started early), while still
# catching most DMD version related build failures early
- dmd-2.091.0,dub
- dmd-2.090.1,dub
- dmd-2.089.0,dub
- ldc-1.18.0,dub
- ldc-1.17.0,dub
- dmd-beta,dub
matrix:
include:
- d: dmd
script: ./travis-ci.sh
travis-ci.sh
#!/bin/bash
set -e -x -o pipefail
# test for successful release build
dub build -b release --compiler=$DC
dub clean --all-packages
# test for successful 32-bit build
if [ "$DC" == "dmd" ]; then
dub build -b release --compiler=$DC --arch=x86
dub clean --all-packages
fi
# Run unit tests
dub test --compiler=$DC
We desperately need this. I think you can test this out in a fork, or do you need my help? I will try to find the time to look at failing unit tests.
I could try on a fork, but you eventually need to enabled Travis CI on the main repo.
Right, I forgot about that. I'll see what I can do.
I'm ready to PR this two files, but there is a unit test failing :
Performing "unittest" build using dmd for x86_64.
pegged 0.4.5-beta.1+commit.6.ga0ab44a: building configuration "pegged-test-default"...
Linking...
Running ./pegged-test-default
pegged/peg.d(3580): [unittest] unittest failure
core.exception.AssertError@pegged/peg.d(3580): unittest failure
----------------
??:? _d_unittestp [0x2a413cd]
pegged/peg.d:3580 void pegged.peg.__unittest_L3563_C1() [0x268f8fd]
??:? void pegged.peg.__modtest() [0x2a2cfdf]
??:? int core.runtime.runModuleUnitTests().__foreachbody2(object.ModuleInfo*) [0x2a56224]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)).__lambda2(immutable(object.ModuleInfo*)) [0x2a38653]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))).__foreachbody2(ref rt.sections_elf_shared.DSO) [0x2a48fcb]
??:? int rt.sections_elf_shared.DSO.opApply(scope int delegate(ref rt.sections_elf_shared.DSO)) [0x2a49538]
??:? int rt.minfo.moduleinfos_apply(scope int delegate(immutable(object.ModuleInfo*))) [0x2a48f59]
??:? int object.ModuleInfo.opApply(scope int delegate(object.ModuleInfo*)) [0x2a38625]
??:? runModuleUnitTests [0x2a56061]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).runAll() [0x2a43e14]
??:? void rt.dmain2._d_run_main2(char[][], ulong, extern (C) int function(char[][])*).tryExec(scope void delegate()) [0x2a43da0]
??:? _d_run_main2 [0x2a43d08]
??:? _d_run_main [0x2a43a85]
/home/travis/dlang/dmd-2.091.0/linux/bin64/../../src/druntime/import/core/internal/entrypoint.d:29 main [0x250eee5]
??:? __libc_start_main [0x7f1491df982f]
1/4 unittests FAILED
Thanks. Do you use dub test for that? If I do that on Windows, I get
Generating test runner configuration 'pegged-test-default' for 'default' (library).
Performing "unittest" build using C:\D\dmd2\windows\bin\dmd.exe for x86_64.
pegged 0.4.5-beta.1: building configuration "pegged-test-default"...
---
ERROR: This is a compiler bug.
Please report it via https://issues.dlang.org/enter_bug.cgi
with, preferably, a reduced, reproducible example and the information below.
DustMite (https://github.com/CyberShadow/DustMite/wiki) can help with the reduction.
---
DMD v2.090.1-dirty
predefs VibeCustomMain Have_pegged DigitalMars Windows CRuntime_Microsoft CppRuntime_Microsoft LittleEndian D_Version2 all D_SIMD D_InlineAsm_X86_64 X86_64 Win64 D_LP64 unittest assert D_ModuleInfo D_Exceptions D_TypeInfo D_HardFloat
binary C:\D\dmd2\windows\bin\dmd.exe
version v2.090.1-dirty
config C:\D\dmd2\windows\bin\sc.ini
DFLAGS -IC:\D\dmd2\windows\bin\..\..\src\phobos -IC:\D\dmd2\windows\bin\..\..\src\druntime\import -L/OPT:NOICF
---
core.exception.OutOfMemoryError@src\core\exception.d(647): Memory allocation failed
If I revert to af79adb this passes. Can you try that? If successful, I will reverse-commit b1c5adf, that should fix it.
Yes, I use dub test on Linux . I don't get a OutOfMemory, but a test case fails.
core.exception.AssertError@pegged/peg.d(3580): unittest failure
I can try to config AppVeyour (Windows CI server) to test on Windows.
I understand. What I want to know is whether your failures are also caused by #269. So if you could git checkout af79adb9f (which is the commit before that merge) and do the test again, then I'll know what to revert.
I can try to config AppVeyour (Windows CI server) to test on Windows.
That would be awesome as well, but most important is to find the commit where the tests started failing.
@PhilippeSigaud As it turned out, some unit tests have started failing. This may well be due to me merging a PR that was not properly tested, apologies for that. @Zardoz89 is helping us to set up automated testing of PRs which should prevent that in the future. However, I don't have the privileges to enable CI on Pegged. Do you have the time to look into that yourself, or do you prefer to up my privileges? Thanks!
Travis-CI is working!
However it also starts a new run upon edits of the wiki, I noticed. There's probably a way to disable that.
I'm also curious if the build status of PRs will be shown and if this blocks PRs with failing unit tests from being merged, or whether additional steps need to be taken to make that happen.
Wiki is on a hidden git branch. I need to take a look to the documentation to see if I can make ignore these branch.