Replace travis with a more flexible vibe.d-written solution

[etcimon]

I can dedicate a Xeon server with 32gb of RAM (ECC) with VMWare running on Mac OS X, FreeBSD, Linux (Fedora) and Windows simultaneously each with a high-RAM (4gb) environment open 24/7. All I'd need is a build tester installed on each OS. I'd plan on making one but it wouldn't be up until 2015, so I'll put this on the table for anyone interested.

• Written entirely in D code and vibe.d, no configurations at all.
• Interfaces with github API, using a timer to query the most recent commit every 10 seconds
• When a new commit is found, runs D commands
• Reports the logs to a central server API (implemented with mongodb?).
• Updates itself using its github repository, dub and shell/powershell commands

The advantage would be persistence of the environment and fast build times. This means it can keep multiple version of DMD, GDC and LDC builds up-to-date on the server.

The central status server would be as follows:

• Hosted on the code.dlang.org website with a travis-like page
• Shows a table with the build# and logs
• Provides a variable bytestream for a no-cache widget at a static address that indicates Fail/Success

Much care would have to be taken to write this in as few lines of codes as possible. The portability of D means the portable build tester also works with projects using C++ / nodejs / etc. on any kind of server

The travis system is embedded in github already, so another (simple) application would be designed to run in travis and proxy through to the real build environment (the central server) and show the linux-version logs (or any OS's failing log) and error code.

Each build tester would need its own repository though, appending -tester to the repo name maybe?

[ColdenCullen]

I love this idea. A cross-platform, optionally self-deployable tester would be an amazing opportunity for D.

That said, I would suggest against the no-configuration idea. Instead of having a separate repo for the tester, what if the dub.json file had a testScript property (or something similar), so that you could place a tester.d (or something similar) in the repo and just execute that. This gives you the simplicity of a config file, but the power of D. We could also provide a library to (optionally) assist in the testing process, such as providing a main method, and a harness to run certain stages of the test.

As far as using Travis as a passthrough goes, GitHub has a pretty sweet commit/branch status API, so we could probably just hook that up instead.

Also, if it hasn't come across already, I'd be extremely interested in helping to build this, so please keep me in the loop.

As a separate issue, if we do go with the testScript idea, I would suggest following in npm's steps and have a scripts object, that we could place test, preBuild, and postBuild in, rather that having preBuildCommands and postBuildCommands.

[mihails-strasuns]

I wanted to extend dub-registry with an API for reporting CI results ages ago but never got to actually implementing anything meaningful.

[etcimon]

As a separate issue, if we do go with the testScript idea, I would suggest following in npm's steps and have a scripts object, that we could place test, preBuild, and postBuild in, rather that having preBuildCommands and postBuildCommands.

NodeJS isn't a systems-level programming framework, so it doesn't have to deal with varying compilers/libraries/shared/static etc. This is the most significant problem for D's build system because the platform has to be clean after the dependencies are used, and it has to be able to upgrade/downgrade them to plenty of versions very quickly.

e.g. Running 5 different DMD/phobos/druntime versions on a single package needs to be possible fairly quickly.

So, there's plenty of possible test scenarios and we need to be able to cover them without it consuming hours.

The solution I've thought of (before moving on to a portable travis-tester utility), is to have a git-make utility. The idea is to have an API that has:

• A library of cross-platform global functions git_pull, git_checkout, git_branch_delete, dub_test, dub_build, etc.

For each possible dependency (gcc, cmake, libevent, phobos, curl, dmd, dub, etc) regardless of the language or framework it uses we'd have a base class (interface) with :

• Package name and repository name, with the git host address
• List of version numbers
• virtual method for changing versions
• virtual method for dependency building and resolving
• virtual method for build process
• virtual method for installation process
• virtual method for cleanup process
• a cache system based on building a git [repo]-cache branch with compiled objects and pulling from it

This git-make utility would then have a module for every dependency, which can be used as a cross-platform tool to build any git package on any platform (Mac, windows, linux, etc) using a git repository name and version tag or branch name.

This would allow the travis-like portable tester to use variable dependencies and version using git branches as cache and version changer. The goal is to take advantage of persistence, by avoiding to rebuild a clean slate and working with diffs instead.

[MartinNowak]

Any work that would get D on the supported language list of Travis-CI and drone.io would be better invested IMHO. Sure it's an interesting project but it's a huge effort to come up with a competing solution. Last but not least it's always extremely simple to fire up a Jenkins server.

[MartinNowak]

I am open to adding the D programming lang compilers to one of the boxes, are you able to help with the chef cookbooks?

Someone? https://github.com/travis-ci/travis-ci/issues/730#issuecomment-10620667

[etcimon]

Yes, it's definitely easier to support existing tools first. Although I think it would be a better addition to see an integrated solution that embeds nicely with the dub repository, with DMD/Phobos test versioning and history, so that we can still develop features / add packages to a project that has hard dependencies on an older set of DMD / Phobos versions. There's always new features/deprecations being added to DMD/Phobos minor iterations so package/test versioning history is quite a must-have.

[bearcherian]

Looks like someone started something for the cookbooks, but i don't see it in any current branch - travis-ci/travis-cookbooks@01e725208a755508529eec28f074f6bbef6c319f

[p0nce]

What I'd like even before CI is a server with DDoc generated from every package in code.dlang.org

[Geod24]

@p0nce : I'm currently working on #355 . Feel free to message me if you want to get involved. @etcimon : @braddr says he wanted to extend the scope of auto-tester.puremagic.com to test any D project (or not D), and D's auto tester already has year of man work invested in it.

[MartinNowak]

Can we close this for now?

[etcimon]

Wow this idea is 4 months old already, sure.