Add Automated Builds With Drone

[zicklag]

Adds automated builds with Drone. I just saw that you use Jenkins, and if you would like to use that instead feel free to close this PR. I had just finished learning how to build for all platforms from Drone for my own project so I figured I'd dump it here if you were interested.

This configuration will automatically compile Evoli for 64bit Windows, Linux, and Mac and publish the built assets to a GitHub release whenever you create a new tag that starts with v.

There are a couple of optional things in the Drone config, such as the draft deployments on the release-draft tag and ignoring feature/* branches so that you don't double-build feature branch pull requests. If you have any questions just ask. I can tweak the configuration for whatever you need.

Also Drone is hosted for free for Open Source projects. :smiley:

[zicklag]

Windows and Linux builds successfully compile, you can download them from here.

• Linux: I've tested the Linux build and it works.
• Windows: The Windows build crashed on my old Windows machines, but that might be because of hardware or old OS's. It would be good if somebody with a newer windows machine could test it.
• MacOS: The MacOS build is failing, but I think that might not be because of my build script. If somebody could confirm that you can in fact build Evoli on Mac right now that would be good.

[khskarl]

Wow nice! Thanks for the contribution :). I tried compiling it in my macOS 10.13.6 + Rust 1.35 with no success.

   Compiling amethyst_core v0.5.0
   Compiling amethyst_assets v0.6.0
   Compiling amethyst_network v0.3.0
error[E0283]: type annotations required: cannot resolve `std::string::String: std::convert::AsRef<_>`
   --> /Users/khskarl/.cargo/registry/src/github.com-1ecc6299db9ec823/amethyst_assets-0.6.0/src/prefab/mod.rs:372:22
    |
372 |                 name.as_ref(),
    |                      ^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0283`.
error: Could not compile `amethyst_assets`.

Currently we are in the middle of migrating Evoli to Amethyst 0.11, which I'm able to compile (without the DebugLines pass). So we will probably finish the migration before merging this :).

[erlend-sh]

In light of this finding by @azriel91 that Drone doesn’t support Vulkan tests, where does that put us?

[zicklag]

It would mean you would either have to use a different CI provider for testing or that you would have to install Drone on a server that has the graphics device necessary to run the tests. Drone could still produce the automated builds that users can download, if you wanted to use it for that, but if you end up using something else for running the tests, then you might just want to use whatever that is to do the release builds as well.

[azriel91]

The reason I check if CI supports Vulkan is:

• I want to test some game logic
• The logic operates over entities with certain asset handles
• Part of loading those assets also loads textures, and textures mean we need the render bundle.
• amethyst_rendy backs onto gfx-hal, whose released version only supports Vulkan right now.

Alternatives to using CI agents with Vulkan support:

• Wait: gfx-hal has been having development to getting GL as a backend, I'm not sure how far along that is. When that is available, we can use XVFB, which integrated graphics cards on CI agents should handle (software renderer).

• Hack: Make amethyst::assets::Handle<_> constructable without actually loading the real asset -- should only be used in tests, can be behind a "test-support" feature.

• Don't test: Just skip tests that use graphical assets.

• Restructure Assets: Instead of having a hierarchical asset tree, keep a flatter asset structure.

  I have a single ID to the-root-of-the-asset-tree asset. Instead it could be single ID -> map of IDs for each sub-asset for that particular object. That way if the logic to be tested still operates over the top level ID, you don't necessarily have to load every sub-asset. Furthermore, the logic probably should operate over the sub-asset ID because it shouldn't need to know about the top level one (given it never needed to access the sibling graphical asset to work in the first place).

The last option is cheap if you haven't built an asset hierarchy already.

---

That's so tangential to the topic, but essentially Drone looks good; none of the other CI providers likely have Vulkan support for free either.

[erlend-sh]

Wait: gfx-hal has been having development to getting GL as a backend

That honestly sounds like a pretty good option to me. I believe @zicklag is dependent on this anyway in order to upgrade to Amethyst latest.

[zicklag]

OK, I've got mac builds working now. You can download and test builds for all platforms here.

As a warning, to get the mac builds to cross-compile from linux I have to use a fork of coreaudio-sys that supports it. This means running a cargo update which will update the dependencies and make the mac build slightly different than the other platforms. Once my PR is merged, that won't be necessary.