Skip to content
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

add supported versions workflow #4210

Draft
wants to merge 17 commits into
base: master
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
130 changes: 130 additions & 0 deletions .github/scripts/find_gem_version_bounds.rb
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
require 'pathname'
require 'rubygems'
require 'json'
require 'bundler'

lib = File.expand_path('lib', __dir__)
$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
require 'datadog'

def parse_gemfiles(directory = 'gemfiles/')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Code Quality Violation

Avoid top-level methods definition. Organize methods in modules/classes. (...read more)

This rule emphasizes the importance of organizing methods within modules or classes in Ruby. In Ruby, it's considered a best practice to wrap methods within classes or modules. This is because it helps in grouping related methods together, which in turn makes the code easier to understand, maintain, and reuse.

Not adhering to this rule can lead to a disorganized codebase, making it hard for other developers to understand and maintain the code. It can also lead to potential name clashes if a method is defined in the global scope.

To avoid violating this rule, always define your methods within a class or a module. For example, instead of writing def some_method; end, you should write class SomeClass def some_method; end end. This not only adheres to the rule but also improves the readability and maintainability of your code.

View in Datadog  Leave us feedback  Documentation

min_gems = { 'ruby' => {}, 'jruby' => {} }
max_gems = { 'ruby' => {}, 'jruby' => {} }

gemfiles = Dir.glob(File.join(directory, '*'))
gemfiles.each do |gemfile_name|
runtime = File.basename(gemfile_name).split('_').first # ruby or jruby
next unless %w[ruby jruby].include?(runtime)
# parse the gemfile
if gemfile_name.end_with?(".gemfile")
process_gemfile(gemfile_name, runtime, min_gems, max_gems)
elsif gemfile_name.end_with?('.gemfile.lock')
process_lockfile(gemfile_name, runtime, min_gems, max_gems)
end
end

[min_gems['ruby'], min_gems['jruby'], max_gems['ruby'], max_gems['jruby']]
end

def process_gemfile(gemfile_name, runtime, min_gems, max_gems)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Code Quality Violation

Avoid top-level methods definition. Organize methods in modules/classes. (...read more)

This rule emphasizes the importance of organizing methods within modules or classes in Ruby. In Ruby, it's considered a best practice to wrap methods within classes or modules. This is because it helps in grouping related methods together, which in turn makes the code easier to understand, maintain, and reuse.

Not adhering to this rule can lead to a disorganized codebase, making it hard for other developers to understand and maintain the code. It can also lead to potential name clashes if a method is defined in the global scope.

To avoid violating this rule, always define your methods within a class or a module. For example, instead of writing def some_method; end, you should write class SomeClass def some_method; end end. This not only adheres to the rule but also improves the readability and maintainability of your code.

View in Datadog  Leave us feedback  Documentation

begin
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Quality Violation

Use the method's implicit 'begin' instead of adding an explicit 'begin' block (...read more)

In Ruby, every method has an implicit begin...end block. Therefore, using an explicit begin...end block at the beginning of a method is redundant and can lead to unnecessary code complexity. This rule is designed to ensure that your code is as clean and efficient as possible.

The importance of this rule lies in the practice of writing clean, maintainable, and efficient code. Unnecessary code can lead to confusion for other developers, making the codebase more difficult to understand and maintain. It can also lead to potential bugs or performance issues.

To adhere to this rule, ensure that you do not use an explicit begin...end block at the beginning of a method. Instead, you can use the method's implicit begin and only use an explicit begin...end block when you want to handle exceptions in a specific part of your method. This practice will lead to cleaner and more efficient code.

View in Datadog  Leave us feedback  Documentation

definition = Bundler::Definition.build(gemfile_name, nil, nil)
definition.dependencies.each do |dependency|
gem_name = dependency.name
version = dependency.requirement.to_s
update_gem_versions(runtime, gem_name, version, min_gems, max_gems)
end
rescue Bundler::GemfileError => e
puts "Error reading Gemfile: #{e.message}"
end
end

def process_lockfile(gemfile_name, runtime, min_gems, max_gems)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Code Quality Violation

Avoid top-level methods definition. Organize methods in modules/classes. (...read more)

This rule emphasizes the importance of organizing methods within modules or classes in Ruby. In Ruby, it's considered a best practice to wrap methods within classes or modules. This is because it helps in grouping related methods together, which in turn makes the code easier to understand, maintain, and reuse.

Not adhering to this rule can lead to a disorganized codebase, making it hard for other developers to understand and maintain the code. It can also lead to potential name clashes if a method is defined in the global scope.

To avoid violating this rule, always define your methods within a class or a module. For example, instead of writing def some_method; end, you should write class SomeClass def some_method; end end. This not only adheres to the rule but also improves the readability and maintainability of your code.

View in Datadog  Leave us feedback  Documentation

lockfile_contents = File.read(gemfile_name)
parser = Bundler::LockfileParser.new(lockfile_contents)
parser.specs.each do |spec|
gem_name = spec.name
version = spec.version.to_s
update_gem_versions(runtime, gem_name, version, min_gems, max_gems)
end
end

def update_gem_versions(runtime, gem_name, version, min_gems, max_gems)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Code Quality Violation

Avoid top-level methods definition. Organize methods in modules/classes. (...read more)

This rule emphasizes the importance of organizing methods within modules or classes in Ruby. In Ruby, it's considered a best practice to wrap methods within classes or modules. This is because it helps in grouping related methods together, which in turn makes the code easier to understand, maintain, and reuse.

Not adhering to this rule can lead to a disorganized codebase, making it hard for other developers to understand and maintain the code. It can also lead to potential name clashes if a method is defined in the global scope.

To avoid violating this rule, always define your methods within a class or a module. For example, instead of writing def some_method; end, you should write class SomeClass def some_method; end end. This not only adheres to the rule but also improves the readability and maintainability of your code.

View in Datadog  Leave us feedback  Documentation

return unless version_valid?(version)

gem_version = Gem::Version.new(version)

# Update minimum gems
if min_gems[runtime][gem_name].nil? || gem_version < Gem::Version.new(min_gems[runtime][gem_name])
min_gems[runtime][gem_name] = version
end

# Update maximum gems
if max_gems[runtime][gem_name].nil? || gem_version > Gem::Version.new(max_gems[runtime][gem_name])
max_gems[runtime][gem_name] = version
end
end



# Helper: Validate the version format
def version_valid?(version)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Code Quality Violation

Avoid top-level methods definition. Organize methods in modules/classes. (...read more)

This rule emphasizes the importance of organizing methods within modules or classes in Ruby. In Ruby, it's considered a best practice to wrap methods within classes or modules. This is because it helps in grouping related methods together, which in turn makes the code easier to understand, maintain, and reuse.

Not adhering to this rule can lead to a disorganized codebase, making it hard for other developers to understand and maintain the code. It can also lead to potential name clashes if a method is defined in the global scope.

To avoid violating this rule, always define your methods within a class or a module. For example, instead of writing def some_method; end, you should write class SomeClass def some_method; end end. This not only adheres to the rule but also improves the readability and maintainability of your code.

View in Datadog  Leave us feedback  Documentation

return false if version.nil?

version = version.to_s.strip

return false if version.empty?

# Ensure it's a valid Gem::Version
begin
Gem::Version.new(version)
true
rescue ArgumentError
false
end
end

def get_integration_names(directory = 'lib/datadog/tracing/contrib/')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Code Quality Violation

Avoid top-level methods definition. Organize methods in modules/classes. (...read more)

This rule emphasizes the importance of organizing methods within modules or classes in Ruby. In Ruby, it's considered a best practice to wrap methods within classes or modules. This is because it helps in grouping related methods together, which in turn makes the code easier to understand, maintain, and reuse.

Not adhering to this rule can lead to a disorganized codebase, making it hard for other developers to understand and maintain the code. It can also lead to potential name clashes if a method is defined in the global scope.

To avoid violating this rule, always define your methods within a class or a module. For example, instead of writing def some_method; end, you should write class SomeClass def some_method; end end. This not only adheres to the rule but also improves the readability and maintainability of your code.

View in Datadog  Leave us feedback  Documentation

Datadog::Tracing::Contrib::REGISTRY.map{ |i| i.name.to_s }
end

SPECIAL_CASES = {
"opensearch" => "OpenSearch" # special case because opensearch = OpenSearch not Opensearch
}.freeze

excluded = ["configuration", "propagation", "utils"]
min_gems_ruby, min_gems_jruby, max_gems_ruby, max_gems_jruby = parse_gemfiles("gemfiles/")
integrations = get_integration_names('lib/datadog/tracing/contrib/')

integration_json_mapping = {}

integrations.each do |integration|
next if excluded.include?(integration)

begin
mod_name = SPECIAL_CASES[integration] || integration.split('_').map(&:capitalize).join
module_name = "Datadog::Tracing::Contrib::#{mod_name}"
integration_module = Object.const_get(module_name)::Integration
integration_name = integration_module.respond_to?(:gem_name) ? integration_module.gem_name : integration
rescue NameError
puts "Integration module not found for #{integration}, falling back to integration name."
integration_name = integration
rescue NoMethodError
puts "gem_name method missing for #{integration}, falling back to integration name."
integration_name = integration
end

min_version_jruby = min_gems_jruby[integration_name]
min_version_ruby = min_gems_ruby[integration_name]
max_version_jruby = max_gems_jruby[integration_name]
max_version_ruby = max_gems_ruby[integration_name]

integration_json_mapping[integration] = [
min_version_ruby, max_version_ruby,
min_version_jruby, max_version_jruby
]
end

# Sort and output the mapping
integration_json_mapping = integration_json_mapping.sort.to_h
File.write("gem_output.json", JSON.pretty_generate(integration_json_mapping))
21 changes: 21 additions & 0 deletions .github/scripts/generate_table_versions.rb
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
require 'json'

input_file = 'gem_output.json'
output_file = 'integration_versions.md'

data = JSON.parse(File.read(input_file))

comment = "# Integrations\n\n"
header = "| Integration | Ruby Min | Ruby Max | JRuby Min | JRuby Max |\n"
separator = "|-------------|----------|-----------|----------|----------|\n"
rows = data.map do |integration_name, versions|
ruby_min, ruby_max, jruby_min, jruby_max = versions.map { |v| v || "None" }
"| #{integration_name} | #{ruby_min} | #{ruby_max} | #{jruby_min} | #{jruby_max} |"
end

File.open(output_file, 'w') do |file|
file.puts comment
file.puts header
file.puts separator
rows.each { |row| file.puts row }
end
52 changes: 52 additions & 0 deletions .github/workflows/generate-supported-versions.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
name: "Generate Supported Versions"

on:
push:
branches:
- quinna.halim/add-supported-versions-table
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note to self: remove before merge

workflow_dispatch:


concurrency:
group: ${{ github.workflow }}
cancel-in-progress: true

jobs:
build:
runs-on: ubuntu-22.04
permissions:
contents: read
steps:
- name: Checkout code
uses: actions/checkout@v4

- name: Set up Ruby
uses: ruby/setup-ruby@v1
with:
bundler-cache: true # runs bundle install
ruby-version: "3.3"

- name: Update latest
run: bundle exec ruby .github/scripts/find_gem_version_bounds.rb

- name: Generate versions table
run: ruby .github/scripts/generate_table_versions.rb

- run: git diff

