-
Notifications
You must be signed in to change notification settings - Fork 208
PHPC-2261: Revamp Evergreen config #1473
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
PHPC-2261: Revamp Evergreen config #1473
Conversation
set -o errexit # Exit the script with error if any of the commands fail | ||
|
||
# Find PHP binary path for the requested version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was moved over so we can run compile for multiple PHP versions on the same box if we wanted to.
- name: "test-ocsp-latest" | ||
execution_tasks: | ||
- ".ocsp .latest" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Display tasks group a number of tasks in the "configure patch" view. While this limits us to have to select/unselect all OCSP tests at once without having a choice of enabling only some of them, I believe this is fine. Each OCSP test is an individual task due to the way these are structured.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM. I think there's also room for improvement here. If we look at libmongoc, I believe they extracted most of their OCSP logic into run-ocsp-test.sh, which makes the Evergreen configuration more readable. That might allow us to do reduce the complexity of _template-ocsp.yml
and bring it more in line with other templates where we'd only selecting server versions.
.evergreen/config/test/ocsp-7.0.yml
Outdated
@@ -0,0 +1,389 @@ | |||
tasks: | |||
- name: "ocsp-test_1-rsa-delegate-7.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The OCSP tasks may be candidates for using a task group. This would allow us to only fetch the build once, install the correct MongoDB version, then run all tasks sequentially on the same build host. This would further cut down resource usage. However, we'll want to make some improvements to mongodb-orchestration to make sure we can set up and tear down OCSP responders properly. We might also have to split up the mongo-orchestration files to allow for separate functions for downloading MongoDB, starting/stopping orchestration, and starting/stopping a deployment.
include: | ||
- filename: .evergreen/config/functions.yml |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately, include
is only allowed in top-level files, so we can't nest our includes (and include the various test files in test-tasks.yml
).
c859cd6
to
d9bb19b
Compare
# Define aliases for patch builds and PR builds. These only apply if no aliases are defined in project settings | ||
github_pr_aliases: | ||
# Run all build tasks, except on Power8 and zSeries due to low number of build hardware | ||
- variant: "^build-[^-]+($|-arm64)" | ||
task: ".*" | ||
# Run tests on debian, only testing local replicasets with authentication enabled | ||
- variant: "test-.*" | ||
task: "test-mongodb-.*-replicaset-auth" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This configuration only takes effect once the configuration in the project settings has been removed, which I'll do after this pull request is merged.
In addition to this, using variant and task tags for aliases does not work as expected (see EVG-20579), so I've had to come up with regular expressions until that issue is resolved.
@@ -88,3 +88,27 @@ generate-function-map: all | |||
else \ | |||
echo "ERROR: Cannot generate function maps without CLI sapi."; \ | |||
fi | |||
|
|||
test-no-build: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This target was necessary to avoid make trying to recompile the extension due to the different paths in the various .dep files. Instead of replacing paths in more files than just Makefile
, I decided to copy the original test
target and remove the dependency to all
.
Alternatively, we can also extract the call to run-tests.php
, but at that point we may as well consider using a different test runner entirely, such as PHPUnit (which can run phpt files as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Alternatively, we can also extract the call to run-tests.php
I was originally going to suggest replacing this Makefile target with additional logic in .evergreen/run-tests.sh
, but seeing how messy this is (and integrated with the rest of the Makefile) I think this is the right call.
at that point we may as well consider using a different test runner entirely, such as PHPUnit (which can run phpt files as well).
I think this is totally worth exploring. Would you mind creating a ticket so we can revisit the idea?
I would never consider using PHPUnit with PHPC for local development (since it'd likely complicate things like backtraces and leak detection), but it may actually make sense for CI assuming it handles all of the same syntax of run-tests.php
and generates comparable test suite output. And we'd also be able to test it alongside run-tests.php
(e.g. introduce PHPUnit in just an extra task to start). I assume it will also enable better integration with Evergreen, such that we could start populating the "Tests" tab like we do for PHPLIB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alcaeus: ☝️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
b5032b4
to
7da992f
Compare
.evergreen/config.yml
Outdated
# Protect ourselves against rogue test case that runs forever | ||
# Good rule of thumb: the average length a task takes, times 5, which roughly accounts for variable system performance | ||
# for various build variants | ||
exec_timeout_secs: 1800 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is still 6 minutes, does that line up with "the average length a task takes, times 5"? Do our tasks roughly take a bit over a minute to execute?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The 1800 seconds are 30 minutes, meaning that we'll assume a roughly 6-minute task runtime. I'll double-check to make sure the value is still accurate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alcaeus: ☝️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Runtime for build tasks is ~2 minutes, while for test tasks it varies between 2 and 5 minutes. Given that this config setting kills tasks that are running too long I don't see an issue with using 30 minutes, but I'm open to reducing it to something more realistic, e.g. 10 minutes.
7da992f
to
3b9f6b0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but there are one or two outstanding questions to follow up on.
- `local`: All tasks that run a local MongoDB cluster for testing. | ||
- `<version>`: These tags allow selection based on MongoDB version, e.g. `6.4`. | ||
- `standalone`, `replicaset`, `sharded`: These tags allow selection based on the MongoDB topology. | ||
- `loadbalanced`: Allows for selecting tests using a load balancer |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that templates/test/load-balanced.yml
mixes this tag with "sharded". Is that necessary since LB should already imply a sharded topology? Would it make sense to consider this a topology and fold it into the previous line?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the sharded
tag from load balanced tests, effectively treating loadbalanced
like its own topology.
.evergreen/config.yml
Outdated
# Protect ourselves against rogue test case that runs forever | ||
# Good rule of thumb: the average length a task takes, times 5, which roughly accounts for variable system performance | ||
# for various build variants | ||
exec_timeout_secs: 1800 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alcaeus: ☝️
This is necessary if we don't want to change all `.dep` files to the new path.
- Artifactory uploads are not used, so we can save on disk space - Evergreen isn't used to test Windows builds, so we don't need to make Windows fixes - Files should already be executable
3b9f6b0
to
a5efc27
Compare
This PR takes care of PHPC-2260 and PHPC-2261. The following changes have been made, while others are still pending:
The last task is still left to do. However, since
generate.tasks
does not show generated tasks when configuring a patch build, it is not suitable for us. However, repetitive files (e.g. the version-dependent tasks) will be generated automatically via a script to avoid repetition and errors.In addition to the changes above, the following semi-related changes have been made:
For now, tests are only run on Debian systems:
We'll have to discuss what tests we want present, and which ones we want to run for pull requests and commits. We may want to include more tasks but not run them by default to allow for testing special scenarios, although those can be added when necessary.