-
Notifications
You must be signed in to change notification settings - Fork 918
Merge release/1.17 into release/2.2 #2189
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
Merge release/1.17 into release/2.2 #2189
Conversation
bd8b13d
to
8c336ff
Compare
API Change ReportNo changes found! |
.evergreen/config.yml
Outdated
|
||
functions: | ||
assume-test-secrets-ec2-role: | ||
assume-test-secrets-ec2-role: |
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 yml language server removed these empty spaces while resolving conflicts.
.pre-commit-config.yaml
Outdated
- id: markdown-link-check | ||
exclude: ^(vendor) | ||
# Retry when the endpoint returns HTTP 429 (Too Many Requests) | ||
args: [-r] |
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.
@matthewdale This solution doesn't appear to always resolve the blogspot HTTP 429 issue. markdown-lint-check
has a specific retryOn429
option that they recommend using. From the related docs:
retryOn429
: if this is true then retry request when response is an HTTP code 429 after the duration indicated by retry-after header.
This will require giving the hook a config file .markdown-link-check-config.json
:
{
"retryOn429": true,
"retryCount": 5,
"fallbackRetryDelay": "60s"
}
- id: markdown-link-check
exclude: ^(vendor)
# Retry when the endpoint returns HTTP 429 (Too Many Requests)
args: ["-c", ".markdown-link-check-config.json"]
Pull request was closed
24ca434
to
b41edf6
Compare
There is an existing patch(es) for this commit SHA: Please note that the status that is posted is not in the context of this PR but rather the (latest) existing patch and that may affect some tests that may depend on the particular PR. If your tests do not rely on any PR-specific values (like base or head branch name) then your tests will report the same status. If you would like a patch to run in the context of this PR and abort the other(s), comment 'evergreen retry'. |
@matthewdale This PR was automatically closed after ignoring changes:
We are ignoring the changes since the |
Merge new changes from release/1.17 into release/2.2.
Commits
To resolve any conflicts, check out the temporary branch and run the following command:Resolving conflicts
To ignore from the remote branch, first reset the temporary branch to release/2.2 and manually merge using the `ours` merge strategy:Ignoring changes
Then, push the temporary branch to upate the pull request.