v8.12.0
La version 8.12.0 de l'agent Ruby apporte une nouvelle instrumentation Elasticsearch. La version 8.12.0 de l'agent Ruby augmente également le nombre par défaut d'événements personnalisés enregistrés, annonce la dépréciation de Ruby 2.3, et apporte un nettoyage de code utile.
Prise en charge de l’instrumentation Elasticsearch
Cette sortie de l’agent Ruby ajoute la prise en charge pour instrument automatiquement le gem elasticsearch. Les versions 7.x et 8.x sont prises en charge. PR#1525
Nom de la configuration Défaut Comportement instrumentation.elasticsearchauto Contrôle l’auto-instrumentation de la bibliothèque elasticsearch au démarrage. Peut être l’un de auto,prepend,chain,disabled.elasticsearch.capture_queriesvrai Si true, l'agent capture la requête Elasticsearch dans la trace de transaction.elasticsearch.obfuscate_queriesvrai Si true, l'agent obscurcit la requête Elasticsearch dans la trace de transaction.Augmentation de la limite des événements personnalisés
Cette version de l'agent Ruby augmente la limite par défaut des événements personnalisés de 1000 événements par minute à 3000 événements par minute. Si vos événements personnalisés étaient limités, ce changement permettra d'envoyer davantage d'événements personnalisés à New Relic. Il existe également une nouvelle limite maximale configurable de 100 000 événements par minute. Pour modifier les limites, consultez la documentation de max_samples_stored. Pour en savoir plus sur ce changement et comment déterminer si des événements personnalisés sont rejetés, consultez notre publication sur l'Explorers Hub. PR#1541
Déprécier la prise en charge de Ruby 2.3
Ruby 2.3 a atteint sa fin de vie le 31 mars 2019. L’agent Ruby a déprécié la prise en charge de Ruby 2.3 et apportera des changements majeurs pour cette version lors de sa prochaine sortie majeure, la v9.0.0 (date de sortie non encore planifiée). Toutes les versions 8.x.x de l’agent resteront compatibles avec Ruby 2.3.
Nettoyage : supprimez le code orphelin
Dans l’agent comme dans les tests unitaires, des changements ont eu lieu au fil des ans, rendant certaines parties du code inaccessibles. Ce code orphelin peut compliquer la maintenance du code et le refactoring, c’est pourquoi le nettoyer peut être très utile. Le membre de la communauté @ohbarye a soumis deux PR de nettoyage distinctes pour cette sortie ; une pour l’agent et une pour les tests. PR#1537 PR#1548
Merci à @ohbarye d'avoir contribué à ce nettoyage utile !
Déclaration de soutien
New Relic recommande de mettre à jour l’agent Ruby régulièrement et au minimum tous les 3 mois. À partir de cette version, la plus ancienne version prise en charge est 6.7.0.359.
v8.11.0
Version 8.11.0 of the agent updates the newrelic deployments command to work with API keys issued to newer accounts, fixes a memory leak in the instrumentation of Curb error handling, further preps for Ruby 3.2.0 support, and includes several community member driven cleanup and improvement efforts. Thank you to everyone involved!
Added support for New Relic REST API v2 when using
newrelic deploymentscommandPreviously, the
newrelic deploymentscommand only supported the older version of the deployments api, which does not currently support newer license keys. Now you can use the New Relic REST API v2 to record deployments by providing your user API key to the agent configuration usingapi_key. When this configuration option is present, thenewrelic deploymentscommand will automatically use the New Relic REST API v2 deployment endpoint. PR#1461Thank you to @Arkham for bringing this to our attention!
Cleanup: Performance tests, constants, rubocop-minitest assertions and refutations
Community member @esquith contributed a whole slew of cleanup successes for our performance test configuration, orphaned constants in our code base, and RuboCop related improvements. PR#1406 PR#1408 PR#1409 PR#1411
Thank you @esquith for these great contributions!
CI: Notify on a change from failure to success
A super handy, much beloved feature of certain CI and build systems is to not only notify when builds start to fail, but also to notify again when the builds once again start to go green. Community member @luigieai was able to figure out how to configure our existing complex, multiple-3rd-party-action based GitHub Actions pipeline to notify on a switch back to success from failure. PR#1519
This is much appreciated! Thank you, @luigieai.
Spelling corrections
Community member @jsoref, author of the Check Spelling GitHub Action, contributed a significant number of spelling corrections throughout the code base. The intelligent issues that were flagged made for a more comprehensive review than a simple dictionary based check would have been able to provide, and the changes are much appreciated. PR#1508
Thank you very much, @jsoref!
Ruby 3.2.0-preview2 compatibility
Ruby 3.2.0-preview1 introduced a change to the way that Ruby reports VM stats and the approach was changed yet again to a 3rd approach with the preview2 release. New Relic reports on Ruby VM stats and is keeping track of the Ruby 3.2 development process to help ensure our customers with a smooth and worthwhile upgrade process once Ruby 3.2.0 (non-preview) is released. PR#1436
Bugfix: Fix memory leak in the Curb instrumentation
Community member @charkost was able to rework the
on_failurecallback logic prepped via the agent's Curb instrumentation in order to avoid some nesting that was causing memory leaks. PR#1518Many thanks for both the heads up on the issue and the fix, @charkost!
Support statement
New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.7.0.359.
v8.10.1
Bugfix: Missing unscoped metrics when instrumentation.thread.tracing is enabled
Previously, when
instrumentation.thread.tracingwas set to true, some puma applications encountered a bug where a varying number of unscoped metrics would be missing. The agent now will correctly store and send all unscoped metrics.Thank you to @texpert for providing details of their situation to help resolve the issue.
Bugfix: gRPC instrumentation causes ArgumentError when other Google gems are present
Previously, when the agent had gRPC instrumentation enabled in an application using other gems (such as google-ads-googleads), the instrumentation could cause the error
ArgumentError: wrong number of arguments (given 3, expected 2). The gRPC instrumentation has been updated to prevent this issue from occurring in the future.Thank you to @FeminismIsAwesome for bringing this issue to our attention.
Support statement
New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.
v8.10.0
New gRPC instrumentation
The agent will now instrument gRPC activity performed by clients and servers that use the grpc RubyGem. Instrumentation is automatic and enabled by default, so gRPC users should not need to modify any existing application code or agent configuration to benefit from the instrumentation. The instrumentation makes use of distributed tracing for a comprehensive overview of all gRPC traffic taking place across multiple monitored applications. This allows you to observe your client and server activity using any service that adheres to the W3C standard.
The following new configuration parameters have been added for gRPC. All are optional.
Configuration name Default Behavior instrumentation.grpc_clientauto Set to 'disabled' to disable, set to 'chain' if there are module prepending conflicts instrumentation.grpc_serverauto Set to 'disabled' to disable, set to 'chain' if there are module prepending conflicts instrumentation.grpc.host_denylist"" Provide a comma delimited list of host regex patterns (ex: "private.com$,exception.*") Code-level metrics functionality is enabled by default
The code-level metrics functionality for the Ruby agent's CodeStream integration is now enabled by default after we have received positive feedback and no open bugs for the past two releases.
Performance: Rework timing range overlap calculations for multiple transaction segments
Many thanks to GitHub community members @bmulholland and @hkdnet. @bmulholland alerted us to rmosolgo/graphql-ruby#3945. That Issue essentially notes that the New Relic Ruby agent incurs a significant perfomance hit when the
graphqlRubyGem (which ships with New Relic Ruby agent support) is used with DataLoader to generate a high number of transactions. Then @hkdnet diagnosed the root cause in the Ruby agent and put together both a proof of concept fix and a full blown PR to resolve the problem. The agent keeps track multiple segments that are concurrently in play for a given transaction in order to merge the ones whose start and stop times intersect. The logic for doing this find-and-merge operation has been reworked to a) be deferred entirely until the transaction is ready to be recorded, and b) made more performant when it is needed. GraphQL DataLoader users and other users who generate lots of activity for monitoring within a short amount of time will hopefully see some good performance gains from these changes.
Performance: Make frozen string literals the default for the agent
The Ruby
frozen_string_literal: truemagic source code comment has now been applied consistently across all Ruby files belonging to the agent. This can provide a performance boost, given that Ruby can rely on the strings remaining immutable. Previously only about a third of the agent's code was freezing string literals by default. Now that 100% of the code freezes string literals by default, we have internally observed some related performance gains through testing. We are hopeful that these will translate into some real world gains in production capacities.
Bugfix: Error when setting the yaml configuration with
transaction_tracer.transaction_threshold: apdex_fOriginally, the agent was only checking the
transaction_tracer.transaction_thresholdfrom the newrelic.yml correctly if it was on two lines.Example:
# newrelic.ymltransaction_tracer:transaction_threshold: apdex_fWhen this was instead changed to be on one line, the agent was not able to correctly identify the value of apdex_f.
Example:
# newrelic.ymltransaction_tracer.transaction_threshold: apdex_fThis would cause prevent transactions from finishing due to the error
ArgumentError: comparison of Float with String failed. This has now been corrected and the agent is able to process newrelic.yml with a one linetransaction_tracer.transaction_threshold: apdex_fcorrectly now.Thank you to @oboxodo for bringing this to our attention.
Bugfix: Don't modify frozen Logger
Previously the agent would modify each instance of the Logger class by adding a unique instance variable as part of the instrumentation. This could cause the error
FrozenError: can't modify frozen Loggerto be thrown if the Logger instance had been frozen. The agent will now check if the object is frozen before attempting to modify the object. Thanks to @mkcosta for bringing this issue to our attention.
Support statement
New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.
v8.9.0
Add support for Dalli 3.1.0 to Dalli 3.2.2
Dalli versions 3.1.0 and above include breaking changes where the agent previously hooked into the gem. We have updated our instrumentation to correctly hook into Dalli 3.1.0 and above. At this time, 3.2.2 is the latest Dalli version and is confirmed to be supported.
Bugfix: Infinite Tracing hung on connection restart
Previously, when using infinite tracing, the agent would intermittently encounter a deadlock when attempting to restart the infinite tracing connection. This bug would prevent the agent from sending all data types, including non-infinite-tracing-related data. This change reworks how we restart Infinite Tracing to prevent potential deadlocks.
Bugfix: Use read_nonblock instead of read on pipe
Previously, our PipeChannelManager was using read which could cause resque jobs to get stuck in some versions. This change updates the PipeChannelManager to use read_nonblock instead to avoid this issue.
Support statement
New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.
v8.8.0
Support Makara database adapters with ActiveRecord
Thanks to a community submission from lucasklaassen with PR #1177, the Ruby agent will now correctly work well with the Makara gem. Functionality such as SQL obfuscation should now work when Makara database adapters are used with Active Record.
Lowered the minimum payload size to compress
Previously the Ruby agent used a particularly large payload size threshold of 64KiB that would need to be met before the agent would compress data en route to New Relic's collector. The original value stems from segfault issues that very old Rubies (older than 2.2) used to encounter when compressing smaller payloads. This value has been lowered to 2KiB (2048 bytes), which should provide a more optimal balance between the CPU cycles spent on compression and the bandwidth savings gained from it.
Provide Code Level Metrics for New Relic CodeStream
For Ruby on Rails applications and/or those with manually traced methods, the agent is now capable of reporting metrics with Ruby method-level granularity. When the new
code_level_metrics.enabledconfiguration parameter is set to atruevalue, the agent will associate source-code-related metadata with the metrics for things such as Rails controller methods. Then, when the corresponding Ruby class file that defines the methods is loaded up in a New Relic CodeStream-powered IDE, the four golden signals for each method will be presented to the developer directly.Supportability Metrics will always report uncompressed payload size
New Relic's agent specifications call for Supportability Metrics to always reference the uncompressed payload byte size. Previously, the Ruby agent was calculating the byte size after compression. Furthermore, compression is only performed on payloads of a certain size. This means that sometimes the value could have represented a compressed size and sometimes an uncompressed one. Now the uncompressed value is always used, bringing consistency for comparing two instances of the same metric and alignment with the New Relic agent specifications.
Support statement
New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.5.0.357.
v8.7.0
Transfert de logs des logs en contexte APM activé par défaut
Le transfert automatique de logs d’application est désormais activé par défaut. Cette version de l’agent enverra automatiquement des logs d’application enrichis à New Relic. Pour en savoir plus sur cette fonctionnalité, cliquez ici, et des options de configuration supplémentaires sont disponibles ici. Pour savoir comment activer ou désactiver l’ingestion de logs par compte, cliquez ici.
Amélioration de la prise en charge asynchrone et de l'instrumentation des threads
Auparavant, l’agent n’était pas en mesure d’enregistrer les événements, et les métriques dans les Threads créés au sein d’une transaction déjà en cours d’exécution. Cette sortie comprend 2 nouvelles options de configuration pour prendre en charge les applications multithreads afin d’instrumenter automatiquement les threads. Une nouvelle option de configuration,
instrumentation.thread.tracing(désactivée par défaut), a été introduite, et, lorsqu’elle est activée, elle permettra à l’agent d’insérer le tracing New Relic dans tous les Threads créés par une application. Pour prendre en charge les applications qui souhaitent uniquement que certains threads soient instrumentés par New Relic, une nouvelle classe est disponible,NewRelic::TracedThread, qui créera un thread incluant l’instrumentation New Relic ; consultez notre documentation de l’API pour obtenir plus de détails.Nouvelles options de configuration incluses dans cette sortie :
Nom de la configuration
Défaut
Comportement
instrumentation.threadauto(enabled)Permet à l'agent d'imbriquer correctement les spans à l'intérieur d'une transaction asynchrone.
instrumentation.thread.tracingfalse(désactivé)Ajouter automatiquement le tracing à tous les threads créés dans l’application. Cela pourrait être activé par défaut dans une sortie ultérieure.
Nous tenons à remercier @mikeantonelli d’avoir partagé avec nous un gist qui a fourni à notre équipe un point d’entrée pour cette fonctionnalité.
Dépréciation de la prise en charge de Ruby 2.2
Ruby 2.2 a atteint sa fin de vie le 31 mars 2018. L’agent a déprécié la prise en charge de Ruby 2.2 et apportera des modifications majeures pour cette version lors de sa prochaine sortie majeure.
Ajout d’options de configuration mises à jour pour les événements de transaction et dépréciation des configurations précédentes
Cette sortie rend obsolète l’instrumentation suivante :
Obsolète
Remplacement
ActiveMerchant 1.64.0 ou version antérieure
ActiveMerchant 1.65.0 ou version ultérieure
ActiveRecord 3.2.22.5 ou version inférieure
ActiveRecord 4.0.0 ou supérieur
Acts As Solr (toutes les versions)
aucun
Authlogic (toutes les versions)
aucun
Bunny 2.6.7 ou inférieur
Bunny 2.7.0 ou version ultérieure
Dalli 2.7.6 ou inférieur
Dalli 2.7.7 ou version ultérieure
DataMapper (toutes les versions)
aucun
Delayed Job 4.1.2 ou version antérieure
Delayed Job 4.1.3 ou supérieur
Excon 0.55.0 ou version antérieure
Excon 0.56.0 ou version ultérieure
Grape 0.19.1 ou version antérieure
Grape 0.19.2 ou version ultérieure
HTTPClient 2.8.2.4 ou version antérieure
HTTPClient 2.8.3
HTTP.rb 2.2.1 ou version antérieure
HTTP.rb 2.2.2 ou version ultérieure
Mongo 2.4.0 ou version antérieure
Mongo 2.4.1 ou version ultérieure
Padrino 0.14.4 ou inférieur
Padrino 0.15.0 ou version ultérieure
Passenger 5.1.2 ou inférieur
Passenger 5.1.3 ou supérieur
Puma 3.8.2 ou version inférieure
Puma 3.9.0 ou version ultérieure
Rack 1.6.7 ou version antérieure
Rack 1.6.8 ou supérieur
Rails 3.2.22.5 ou version antérieure
Rails 4.0.0, ou version ultérieure
Rainbows (toutes les versions)
aucun
Sequel 4.44.0 ou inférieur
Sequel 4.45.0 ou version ultérieure
Sidekiq 4.2.10 ou version antérieure
Sidekiq 5.0.0 ou supérieur
Sinatra 1.4.8 ou inférieur
Sinatra 2.0.0 ou supérieur
Sunspot (toutes les versions)
aucun
Typhœus 1.1.2 ou inférieur
Typhoeus 1.3.0 ou version ultérieure
Unicorn 5.2.0 ou version antérieure
Unicorn 5.3.0 ou version ultérieure
Pour les gems avec des versions obsolètes, nous ne testerons plus ces versions dans notre suite multiverse. Elles peuvent, cependant, toujours être compatibles avec l'agent. Nous ne traiterons plus les rapports de bugs pour les problèmes rencontrés avec ces versions de la gem.
Exploiter en interne
Object.const_get, etObject.const_defined?Lorsque vous recherchez dynamiquement une constante de classe à partir d’une chaîne, ou que vous en obtenez une référence, utilisez les méthodes intégrées de la classe
Objectdans la mesure du possible pour bénéficier d’opérations plus simples, et plus performantes. Tous les JRubies, et CRubies v2.5, et versions antérieures ont besoin d’un peu d’aide au-delà de ce queObjectpeut fournir, étant donné que ces Rubies peuvent renvoyer une constante indésirable provenant d’un espace de nommage différent de celui qui a été spécifié. Mais pour tous les autres Rubies, et même pour ces Rubies dans des contextes où nous pouvons faire confiance à 100 % à la valeur de la chaîne entrante, utilisez les méthodes de la classeObject, et profitez de leurs avantages.Clarifier la documentation pour la configuration de
rake.tasksLa description de
rake.tasksdans le fichiernewrelic.ymlpar défaut et la documentation de configuration de l’agent Ruby New Relic ont été mises à jour pour clarifier son comportement et son utilisation. La documentation indique désormais :Spécifiez un éventail de tâches Rake à instrumenter automatiquement. Cette option de configuration convertit l’éventail en une liste RegEx. Si vous souhaitez autoriser toutes les tâches par défaut, utilisez
rake.tasks: [.+]. Les tâches Rake ne seront pas instrumentées à moins qu’elles ne soient ajoutées à cette liste. Pour plus d’informations, consultez la (documentation sur l’instrumentation New Relic Rake)[/docs/apm/agents/ruby-agent/background-jobs/rake-instrumentation].Nous remercions @robotfelix d’avoir suggéré ces modifications.
Activez le paramètre des variables d’environnement permettant aux configurations d’éventail d’être converties en éventails
Avant ce changement, lorsque des listes séparées par des virgules étaient passées comme variables d’environnement, une erreur était émise vers le
newrelic_agent.log, et un String était défini comme valeur. Désormais, les éventails seront convertis avec précision.Correction de bug : permet aux TransactionEvents d’être échantillonnés au taux attendu
La valeur de capacité
transaction_events.max_samples_storeddans le TransactionEventAggregator ne correspondait pas à son intervalle de cycle de collecte attendu, provoquant un suréchantillonnage des TransactionEvents. Ce correctif s’appuie sur les mises à jour effectuées dans #952 afin que l’intervalle et la capacité se comportent comme prévu pour les options de configurationtransaction_events*renommées.Correction de bug : attributs manquants pour les événements d’erreur créés en dehors d’une transaction
Auparavant, l’agent n’attribuait pas de priorité aux événements d’erreur qui étaient créés en appelant notice_error en dehors de la portée d’une transaction. Cela causait des problèmes d’échantillonnage lorsque le tampon de l’événement d’erreur était plein, entraînant un
NoMethodError: undefined method '<' for nil:NilClassdans le newrelic_agent.log. Cette correction de bug garantit qu’une priorité est toujours attribuée aux événements d’erreur afin que l’agent soit capable d’échantillonner correctement ces événements d’erreur. Nous remercions @olleolleolle d’avoir porté ce problème à notre attention.
Déclaration de soutien
New Relic recommande de mettre à jour l’agent régulièrement et au minimum tous les 3 mois. À partir de cette sortie, la plus ancienne version prise en charge est 5.7.0.350.
v8.6.0
Telemetry-in-Context: Automatic Application Logs, a quick way to view logs no matter where you are in the platform
- Adds support for forwarding application logs to New Relic. This automatically sends application logs that have been enriched to power Telemetry-in-Context. This is disabled by default in this release. This may be on by default in a future release.
- Adds support for enriching application logs written to disk or standard out. This can be used with another log forwarder to power Telemetry-in-Context if in-agent log forwarding is not desired. We recommend enabling either log forwarding or local log decorating, but not both features. This is disabled by default in this release.
- Improves speed and Resque support for logging metrics which shows the rate of log message by severity in the Logs chart in the APM Summary view. This is enabled by default in this release.
To learn more about Telemetry-in-Context and the configuration options please see the documentation here.
Bugfix: Curb - satify method_with_tracing's verb argument requirement
When Curb instrumentation is used (either via prepend or chain), be sure to always pass the verb argument over to
method_with_tracingwhich requires it. Thank you to @knarewski for bringing this issue to our attention, for providing a means of reproducing an error, and for providing a fix. That fix has been replicated by the agent team with permission. See Issue 1033 for more details.Improve the usage of the 'hostname' executable and other executables
In all places where a call to an executable binary is made (currently this is done only for the 'hostname' and 'uname' binaries), leverage a new helper method when making the call. This new helper will a) not attempt to execute the binary if it cannot be found, and b) prevent STDERR/STDOUT content from appearing anywhere except New Relic's own logs if the New Relic logger is set to the 'debug' level. When calling 'hostname', fall back to
Socket.gethostnameif the 'hostname' binary cannot be found. When calling 'uname', fall back on using a value of 'unknown' if the 'uname' command fails. Many thanks to @metaskills and @brcarp for letting us know that Ruby AWS Lambda functions can't invoke 'hostname' and for providing ideas and feedback with Issue #697.Documentation: remove confusing duplicate RUM entry from newrelic.yml
The
browser_monitoring.auto_instrumentconfiguration option to enable web page load timing (RUM) was confusingly listed twice in the newrelic.yml config file. This option is enabled by default. The newrelic.yml file has been updated to list the option only once. Many thanks to @robotfelix for bringing this to our attention with Issue #955.Bugfix: fix unit test failures when New Relic environment variables are present
Previously, unit tests would fail with unexpected invocation errors when
NEW_RELIC_LICENSE_KEYandNEW_RELIC_HOSTenvironment variables were present. Now, tests will discard these environment variables before running.
Support statement
New Relic recommends that you upgrade the agent regularly and at a minimum every 3 months. As of this release, the oldest supported version is 6.3.0.355.
v8.5.0
AWS: Support IMDSv2 by using a token with metadata API calls
When querying AWS for instance metadata, include a token in the request headers. If an AWS user configures instances to require a token, the agent will now work. For instances that do not require the inclusion of a token, the agent will continue to work in that context as well.
Muffle anticipated stderr warnings for "hostname" calls
When using the
hostnamebinary to obtain hostname information, redirect STDERR to /dev/null. Thanks very much to @frenkel for raising this issue on behalf of OpenBSD users everywhere and for providing a solution with PR #965.Added updated configuration options for transaction events and deprecated previous configs This release deprecates and replaces the following configuration options:
Deprecated | Replacement |
|---|---|
event_report_period.analytic_event_data | event_report_period.transaction_event_data |
analytics_events.enabled | transaction_events.enabled |
analytics_events.max_samples_stored | transaction_events.max_samples_stored |
Eliminated warnings for redefined constants in ParameterFiltering
Fixed the
ParameterFilteringconstant definitions so that they are not redefined on multiple reloads of the module. Thank you to @TonyArra for bringing this issue to our attention.Docker for development
Docker and Docker Compose may now be used for local development and testing with the provided
Dockerfileanddocker-compose.ymlfiles in the project root. See DOCKER.md for usage instructions.
Bugfix: Rails 5 + Puma errors in rack "can't add a new key into hash during iteration"
When using rails 5 with puma, the agent would intermittently cause rack to raise a
RuntimeError: can't add a new key into hash during iteration. We have identified the source of the error in our instrumentation and corrected the behavior so it no longer interferes with rack. Thanks to @sasharevzin for bringing attention to this error and providing a reproduction of the issue for us to investigate.CI: target JRuby 9.3.3.0
Many thanks to @ahorek for PR #919, PR #921, and PR #922 to keep us up to date on the JRuby side of things. The agent is now actively being tested against JRuby 9.3.3.0. NOTE that this release does not contain any non-CI related changes for JRuby. Old agent versions are still expected to work with newer JRubies, and the newest agent version is still expected to work with older JRubies.
CI: Update unit tests for Rails 7.0.2
Ensure that the 7.0.2 release of Rails is fully compatible with all relevant tests.
CI: Ubuntu 20.04 LTS
To stay current and secure, our CI automation is now backed by version 20.04 of Ubuntu's long term support offering (previously 18.04).