-
Notifications
You must be signed in to change notification settings - Fork 5
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
Change CI to use matrix of 2.5 to 3.2 #106
Merged
Merged
Conversation
This file contains 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
* Extract check for max retry delay to its own method * Use milliseconds throughout the class and only convert to seconds when returning the final visibility timeout * Use guard clauses in the check_... methods * Ensure adhering to limits inside the timeout method
Jitter, or randomness in signals, is a common technique for avoiding calls that fail at the same time to retry at the same time. Therefore jitter can help avoid the thundering herd problem, where many instances of the same application all retry at the same time, causing a spike in load on the system. For example, if a service was down for some reason and comes back up, all queued events will hit at once and could cause the service to fail for most events. However, without jitter, the events will all retry at the same time, causing the same problem. Adding some jitter (or randomness) to the retry delays result in the events retrying at different times. In our implementation, the configuration says how much jitter is used based on the retry delay. For example, if `retry_jitter_ratio` is set to 0, no jitter will be applied and all events will retry after the usual retry delay. If it is set to 100, the retry delay will be a random number between 0 and the retry delay without jitter. If it is set to 20, the retry delay will be a random number between 80 and 100% of the retry delay without jitter.
As we are now setting `src` as the default folder, we can just use the container loop from the mounted `src` volume. Also adjust paths in README and test script to work from root, rather inside the `script` folder.
In the upgraded environment with Ruby 3 booting up localstack takes too long, so some tests relying on it fail before it becomes available. Solution is just to add healthchecks and to wait for them to be healthy before starting tests. Also add this for Rspec test action on GitHub to avoid flaky test runs.
florianpilz
changed the title
Update test image to Ruby 3 and change CI to use matrix of 2.7, 3.0, 3.2
Change CI to use matrix of 2.5 to 3.2
Dec 22, 2023
florianpilz
approved these changes
Dec 22, 2023
melaniesmith29
approved these changes
Jan 4, 2024
I also verified the gem works when included in a project relying on it 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Use test matrix to test Ruby 2.5, 2.6, 2.7, 3.0, 3.1 and 3.2. Also make default test setup based on Ruby 3.2
Opened #105 to track the problem around upgrading the
oj
gem.