XMage Automatic / Nightly Builds

[atomicinf]

Can't wait for the next dev build to get that critical bugfix?
Too hard to wind your way around Maven?

Try new XMage automatic and nightly builds!

Where can I find these?

Automatic and nightly builds can be found at http://averyradio.caltech.edu/mage-nightly/
Build statuses can be reviewed at http://averyradio.caltech.edu:8086

Every 30 minutes, Jenkins checks to see if there were changes in GitHub.
If there was, Jenkins will schedule an automatic build.

Additionally, every day around 00:00 UTC, a build is scheduled whether or not a GitHub change happened.
These are the nightly builds.

Jenkins runs through the entire test suite as part of the build, so each build currently takes around 30 minutes.
The build status page reflects the health of the last automatic / nightly build, and links to detailed build reports.

Which build should I use?

The automatic build is the latest and greatest 'bleeding-edge' build.
When a change enters GitHub, an automatic build will have that change in less than an hour.
Use these if you want to test something before the nightly goes out.

The nightly build is more regularly scheduled, so might be more suitable if you're trying to get a bunch of friends on the same version for a play session.
Also, if you're running a server, picking a convenient nightly might be the best choice, instead of tracking automatic builds as they become available.

Other Information

The nightly and automatic builds are provided as a shared public resource.
Please do your part to help preserve their availability.

Older nightly and automatic builds may be deleted in the future.

[atomicinf]

Builds between 2013-11-25 and 2013-12-03 were being wonky for some reason.
Updated Jenkins and reran everything and things look fine for now.

I'll keep an eye on things to see what's going on.

[atomicinf]

Removed all builds from 2013 to save disk space.

The build process appears to have been stable for the last few weeks.

[atomicinf]

Both automatic and nightly builds were hanging for 6 days, which is why there haven't been new builds in that time.
Turns out the automatic build was sticking on org.mage.test.cards.single.IncreasingCardsTest (commit 6fe430ec) for some bizarre reason.

Automatic builds are working again so we should be all good.

[North]

It's very nice to see there is a Jenkins for MAGE. Very nicely done atomicinf.

At some point I tried to maintain a Sonar instance for MAGE and try to improve code quality but one could get lost in the large sea of false positives (not to mention the sonar build took quite a while and Sonar itself ate a lot of system resources.).

[atomicinf]

Automatic build #284 (started March 12 17:12 UTC) ended up generating almost 5GB of logs from org.mage.test.cards.abilities.oneshot.sacrifice.MorticianBeetleTest apparently generating neverending ClassCastExceptions.

Code: Select all

java.lang.ClassCastException: org.mage.test.player.TestPlayer cannot be cast to
mage.filter.predicate.ObjectSourcePlayer
        at mage.filter.predicate.other.PlayerPredicate.apply(PlayerPredicate.jav
a:41)
        at mage.filter.predicate.Predicates$AndPredicate.apply(Predicates.java:1
72)
        at mage.filter.FilterImpl.match(FilterImpl.java:63)
        at mage.filter.FilterPlayer.match(FilterPlayer.java:68)
        at mage.target.TargetPlayer.canChoose(TargetPlayer.java:99)
        at mage.target.Targets.canChoose(Targets.java:132)
        at mage.abilities.AbilityImpl.canChooseTarget(AbilityImpl.java:661)
        at mage.abilities.SpellAbility.canActivate(SpellAbility.java:109)
        at mage.players.PlayerImpl.canPlay(PlayerImpl.java:1730)
        at mage.players.PlayerImpl.getPlayable(PlayerImpl.java:1776)
        at org.mage.test.player.TestPlayer.priority(TestPlayer.java:104)
        at mage.game.GameImpl.playPriority(GameImpl.java:971)
        at mage.game.turn.Step.priority(Step.java:88)
        at mage.game.turn.Phase.playStep(Phase.java:198)
        at mage.game.turn.Phase.play(Phase.java:115)
        at mage.game.turn.Turn.play(Turn.java:132)
        at mage.game.GameImpl.playTurn(GameImpl.java:626)
        at mage.game.GameImpl.play(GameImpl.java:597)
        at mage.game.GameImpl.start(GameImpl.java:566)
        at org.mage.test.serverside.base.CardTestPlayerBase.execute(CardTestPlayerBase.java:163)
        at org.mage.test.cards.abilities.oneshot.sacrifice.MorticianBeetleTest.testSacrifice(MorticianBeetleTest.java:31)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at ...


This would of course eventually consume our (extremely large) NFS backing storage, but to my surprise the local VM storage was exhausted first. It turns out Jenkins generates temporary files in /tmp (apparently from deferring output to stderr and stdout) that ballooned to consume all available space absolutely everywhere.

