Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add CI builds for C# solution #21

Closed
wants to merge 27 commits into from
Closed

Add CI builds for C# solution #21

wants to merge 27 commits into from

Conversation

xplicit
Copy link
Contributor

@xplicit xplicit commented Jan 27, 2015

Allows to build the csharp solution in Travis CI. Tested only for linux platform, because
Travis CI requires to do manual request to enable CI on multiple platforms.
Also, beta-support of C# is enabled only for linux in Travis CI, so it may be need to do
additional install of mono on os x platform in before_install step.

@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

I don't know is it mandatory to run builds on OSX, I don't have ability to test osx builds, because osx is disabled in my travis account.
Also I changed make --jobs 2 check to make check, because I often get the clang compiling job be killed due to out of memory on travis machine.

@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

Without make --jobs 2 check it timeouts.

@sapek
Copy link
Contributor

sapek commented Jan 27, 2015

I build C++ project on OS X in travis because there is no Ubuntu 12.04 package for Boost 1.54 or newer. I was planning to add C++ build once travis adds support for Ubuntu 14.04 (they said they are working on it). I think it would be fine for now to have C++ build on OS X and Mono C# build on Linux.

@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

@sapek I added installation of Boost 1.55 on Ubuntu 12.04 to .travis.yml. It works in general. I have issues with make check command on travis linux machine. It timeouts if I use make check command or be killed by out of memory if I use make --jobs 2 check. If use make it works.
Also I am waiting now the build result for os x

You can look at the results:
linux build: https://travis-ci.org/Microsoft/bond/jobs/48547741
os x build (currently building): https://travis-ci.org/Microsoft/bond/jobs/48547743

@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

Also I tried to use GCC 4.7 instead of clang on VPS hosting, but still have issues with out of memory when make check

@sapek
Copy link
Contributor

sapek commented Jan 27, 2015

Clang 3.6 is the fastest, that might work.

@sapek
Copy link
Contributor

sapek commented Jan 27, 2015

If you want you can leave the make check OS X only for now and just enable Mono build in this PR. I will revisit the C++ build (you can leave the installation script part, just disable calling make check on Linux). C++ build with all unit tests take a long time on a VM and I might have to look at optimizing it in general to avoid Travis timeouts.

@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

Did it already (make check for OS X and make for linux). I'll wait when the current OS X build ends and commit the change.

@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

OS X build is passed (if don't mind about MSTest compile errors)!

Allows to build csharp solution in Travis CI.
Two platforms are added: OS X and Linux. There are difference in builds
on the platforms: on OS X CI make C++ unit-test, while on Linux it does not
do it due to timeout/out of memory.
@xplicit
Copy link
Contributor Author

xplicit commented Jan 27, 2015

I rebased commits and put them into one commit. Now it builds cs.sln both on linux and OS X, on OS X it also runs C++ unit-tests.
One thing is left: need to convert MSTest to NUnit and the solution will be built without errors and C# unit-tests will be able to run. In this case the build will be passed without exceptions.

@sapek
Copy link
Contributor

sapek commented Jan 27, 2015

We need to disable the test projects on Mono until we convert them to NUnit or the CI build will constantly show as broken, right?

@xplicit
Copy link
Contributor Author

xplicit commented Jan 29, 2015

@sapek Yes, you're right. I converted tests to unit in this commit https://github.com/xplicit/bond/commit/37b82ed307771246a9a9520e116d902a147be497

After conversion on .NET: 140 tests were passed, one test is failed (it seems, that NUnit can't compare empty array segments).

Assert.IsEqual(new ArraySegment<byte>(), new ArraySegment<byte>()); //throws exception

On mono 46 tests are failed (something with unsafe IO, I did not look inside them yet).

Also, I want to try to add stable version of NUnit (at first attempt I added NUnit 3.0 alpha package, because it has got different libraries for different frameworks, while v2.6 has got only one library for all targets).

To run Unit tests from VS you need to install NUnit Test Adapter (Tools/Extensions and Updates)

Rob Rodi and others added 17 commits February 12, 2015 16:58
Users can install the grammar by adding the files to their
`%AppData%\Roaming\Sublime Text 3\Packages\User` folder.
It's fairly simplistic, but should be a decent start.
PowerShell script fails AppVeyor CI build when cabal install emits
warnings.
The cabal version 1.20+ was required only for the --required-sandbox
flag. However since the make files are setting up the sandbox we know
that we are always building using sandbox. The current Haskell Platform
comes with cabal 1.18 so this way installing cabal update is not needed.
Mono MemoryStream internal implementation differs from .NET implementation
It does not have `InternalGetOriginAndLength` method. So the cloning
method changed to use mono implementation of MemoryStream
when the method `InternalGetOriginAndLength` is not found
Made the following changes for the open source AppVeyor plan which
runs on very slow and memory limited VMs:
- Limit ghc heap size to 192MB when installing dependencies
- Use `appveyor DownloadFile` instead `Start-Download`
- Download Boost in the smaller 7Zip format
- Cache cabal sandbox and boost download
- Disable C++ build
Since C++ build is disabled we don't need to extract Boost and the build
is on the edge of time out.
This allows include directories to contain spaces.
This ensures that the MSBuild targets and gbc work when a .bond file or an
import directory has spaces in the path.
When support for import directories with spaces in their paths was
added, that inadvertently broke codegen when one ended with a trailing
slash. We add a trailing \. like we do for the output directory to fix
that.
sapek and others added 9 commits February 12, 2015 16:58
When bonded<T> is serialized to untagged protocols like Simple Binary
it is first marshaled into a separate buffer using a tagged protocol and
then written as length prefixed blob to the untagged protocol.
OutputBuffer used for marshaling by default allocates 64KB which is
costly if the bonded<T> payload is small.
Unit tests take a long time to run in CI. Building all tests with
--collection-interfaces flag is somewhat wasteful because a lot of tests
don't use collections at all. Furthermore this way we only tested
collection interfaces together with properties. This change removes the
separate test configuration for --collection-interfaces and instead uses
concrete/interface collection alternatively for different .bond files in
Fields/Properties configuration. This way every schema is tested with
both interfaces and concrete collections and both are also tested with
fields and properties. This gives better coverage while eliminating
redundant identical tests in different assemblies.
@xplicit
Copy link
Contributor Author

xplicit commented Feb 12, 2015

Here new pull request with the same thing: #36

@xplicit xplicit closed this Feb 12, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants