RUBY-3731 Run ruby-dev build on a bi-weekly schedule#3068
Draft
comandeo-mongo wants to merge 1 commit into
Draft
RUBY-3731 Run ruby-dev build on a bi-weekly schedule#3068comandeo-mongo wants to merge 1 commit into
comandeo-mongo wants to merge 1 commit into
Conversation
The ruby-dev variant tests master against the upcoming Ruby version. It already runs off-PR (no "pr" tag), but on every master commit. Add batchtime: 20160 (14 days) so it runs on a ~2-week cadence instead. Document in .evergreen/README.md the project notification a project admin must configure so failures open a RUBY Jira issue with the Ruby version, commit hash, and list of failures.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira: https://jira.mongodb.org/browse/RUBY-3731
What
Make the
ruby-devbuild variant testmasteragainst the upcoming Rubyversion on a regular schedule, instead of on every commit, and document how
failures are reported to Jira.
The
ruby-devvariant already existed and already runs off pull requests (itcarries no
prtag, so the PR alias skips it). The only gap was the cadenceand the failure-reporting story.
Changes
Scheduling:
.evergreen/config/standard.yml.erb— addbatchtime: 20160(14 days) tothe
ruby-devvariant's task, so Evergreen activates it at most once everytwo weeks. This matches the repo's existing 14-day convention.
.evergreen/config.yml— regenerated from the ERB templates (rake eg).Do not edit by hand.
Failure reporting (docs only):
.evergreen/README.md— new "Scheduled ruby-dev build" section. TheJira-issue-on-failure requirement is an Evergreen project notification, not
repo config, so it is documented for a project admin to configure once:
task-failure scoped to the
ruby-devvariant, action "Create a Jira issue"in project
RUBY. Evergreen populates the issue with the variant (Rubyversion), version/commit, and links to the failed tasks.
Test plan
rake egregeneratesconfig.yml; diff is only thebatchtimelineplus the explanatory comment.
evergreen validate .evergreen/config.yml-> "valid with warnings"(the warnings are pre-existing, for commented-out gcpkms/azurekms/lambda
tasks).
or runtime behavior change, so there is nothing in
spec/to exercise.Follow-up (manual, not in this PR)
A project admin must create the Evergreen notification described in the
README. It cannot be committed because it lives in project settings.