As a side effect no builds could proceed since the Jenkins instance currently uses local VM storage for its workspace.

I've verified that the build process currently works properly. In the meantime I'm looking through the VM filesystem to see if any other large files got deposited; cleaning out the 5GB used in /tmp didn't free as much local VM storage as I was expecting.

[LevelX]

Automatic build #284 (started March 12 17:12 UTC) ended up generating almost 5GB of logs from org.mage.test.cards.abilities.oneshot.sacrifice.MorticianBeetleTest apparently generating neverending ClassCastExceptions.

Code: Select all

java.lang.ClassCastException: org.mage.test.player.TestPlayer cannot be cast to
mage.filter.predicate.ObjectSourcePlayer
        at mage.filter.predicate.other.PlayerPredicate.apply(PlayerPredicate.jav
a:41)
        at mage.filter.predicate.Predicates$AndPredicate.apply(Predicates.java:1
72)
        at mage.filter.FilterImpl.match(FilterImpl.java:63)
        at mage.filter.FilterPlayer.match(FilterPlayer.java:68)
        at mage.target.TargetPlayer.canChoose(TargetPlayer.java:99)
        at mage.target.Targets.canChoose(Targets.java:132)
        at mage.abilities.AbilityImpl.canChooseTarget(AbilityImpl.java:661)
        at mage.abilities.SpellAbility.canActivate(SpellAbility.java:109)
        at mage.players.PlayerImpl.canPlay(PlayerImpl.java:1730)
        at mage.players.PlayerImpl.getPlayable(PlayerImpl.java:1776)
        at org.mage.test.player.TestPlayer.priority(TestPlayer.java:104)
        at mage.game.GameImpl.playPriority(GameImpl.java:971)
        at mage.game.turn.Step.priority(Step.java:88)
        at mage.game.turn.Phase.playStep(Phase.java:198)
        at mage.game.turn.Phase.play(Phase.java:115)
        at mage.game.turn.Turn.play(Turn.java:132)
        at mage.game.GameImpl.playTurn(GameImpl.java:626)
        at mage.game.GameImpl.play(GameImpl.java:597)
        at mage.game.GameImpl.start(GameImpl.java:566)
        at org.mage.test.serverside.base.CardTestPlayerBase.execute(CardTestPlayerBase.java:163)
        at org.mage.test.cards.abilities.oneshot.sacrifice.MorticianBeetleTest.testSacrifice(MorticianBeetleTest.java:31)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at ...


This would of course eventually consume our (extremely large) NFS backing storage, but to my surprise the local VM storage was exhausted first. It turns out Jenkins generates temporary files in /tmp (apparently from deferring output to stderr and stdout) that ballooned to consume all available space absolutely everywhere.

As a side effect no builds could proceed since the Jenkins instance currently uses local VM storage for its workspace.

I've verified that the build process currently works properly. In the meantime I'm looking through the VM filesystem to see if any other large files got deposited; cleaning out the 5GB used in /tmp didn't free as much local VM storage as I was expecting.

Yes, there was a casting problem for 2-3 days. But now all should build again correctly.
Regards

[atomicinf]

Some hiccups with the build server have been resolved:

• A h2.mv.db file was eating all available local scratch space. Clearing the workspace resolved this.
• Maven was complaining about memory, so some more was provisioned.

Some of the builds between May 26 and now might be 'polluted', so don't rely on them.

[gabriele83]

I used to check on averyradio.caltech.edu:8086/job/MAGE Nightly/changes the changes of the nightly builds, but that page isn't accessible anymore.
Is there a place to check for nightly builds changelogs?

[atomicinf]

Build VM had melted two weeks ago and never told me. Restarted the VM; I think the server is in good shape again for now (at least manual forcing of the nightly build produces a build).

Nightly #494 should be a good build; #493 didn't finish, but has the changelog since #492.

[gabriele83]

The page http://averyradio.caltech.edu:8086/job/ ... ly/changes is offline again.
It has been at least 3 days.

[atomicinf]

Jenkins got killed by an OOM condition and I couldn't discover this until I remembered how to log in to the VM again.
I'm watching the build closely to see whether the VM needs more memory.

I might not be able to keep this service running for much longer because of the limited time I have on hand and the limited access I might have to this particular VM host in the future.
If Jenkins decides to break again in the distant future then I might not be available to bring it back up.

If you find a CI service useful for this project then you might consider provisioning a replacement...

[Finbez]

There hasn't been a new build since Oct. 1 even though there have been github changes? What's up with that?

[atomicinf]

OOM killer ate Jenkins again after a week of normal operation. I've provisioned some extra RAM, we'll see if that staves off the problem for a while.

[Finbez]

Poor Jenkins

Do these builds not include new cards as well? None of the C15 cards are in.