Set up CI & make a new release

[jaberg]

@aldanor (#350) suggests a number of things, but burning issues would be:

• set up CI for key platforms
• address any failing tests

If we do this, make a release, then we can start on a lot of the other possible next steps.

[jaberg]

Made this a milestone, rather than an issue.

[jaberg]

#361 gets tests passing (skipping mongo).

[michaelmior]

I'm still seeing a failing test. I configured Travis CI on a branch in my fork. The test output is available on Travis.

[michaelmior]

Also, the tests seem flaky since different tests fail each time things run. As one other observation, I tried to get the IPython tests running but I see that the latest IPython has moved the parallel stuff to a separate package. Probably worth updating to use that. Possibly related to #215.

[jaberg]

Let's stomp these out - if you see a test fail keep track of it (gh issue?) so we can fix it even if it passes most of the time. Some tests may not have the random seeds locked down, and yet still pass e.g. 99% of the time. How to properly test such code is an interesting question, but in the interest of not confusing travisCI I think pinning a good seed is reasonable now.

…

On Mon, Feb 5, 2018 at 9:13 AM, Michael Mior ***@***.***> wrote: Also, the tests seem flaky since different tests fail each time things run. As one other observation, I tried to get the IPython tests running but I see that the latest IPython has moved the parallel stuff to a separate package. Probably worth updating to use that. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#355 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKdDMLFY4WCPIUXub6-F1PcenF3h4OEks5tRwyPgaJpZM4Rhmjv> .

[jaberg]

Oh - reading the fmin() docs reminded me of HYPEROPT_FMIN_SEED. The fmin calls in the tests were deliberately written without seeds so that this env variable could re-run the tests with different seeds. I'll put up a PR that sets this in travis config. On Mon, Feb 5, 2018 at 10:55 PM, James Bergstra <james.bergstra@gmail.com> wrote:

…

Let's stomp these out - if you see a test fail keep track of it (gh issue?) so we can fix it even if it passes most of the time. Some tests may not have the random seeds locked down, and yet still pass e.g. 99% of the time. How to properly test such code is an interesting question, but in the interest of not confusing travisCI I think pinning a good seed is reasonable now. On Mon, Feb 5, 2018 at 9:13 AM, Michael Mior ***@***.***> wrote: > Also, the tests seem flaky since different tests fail each time things > run. As one other observation, I tried to get the IPython tests running but > I see that the latest IPython has moved the parallel stuff to a separate > package. Probably worth updating to use that. > > — > You are receiving this because you modified the open/close state. > Reply to this email directly, view it on GitHub > <#355 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AAKdDMLFY4WCPIUXub6-F1PcenF3h4OEks5tRwyPgaJpZM4Rhmjv> > . >

[michaelmior]

@jaberg Do you want me to go ahead and merge as-is then and file issues for failing tests?

[jaberg]

@michaelmior sorry, but merge what? I've got a PR #363 to pin down the seed in Travis so that CI isn't flaky.

[michaelmior]

@jaberg When I last looked, Travis wasn't enabled at all. I see that's already been done :)

[maxpumperla]

@jaberg closing this as travis has been around for a while now and we've had a release.