- name: Create Pull Request
id: cpr
uses: peter-evans/create-pull-request@v7
with:
token: ${{ secrets.GHA_PAT }}
branch: auto-generate/update-supported-versions
title: '[🤖] Update Supported Versions'
base: master
labels: dev/internal, integrations
commit-message: "Test creating supported versions"
delete-branch: true
body: |
This is a PR to update the table for supported integration versions.
Workflow run: [Generate Supported Versions](https://github.com/DataDog/dd-trace-rb/actions/workflows/generate-supported-versions.yml)
This should be tied to tracer releases, or triggered manually.

3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/action_cable/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :action_cable, auto_patch: false
def self.gem_name
'actioncable'
end

def self.version
Gem.loaded_specs['actioncable'] && Gem.loaded_specs['actioncable'].version
Expand Down
4 changes: 4 additions & 0 deletions lib/datadog/tracing/contrib/action_mailer/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,10 @@ class Integration
# @public_api Changing the integration name or integration options can cause breaking changes
register_as :action_mailer, auto_patch: false

def self.gem_name
'actionmailer'
end

def self.version
Gem.loaded_specs['actionmailer'] && Gem.loaded_specs['actionmailer'].version
end
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/action_pack/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :action_pack, auto_patch: false
def self.gem_name
'actionpack'
end

def self.version
Gem.loaded_specs['actionpack'] && Gem.loaded_specs['actionpack'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/action_view/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :action_view, auto_patch: false
def self.gem_name
'actionview'
end

def self.version
# ActionView is its own gem in Rails 4.1+
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/active_job/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :active_job, auto_patch: false
def self.gem_name
'activejob'
end

def self.version
Gem.loaded_specs['activejob'] && Gem.loaded_specs['activejob'].version
Expand Down
4 changes: 4 additions & 0 deletions lib/datadog/tracing/contrib/active_record/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,10 @@ class Integration
# @public_api Changing the integration name or integration options can cause breaking changes
register_as :active_record, auto_patch: false

def self.gem_name
'activerecord'
end

def self.version
Gem.loaded_specs['activerecord'] && Gem.loaded_specs['activerecord'].version
end
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/active_support/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -19,6 +19,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :active_support, auto_patch: false
def self.gem_name
'activesupport'
end

def self.version
Gem.loaded_specs['activesupport'] && Gem.loaded_specs['activesupport'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/aws/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :aws, auto_patch: true
def self.gem_name
'aws-sdk-core'
end

def self.version
if Gem.loaded_specs['aws-sdk']
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/concurrent_ruby/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :concurrent_ruby
def self.gem_name
'concurrent-ruby'
end

def self.version
Gem.loaded_specs['concurrent-ruby'] && Gem.loaded_specs['concurrent-ruby'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/httprb/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :httprb
def self.gem_name
'http'
end

def self.version
Gem.loaded_specs['http'] && Gem.loaded_specs['http'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/kafka/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :kafka, auto_patch: false
def self.gem_name
'ruby-kafka'
end

def self.version
Gem.loaded_specs['ruby-kafka'] && Gem.loaded_specs['ruby-kafka'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/mongodb/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :mongo, auto_patch: true
def self.gem_name
'mongo'
end

def self.version
Gem.loaded_specs['mongo'] && Gem.loaded_specs['mongo'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/opensearch/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :opensearch, auto_patch: true
def self.gem_name
'opensearch-ruby'
end

def self.version
Gem.loaded_specs['opensearch-ruby'] \
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/presto/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :presto
def self.gem_name
'presto-client'
end

def self.version
Gem.loaded_specs['presto-client'] && Gem.loaded_specs['presto-client'].version
Expand Down
3 changes: 3 additions & 0 deletions lib/datadog/tracing/contrib/rest_client/integration.rb
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,9 @@ class Integration

# @public_api Changing the integration name or integration options can cause breaking changes
register_as :rest_client
def self.gem_name
'rest-client'
end

def self.version
Gem.loaded_specs['rest-client'] && Gem.loaded_specs['rest-client'].version
Expand Down
Loading