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

Merged
merged 46 commits into from
Jan 8, 2025

Conversation

quinna-h
Copy link
Contributor

@quinna-h quinna-h commented Dec 9, 2024

What does this PR do?

  • Adds a script find_gem_version_bounds.rb that parses gemfiles to get the minimum and maximum supported version for integrations, which is run in the workflow Generate Supported Versions
  • The script generate_table_versions.rb outputs the integrations and minimum supported versions in a markdown table.
  • Adds the gem names in the integration declarations

Generated PR example: #4236

Motivation:
Part of Autodoc generation for supported versions.

Change log entry
No.

Additional Notes:

How to test the change?

@quinna-h quinna-h added the dev/internal Other internal work that does not need to be included in the changelog label Dec 9, 2024
Copy link

github-actions bot commented Dec 9, 2024

Thank you for updating Change log entry section 👏

Visited at: 2024-12-12 08:50:22 UTC

find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
@pr-commenter
Copy link

pr-commenter bot commented Dec 9, 2024

Benchmarks

Benchmark execution time: 2025-01-08 02:11:28

Comparing candidate commit 3f1112e in PR branch quinna.halim/add-supported-versions-table with baseline commit d5f88ea in branch master.

Found 1 performance improvements and 0 performance regressions! Performance is the same for 30 metrics, 2 unstable metrics.

scenario:profiler - sample timeline=false

  • 🟩 throughput [+0.526op/s; +0.534op/s] or [+8.804%; +8.935%]

find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
find_min_gemfile.rb Outdated Show resolved Hide resolved
@quinna-h quinna-h requested a review from TonyCTHsu December 11, 2024 15:11
.github/scripts/find_min_gemfile.rb Outdated Show resolved Hide resolved
.github/scripts/find_min_gemfile.rb Outdated Show resolved Hide resolved
.github/scripts/find_min_gemfile.rb Outdated Show resolved Hide resolved
.github/scripts/find_min_gemfile.rb Outdated Show resolved Hide resolved
.github/scripts/find_min_gemfile.rb Outdated Show resolved Hide resolved
.github/scripts/find_min_gemfile.rb Outdated Show resolved Hide resolved
@datadog-datadog-prod-us1
Copy link
Contributor

datadog-datadog-prod-us1 bot commented Dec 11, 2024

Datadog Report

Branch report: quinna.halim/add-supported-versions-table
Commit report: 3f1112e
Test service: dd-trace-rb

✅ 0 Failed, 22119 Passed, 1476 Skipped, 5m 17.56s Total Time

.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
integration_versions.md Outdated Show resolved Hide resolved
integration_versions.md Outdated Show resolved Hide resolved
@marcotc
Copy link
Member

marcotc commented Dec 13, 2024

Potentially either the existing Update Latest Dependency workflow or a new workflow

I'd say add it to Update Latest Dependency for now. It should technically be on every PR that changes dependencies, but would be tricky to coordinate two automated commits at the same time (this and the existing Lock Dependency action).

.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
.github/scripts/find_gem_version_bounds.rb Outdated Show resolved Hide resolved
@quinna-h
Copy link
Contributor Author

Potentially either the existing Update Latest Dependency workflow or a new workflow

I'd say add it to Update Latest Dependency for now. It should technically be on every PR that changes dependencies, but would be tricky to coordinate two automated commits at the same time (this and the existing Lock Dependency action).

I think we are going to end up putting it in a separate workflow, as we want it to be tied to the tracer release process (but for now make it manual, aka triggered on workflow dispatch)

ivoanjo and others added 21 commits January 7, 2025 20:42
**What does this PR do?**

This PR builds atop #4237 and fixes a similar-ish issue in the profiler
caused by the same mishandling of ipv6 addresses.

In particular, when provided with an ipv6 address in the agent url,
the profiler would fail with an exception:

