|
| 1 | +# Evergreen Notes |
| 2 | + |
| 3 | +## mongo-php-toolchain |
| 4 | + |
| 5 | +[10gen/mongo-php-toolchain](https://github.com/10gen/mongo-php-toolchain) is |
| 6 | +responsible for building PHP binaries that will be distributed to Evergreen |
| 7 | +hosts. |
| 8 | + |
| 9 | +The Debian and RHEL toolchain scripts are responsible for building individual |
| 10 | +toolchains for each variant (e.g. PHP version, architecture). Debian and RHEL |
| 11 | +are separate primarily for reasons related to OpenSSL. |
| 12 | + |
| 13 | +## drivers-evergreen-tools |
| 14 | + |
| 15 | +[mongodb-labs/drivers-evergreen-tools](https://github.com/mongodb-labs/drivers-evergreen-tools) |
| 16 | +consists of common scripts used by many drivers (e.g. Mongo Orchestration). The |
| 17 | +PHP driver clones this during the build process. |
| 18 | + |
| 19 | +In some cases, we have modified scripts in the drivers-evergreen-tools |
| 20 | +repository. For instance, the PHP driver uses its own `run-orchestration.sh` |
| 21 | +script but still relies on the common `stop-orchestration.sh` script. |
| 22 | + |
| 23 | +## PHP driver Evergreen configuration |
| 24 | + |
| 25 | +`$PROJECT_DIRECTORY` is set by Evergreen and denotes the directory where the PHP |
| 26 | +driver is built and tested (i.e. git checkout directory). |
| 27 | + |
| 28 | +Various files have been copied and modified from drivers-evergreen-tools: |
| 29 | + |
| 30 | + * `compile.sh`: This is the main entry point for building the driver and will |
| 31 | + either call `compile-unix.sh` and `compile-windows.sh`; however, Windows |
| 32 | + builds use a Cygwin environment and are not yet supported. |
| 33 | + * `compile-unix.sh`: This includes architecture-specific flags and is used for |
| 34 | + both Linux and macOS builds. |
| 35 | + * `run-orchestration.sh`: This is very similar to the drivers-evergreen-tools |
| 36 | + script but it is customized to use the PHP driver's own topology configs for |
| 37 | + Mongo Orchestration. |
| 38 | + * `start-orchestration.sh`: This is modified to install an older, tagged |
| 39 | + version of Mongo Orchestration. This was necessary for a particular platform, |
| 40 | + but may be something to look into in the future. |
| 41 | + |
| 42 | +The PHP driver's `config.yml` is a very stripped down and heavily modified copy |
| 43 | +of the drivers-evergreen-tools configuration. This file starts by defining |
| 44 | +several functions, which consist of one or more commands (types supported by |
| 45 | +Evergreen). |
| 46 | + |
| 47 | +In the case of the `bootstrap mongo-orchestration` function, we execute our |
| 48 | +modified `run-orchestration.sh` script and assign various environment variables |
| 49 | +which have been defined by our matrix configuration (excluding the |
| 50 | +`$PROJECT_DIRECTORY`, which is set by Evergreen itself). |
| 51 | + |
| 52 | +In `run tests`, we also depend on environment variables (e.g. `$MONGODB_URI`) |
| 53 | +that originates in `run-orchestration.sh` and are unpacked and assigned by the |
| 54 | +`expansions.update` command within the `bootstrap mongo-orchestration` function. |
| 55 | +Since Evergreen functions do not return values, assigning environment variables |
| 56 | +is the preferred way to communicate down the line. |
| 57 | + |
| 58 | +The `pre` and `post` block define a sequence of functions to run before and |
| 59 | +after each build, respectively. |
| 60 | + |
| 61 | +Build variants are the top-level scope in Evergreen. They consist of a list of |
| 62 | +tasks (i.e. a square in Evergreen output) and a matrix. The matrix specification |
| 63 | +is the combination of all included axes. For instance, the `tests-php5` matrix |
| 64 | +may consist of all OS types with PHP5, MongoDB server version 4.0 (we need not |
| 65 | +test all server versions), and lastly one or more specific PHP 5.x versions. |
| 66 | +Such a matrix might yield a dozen variants, which will be run for each task in |
| 67 | +the build variant configuration. The `display_name` option determines how the |
| 68 | +build variant (combination of matrix and all tasks) is labeled in the Evergreen |
| 69 | +UI. |
| 70 | + |
| 71 | +The `axes` block defines a list of values for a specific group or ID, which is |
| 72 | +used when defining a matrix. For instance, if a matrix includes 4 axes, it will |
| 73 | +expand to all possible combinations of values within those axes. Care should be |
| 74 | +taken to not create too many redundant combinations when defining matrices. |
| 75 | + |
| 76 | +The `exclude_spec` field within a build variant allows us to exclude one or more |
| 77 | +combinations from the generated matrix. We typically use this to exclude an |
| 78 | +environment we know is not supported (e.g. MongoDB 3.0 and 3.2 on zSeries). |
0 commit comments