* Add C++ build testing with clang and gcc
This adds Dockerfiles which test building flatc and the C++ library against clang
and gcc. See discussion at #5119. It is derived from the Travis CI tooling.
The GRPC tests are failing due to #5099 so those are commented out.
These are run from the .travis.yml file rather than the tests/docker/languages
folder because the builds may each take longer than 30 minutes and were hitting
Travis timeouts.
Parallel builds and build caching attempt to keep the build times low.
* Add GCC 8.3 and Clang 7.0 with sanitizers into CI (based on #5130)
- Add a docker based on Debian Buster.
- Add C++ building scripts for the docker.
- Leak-sanitizer requires SYS_PTRACE.
* Add utility for checking the encoding of source files
- accept source files with ASCII or UTF-8 without BOM
- accept only CRLF line ending
* Fix non-ascii symbol in idl_parcer.cpp
* Remove BOM from test.cpp
This runs a script in TravisCI that executes a bunch of small Docker image
scripts to test the language ports in isolated environments. This allows us to
test multiple language versions with little additional complexity.
Covers:
+ Java OpenJDK 10.0.2
+ Java OpenJDK 11.0.1
+ Node 10.13.0
+ Node 11.2.0
+ Python CPython 2.7.15
+ Python CPython 3.7.1
+ Rust 1.30.1
* call reflection code generation from tests
This simplifies instructions to contributors so they don't forget to update
reflection code.
* add error handling to generate_code scripts
Let them propagate their errors instead of swallowing them so they show
up when called in CI.
* apply editorconfig to shell scripts
* use ordered map in dart codegen
Using an unordered map in the codegen can lead to spurious diffs in the
generated dart code.
* add CI check for generate_code being run
* update reflection_generated.h
* disable diff-check for monster_test.bfbs
Work around #5008.
Use a combination of travis and twine to publish to PyPI. New
publications will be made:
* When `master` is updated. This will trigger the publication of a
the Python artifact versioned an iso-compliant build datetime. In this
way, the cutting edge version will always be available via PyPI.
* When a new git tag is pushed. Tag pushes trigger the publication of
a python artifact with the same version as the git tag, with the
leading `v` stripped if present (`v1.2.3` becomes `1.2.3`).
Publications rely on Travis having a PYPI_PASSWORD environment set in
the project settings. See the Travis CI documentation for information on
[setting environment variables which containing sensitive data][1]. Make
extra sure the "Display value in build log" switch is OFF.
In addition to setting the previously mentioned `PYPI_PASSWORD`
environment variable, the owner of the PyPI `flatbuffers` repository
should, after merging this commit into master, add his own commit to
change `mikeholler` in `.travis/deploy-python.sh` to his username. It's
also recommended that the owner of `flatbuffers` use a separate account
in the unlikely event that the environment variable somehow becomes
compromised. Again, this is very unlikely, since the environment
variable is only set for "safe" builds approved by maintainers (not on
random pull requests).
[1]: https://docs.travis-ci.com/user/environment-variables/#Defining-Variables-in-Repository-Settings
mustiikhalil