Using non-versioned scripts for `build_file` means every Python version is
tested (under Tox), and this is multiplied by each Python version running Tox.
For example, when the `python38` config is used to run Tox, the
Tox layer runs on Python 3.8. This then tests all of the Python versions
individually, including, for example, python27 tests.
This change fixes the `build_file` paths to point to the same-pathed build
script. For example, `kokoro/linux/python27/presubmit.cfg` now uses
`kokoro/linux/python27/build.sh`.
Some additional fixes:
* Use `python -m tox` in tests.sh instead of just `tox`. This helps non-site
installations of tox, where the `tox` script may not be on `$PATH`.
* Ensure tox (and other Python build-related packages) are available in
Python testing images. (New images have been pushed.)
* Disable `--warnings_as_errors` due to deprecated function.
* Remove apt lists per [Docker best practices][1].
[1]: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/
* Only ported c extension to php8.
* Didn't fixed the issue of throwing warnings for missing arginfo in bundled files.
* Tests not fixed, because syntax of phpunit (<7 vs >9.3) are not compatible.
* In next release, needs to drop php5 and php7.0 support (in order to use phpunit > 7)
* Create a new docker image for python 3.6
The previous one cannot build, because python3.6 was removed from
stretch.
* Drop support for 3.3 and 3.4
Also update all docker file to be single version
* Build extensions for Ruby 2.7
* Try installing bundler 2.x
* Try bumping rake-compiler-dock
* Use standard RCD images
* Avoid 'rake cross native' with rake-compiler-dock
* Use Ruby 2.5 for building Ruby <= 2.6
* Use rake-compiler 1.1.0
* Specify target
* Don't update Ruby test image for now
* Set execute bit on files if and only if they begin with (#!).
Git only tracks the 'x' (executable) bit on each file. Prior to this
CL, our files were a random mix of executable and non-executable.
This change imposes some order by making files executable if and only
if they have shebang (#!) lines at the beginning.
We don't have any executable binaries checked into the repo, so
we shouldn't need to worry about that case.
* Added fix_permissions.sh script to set +x iff a file begins with (#!).
* [bazel] Move Java runtime/toolchains into //java
This change moves `java_library` targets from the top-level BUILD file
into `//java/{core,lite,util}` and declares `alias` targets to point to
their new locations (hence, this is not a breaking change).
This will allow users that don't use Java to stop depending on
`@rules_java` (e.g. as requested in
https://github.com/bazelbuild/rules_scala/pull/989#issuecomment-583405161).
Note that there is no intention to deprecate + remove the top-level
targets in the foreseeable future.
* Add BUILD files in //java to java_EXTRA_DIST
Lots of CI tests have been failing recently with error messages like
this from "docker pull":
Error response from daemon: unexpected EOF
This seems to be an issue affecting other projects as well:
https://forums.docker.com/t/docker-pull-causes-error-response-from-daemon-unexpected-eof/88608
This commit tries to mitigate the problem by periodically retrying
failed Docker pulls.
I'm not exactly sure why, but this fixes the failing Bazel presubmit
test. Using the most recent version seems like a good idea anyway so
that we can make sure we're compatible with any new Bazel changes.
* Bump target frameworks from netcoreapp1.0 to netcoreapp2.2.
Move global.json up to root of repo, change SDK ver to 2.2.100
Change .net core sdk in dockerfile for kokoro to ver 2.2.100
* Re-add curl install
* Change all exe target to 2.1
* Fix incorrect versions in global.json and Dockerfile
* Downgrade version to 2.1 to match exe targets
* introduce separate testing Dockerfile for C#
* revert changes to the shared Dockerfile
* use netcoreapp2.1 for C# conformance tests
* use language specific dockerfile for testing C#
* Edit compatibility tests script to use parameters instead of file copies
* install dotnet SDK on windows before running the tests
* update csharp_EXTRA_DIST
* Add ruby 2.6 gem build for linux
* Add docker hub organization
* Add ruby2.6 in cross compile targets
* Fix tests
* Check mac version
* No need to install php in preparation for mac
* Add ruby 2.6 test
* Fix broken tests
* Fix compatibility test
* Fix bundler version
* Use new docker image
* Fix broken test
* Use new docker image in ruby26 test
* Install ruby for mac
* Rebuild python docker image
* Update docker image
* Change call to build_and_run_docker.sh
* Set up python tests for different versions
* Fix comments
* Inherit from message instead of implement
When regestering class (implmenets other class) during MINIT, zend_class_implements
would call zend_class_entry->interface_gets_implemented(). In PHP-7.3 interface_gets_implemented shares the same location with create_object.
However, during MINIT, the global object storeage hasn't been initialized. And thus, caused segment fault in php 7.3.
* Use zend_string_init where interned string may be the value.
zend_string_dup will keep using the existing interned string.
In php 7.3, interned string cannot be destroyed from user's code.
* Uncommment debug code
* Use latest phpunit for each php versions
* Revert change in Dockerfile
* Update php test to use the new docker image
* Update composer
* Change docker organization
* Update phpunit
* Debug phpunit
* Store phpunit into bin dir in docker image
* Install valgrind to docker
* Fix compatibility test
* Remove generated_service_test from compatibility c extension test
* Update 32bit php test to the new docker image
* Install bison
* Fix build.sh
* Fix DOCKERIMAGE_PREFIX
* Fix basename
* Add comment to build_and_run_docker2.sh
* Remove commented code
* Fix comments