```
$ env DD_AGENT_HOST=2001:db8:1::2 DD_PROFILING_ENABLED=true \
bundle exec ddprofrb exec ruby -e "sleep 2"

dd-trace-rb/lib/datadog/profiling/http_transport.rb:27:in `initialize':
Failed to initialize transport: invalid authority (ArgumentError)
```

**Motivation:**

Luckily we didn't have any customers using this, as it fails immediately
and loudly, but it's still a bug on a configuration that should be
supported.

**Additional Notes:**

Since we had similar buggy logic copy-pasted in crashtracking and
profiling (crashtracking had been fixed in #4237) I chose to extract
out the relevant logic into the `AgentSettings` class, so that
both can reuse it.

**How to test the change?**

I've added unit test coverage for this issue to profiling, and
the snippet above can be used to end-to-end test it's working fine.

Here's how it looks on my machine now:

```
E, [2025-01-02T17:32:32.398756 #359317] ERROR -- datadog: [datadog]
(dd-trace-rb/lib/datadog/profiling/http_transport.rb:68:in `export')
Failed to report profiling data (agent: http://[2001:db8:1::2]:8126/):
failed ddog_prof_Exporter_send: error trying to connect: tcp connect
error: Network is unreachable (os error 101): tcp connect error:
Network is unreachable (os error 101): Network is unreachable (os error 101)
```

E.g. we correctly try to connect to the dummy address, and fail :)

(Note: The error message is a bit ugly AND repeats itself a bit.
That's being tracked separately
in DataDog/libdatadog#283 )
Forgot this one, some of our tests relied on it!
… leak

Since our exceptions match on the stack, they are affected by internal
naming changes, and it looks like a new `ruby_xcalloc_body` function
is now showing up in the stack.
This is waaay incomplete in terms of adding support for Ruby 3.5 but
should get us going for ASAN testing for now.
In practice this shouldn't make a difference, since the final lockfiles
are supposed to be a superset of the root-level gemfile BUT the
`Appraisals` file no longer exists anyway and "just in case" let's
have it anyway as it seems more correct.
This is not expected to be an issue in 3.5 (and is probably fixed for
3.4 as well, but I'll leave that for a separate PR to not affect the
appraisals).
This checker is used to detect accidental thread scheduling switching
points happening during profiling sampling.

See the bigger comment in unsafe_api_calls_check.h .

I was able to check that this checker correctly triggers for the bug
in #4195, and also the bug I'm going to fix next, which is the
use of `rb_hash_lookup` in the otel context reading code.
`rb_hash_lookup` calls `#hash` on the key being looked up so it's safe
to use unless during sampling.

This can cause the same issue as we saw in #4195 leading to

```
[BUG] unexpected situation - recordd:1 current:0

-- C level backtrace information -------------------------------------------
ruby(rb_print_backtrace+0x11) [0x55ba03ccf90f] vm_dump.c:820
ruby(rb_vm_bugreport) vm_dump.c:1151
ruby(bug_report_end+0x0) [0x55ba03e91607] error.c:1042
ruby(rb_bug_without_die) error.c:1042
ruby(die+0x0) [0x55ba03ac0998] error.c:1050
ruby(rb_bug) error.c:1052
ruby(disallow_reentry+0x0) [0x55ba03ab6dcc] vm_sync.c:226
ruby(rb_ec_vm_lock_rec_check+0x1a) [0x55ba03cb17aa] eval_intern.h:144
ruby(rb_ec_tag_state) eval_intern.h:155
ruby(rb_vm_exec) vm.c:2484
ruby(vm_invoke_proc+0x201) [0x55ba03cb62b1] vm.c:1509
ruby(rb_vm_invoke_proc+0x33) [0x55ba03cb65d3] vm.c:1728
ruby(thread_do_start_proc+0x176) [0x55ba03c63516] thread.c:598
ruby(thread_do_start+0x12) [0x55ba03c648a2] thread.c:615
ruby(thread_start_func_2) thread.c:672
ruby(nt_start+0x107) [0x55ba03c65137] thread_pthread.c:2187
/lib/x86_64-linux-gnu/libpthread.so.0(start_thread+0xd9) [0x7ff360b66609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7ff360a70353]
```
During my experiments to reproduce issues around allocation profiling,
I've noted that the VM is in an especially delicate state during
exception raising, so let's just decline to sample in this situation.
It occurs to me that if a symbol is dynamic, we were causing it to
become a static symbol (e.g. making it never be able to be garbage
collected).

This can be very bad! And also, we know the symbol we're looking for
must be a static symbol because if nothing else, our initialization
caused it to become a static symbol.

Thus, if we see a dynamic symbol, we can stop there, since by
definition it won't be the symbol we're looking after.

This is... really awkward to add a specific unit test for, so
I've just relied on our existing test coverage to show that this
has not affected the correctness of our otel code.
update workflow file
@quinna-h quinna-h force-pushed the quinna.halim/add-supported-versions-table branch from dbd211a to cb788d7 Compare January 8, 2025 01:43
@quinna-h quinna-h requested review from a team as code owners January 8, 2025 01:43
@github-actions github-actions bot added core Involves Datadog core libraries profiling Involves Datadog profiling labels Jan 8, 2025
@marcotc marcotc merged commit c3cd448 into master Jan 8, 2025
337 checks passed
@marcotc marcotc deleted the quinna.halim/add-supported-versions-table branch January 8, 2025 02:13
@github-actions github-actions bot added this to the 2.9.0 milestone Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Involves Datadog core libraries dev/github Github repository maintenance and automation dev/internal Other internal work that does not need to be included in the changelog integrations Involves tracing integrations profiling Involves Datadog profiling tracing
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants