#techempower-fwbm

oh

right

ha ha

but if all green... much sexy

so true. Can't believe I got run-ci to work with pull requests that easily

thought it would be a fight, but I this is working really well

I think travis is tired of us lol - it was running 5 jobs concurrently at the start of #33, but now it seems to only be running 2 concurrently :-p

wahmp wahmp

maybe it's high-load time?

Yea...you west coasters are eating resources: http://status.travis-ci.com/

zomg, only 4 remaining before I get my sweet sweet green

yumyum

ONE MORE

GOGOGOGOGOGOGOo

NOOOOO

ERRORED!?

DAMN YOU HTTPLISTENER

huh?

oh damn

#looking...

NOOO WHAT IS MY LIFE!?

ba ha ha

it's fine, just turns out that HttpListener has no tests that can run on Travis (e.g. os and database os have to be linux)

windows*?

[FrameworkBenchmarks] hamiltont pushed 1 new commit to master: http://git.io/jiZ-IA

FrameworkBenchmarks/master c3360e4 Hamilton Turner: Remove HttpListener from Travis jobs...

time to rebase again?

already done ;-)

hawt

hmm, is that how we want to handle this situation?

oh btw I never heard the resolution: does travis now run all variants of tests?

example: undertow (default), undertow-mongodb, undertow-mysql, etc etc all in the same benchmark config?

No, I don't think it can support it

It only runs one of them

is there a good reason for that?

it prints out into the log which one it chooses

the most direct reason is that I only setup mysql inside travis

can we build in a tool flag to run "all test, not just default/named"

lawl?

you can't do mongodb?

or postgresql?

etc?

Probably can, but I haven't set it up yet

oh okay

well, that's what I'm getting at

yea

I see no reason to try and do them all

as we iterate the travis stuff, I think the next step would be supporting that

Yea, exactly

double-hot

oh, sorry - meant "I see no reason to not try and do them all"

double negative madness

you see good reason to try and do all

yes, that

seems like what I want to say

Ok, #36 is our winner

all bets in

Giving 10:1 on a full green

[travis-ci] hamiltont/FrameworkBenchmarks branch 'cakephp-patch' errored (Hamilton Turner)

[travis-ci] Build 183 took 111 min 38 sec. See http://travis-ci.org/hamiltont/FrameworkBenchma...

Oh sorry, that's me

DAMN YOU TRAVIS-CI

it's actually my fork

that's a lot of minutes

lawl

k

yea...

they count all CPU time

so it's not wall time, but still

a lot of minutes indeed

yeah

getting back to httplistener

let's not simply disable it - can we improve the situation so that its job reports pass because there is nothing to run?

that way, if they add a mono thing to their benchmark_config in the future, the current one will still "pass" because there is nothing to run, but the mono build will still try and run

(at some future date when we are running all the tests of a given dir)

Perhaps. Can it run on linux?

I think that's why it errored

Not because of mysql

Yea, it has no test taht can run standalone on linux

So travis can't help us here

right

but right now, run-tests actively fails because the test it's trying to run specifies "OS=windows" and our OS is set (by default) to linux

what if we changed it to have an exit code of 0 in that case - nothing was run so nothing failed

that would allow HttpListener to, in the future, have an additional test where it runs on Mono and specifies linux as the os

Oh hmm

I see your point

Sure

Although

perhaps it's better to add it back into travis if linux support is added

because if I add it in now...

it's going to waste time and resources for every build

launching a new VM, just to return pass

Seems an easy thing to not forget to add - when someone puts in a PR to add linux support and travis doesn't run, that's a pretty good reminder to add it to the .travis.yml file

I'm confused

Letting HttpListener run on Travis is basically a big waste of time and compute resources

"big"?

basically, you're saying that HttpListener simply won't have a travis job

lookat at an extra 30 seconds to 5 minutes (depending on travis' speed) for that HttpListener job

we are looking at an extra*

and if in the future a mono test is added, it will be on the head of whoever is handling pull requests to know and add the travis job, but only for the mono test

I get that

Yea, and it's as simple as adding one line here - https://github.com/TechEmpower/FrameworkBenchma...

but I think that time spent in the general case for the tradeoff of needing less hand-holding (and edge-cases) during merging pull request is a good trade-off

okay - but what do we do after we implement "run all tests for this directory"?

and HttpListener has a mono test

Just add that one line?

but the windows test will fail

like it did 10m ago

Nope

and we will have to add in the logic I mentioned about "if benchmark_config.os != host.os, pass" anyway

See https://github.com/TechEmpower/FrameworkBenchma...

haha

sigh

it only errored because it found no tests to run

oh

hmmm

okay, you win

*yay

In all seriousness

I think its really easy to add back in

and I think it will be added by the first person who wants to try to use mono for HttpListener

because it's really useful to have travis chugging along

agreed

and I'm tired of their already-slow website

I didn't realize what you had already done behind the curtain

Each time I see the "new framework" title in a pull request I worry about slowing the website down more :-/

would be nice if they had an open-source version that we could install and dedicate full resources

Travis?!

they do :-)

It's entirely open source

okay, hold up

let's back up a sec

because we have hard

ware

hardware

ba ha ha

hardware in droves

yea

so...

tasks someone with setting that up

and there you go

task*

maybe we make an issue along the lines of "set up OUR travis box and configure TFB to use it instead of travis-proper"

do we get the hot interface and webhooks with github and everything?

I beliieve it's the whole shebang, but you'd have to get someone to look into it

I've never used anyhting but the official stuff

fuuuuuuu