Skip to content

Commit

Permalink
Rename 'Node' to 'Node.js' in a few places
Browse files Browse the repository at this point in the history
  • Loading branch information
watson committed Jan 9, 2025
1 parent d249abf commit cb6f36e
Show file tree
Hide file tree
Showing 6 changed files with 7 additions and 7 deletions.
2 changes: 1 addition & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ All notable changes to this project will be documented in this file.

* 2024-05-27 [Use semver for version parser](https://github.com/DataDog/system-tests/pull/2487) by @cbeauchesne
* 2024-05-07 [[python] decrease the waiting time for python libraries from 25s to 5s](https://github.com/DataDog/system-tests/pull/2431) by @christophe-papazian
* 2024-05-29 [Manifest references + Node semver migration](https://github.com/DataDog/system-tests/pull/2416) by @simon-id
* 2024-05-29 [Manifest references + Node.js semver migration](https://github.com/DataDog/system-tests/pull/2416) by @simon-id
* 2024-05-03 [Dynamically compute scenarios to run](https://github.com/DataDog/system-tests/pull/2408) by @cbeauchesne


Expand Down
2 changes: 1 addition & 1 deletion docs/scenarios/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -54,4 +54,4 @@ Automatic library injection simplifies the APM onboarding experience for custome

The lib-injection project is a feature to allow injection of the Datadog library into a customer's application container without requiring them to modify their application images.

This feature enables applications written in Java, Node, Python, .NET or Ruby running in Kubernetes to be automatically instrumented with the corresponding Datadog APM libraries. More detailled documentation can be found [here](https://github.com/DataDog/system-tests/blob/main/docs/scenarios/k8s_lib_injection.md).
This feature enables applications written in Java, Node.js, Python, .NET or Ruby running in Kubernetes to be automatically instrumented with the corresponding Datadog APM libraries. More detailled documentation can be found [here](https://github.com/DataDog/system-tests/blob/main/docs/scenarios/k8s_lib_injection.md).
2 changes: 1 addition & 1 deletion docs/scenarios/k8s_lib_injection.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ The lib-injection project is a feature to allow injection of the Datadog library
into a customer's application container without requiring them to modify their
application images.

This feature enables applications written in Java, Node, Python, .NET or Ruby running
This feature enables applications written in Java, Node.js, Python, .NET or Ruby running
in Kubernetes to be automatically instrumented with the corresponding Datadog
APM libraries.

Expand Down
4 changes: 2 additions & 2 deletions lib-injection/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ The lib-injection project is a feature to allow injection of the Datadog library
into a customer's application container without requiring them to modify their
application images.

This feature enables applications written in Java, Node or Python running
This feature enables applications written in Java, Node.js or Python running
in Kubernetes to be automatically instrumented with the corresponding Datadog
APM libraries.

Expand Down Expand Up @@ -43,7 +43,7 @@ The Datadog admission controller is a component of the Datadog Cluster Agent. It

Lib injection testing is part of the "system-tests" test suite. Although we run it in isolation from the system-tests, they share certain similarities

To test lib-injection/autoinstrumentation feature, we run a Kubernetes cluster with the Datadog Cluster Agent and we check that the instrumentation runs smoothly using different sample applications (weblog) in different languages (currently Java, Python and Node).
To test lib-injection/autoinstrumentation feature, we run a Kubernetes cluster with the Datadog Cluster Agent and we check that the instrumentation runs smoothly using different sample applications (weblog) in different languages (currently Java, Python and Node.js).

The following image represents, in general terms, the necessary and dependent architecture to be able to run lib-injection tests:

Expand Down
2 changes: 1 addition & 1 deletion tests/parametric/test_otel_env_vars.py
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,7 @@ class Test_Otel_Env_Vars:
{
"DD_SERVICE": "service",
"OTEL_SERVICE_NAME": "otel_service",
"DD_TRACE_LOG_LEVEL": "error", # Node uses DD_TRACE_LOG_LEVEL
"DD_TRACE_LOG_LEVEL": "error", # Node.js uses DD_TRACE_LOG_LEVEL
"DD_LOG_LEVEL": "error",
"DD_TRACE_DEBUG": "false",
"OTEL_LOG_LEVEL": "debug",
Expand Down
2 changes: 1 addition & 1 deletion tests/test_config_consistency.py
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ def setup_query_string_obfuscation_empty_client(self):
self.r = weblog.get("/make_distant_call", params={"url": "http://weblog:7777/?key=monkey"})

@bug(context.library == "java", reason="APMAPI-770")
@missing_feature(context.library == "nodejs", reason="Node only obfuscates queries on the server side")
@missing_feature(context.library == "nodejs", reason="Node.js only obfuscates queries on the server side")
@missing_feature(context.library == "golang", reason="Go only obfuscates queries on the server side")
def test_query_string_obfuscation_empty_client(self):
spans = [s for _, _, s in interfaces.library.get_spans(request=self.r, full_trace=True)]
Expand Down

0 comments on commit cb6f36e

Please sign in to comment.