Nit: Fix spelling of Node.js and .NET

.gitlab-ci.yml

@@ -122,7 +122,7 @@ variables:
     reports:
       dotenv: run.env
 
-# ----------- Nodejs SSI ----------------
+# ----------- Node.js SSI ----------------
 step1_generate_nodejs_ssi_pipeline:
   extends: .step1_generate_aws_ssi_pipeline
   needs: []
@@ -355,7 +355,7 @@ step2_exec_php_ssi_pipeline:
         job: x_merge_php_ssi_pipeline
     strategy: depend
 
-# ----------- Dotnet SSI ----------------
+# ----------- .NET SSI ----------------
 step1_generate_dotnet_ssi_pipeline:
   stage: dotnet_ssi_pipelines
   dependencies: []

CHANGELOG.md

@@ -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
 
 
@@ -116,7 +116,7 @@ All notable changes to this project will be documented in this file.
 ### October 2023 (100 PR merged)
 
 * 2023-10-09 [New python/FastAPI variant](https://github.com/DataDog/system-tests/pull/1663) by @christophe-papazian
-* 2023-10-27 [New NodeJS/NextJS variant](https://github.com/DataDog/system-tests/pull/1662) by @uurien
+* 2023-10-27 [New Node.js/NextJS variant](https://github.com/DataDog/system-tests/pull/1662) by @uurien
 * 2023-10-01 [New scenario for testing debugger probes](https://github.com/DataDog/system-tests/pull/1632) by @shurivich
 
 ### September 2023 (84 PR merged)

docs/execute/README.md

@@ -9,7 +9,7 @@ You will need a bash based terminal, python3.12, git and docker. Clone this fold
 ./run.sh     # run tests
 ```
 
-By default, test will be executed on the nodeJS library. Please have a look on [build.sh CLI's documentation](./build.md) for more options.
+By default, test will be executed on the Node.js library. Please have a look on [build.sh CLI's documentation](./build.md) for more options.
 
 `./run.sh` has [some options](./run.md), but for now, you won't need them.
 

docs/execute/binaries.md

@@ -81,7 +81,7 @@ Then run the OpenTelemetry drop-in test from the repo root folder:
 - `./build.sh java`
 - `TEST_LIBRARY=java ./run.sh INTEGRATIONS -k Test_Otel_Drop_In`
 
-## NodeJS library
+## Node.js library
 
 There are three ways to run system-tests with a custom node tracer.
 

docs/execute/troubleshooting.md

@@ -36,7 +36,7 @@ Adjust file permissions on your `.docker`:
 sudo chown -R $(whoami) ~/.docker
 ```
 
-## NodeJs weblog experimenting segfaults on Mac/Intel
+## Node.js weblog experimenting segfaults on Mac/Intel
 
 In the docker dashboard -> settings -> general, untick `Use Virtualization Framework`. See this [Stack overflow thread](https://stackoverflow.com/questions/76735062/segmentation-fault-in-node-js-application-running-in-docker) for more information.
 

docs/scenarios/README.md

@@ -48,10 +48,10 @@ Parametric scenarios are designed to validate tracer and span interfaces. They a
 
 ### Auto-Inject/OnBoarding scenarios
 
-Automatic library injection simplifies the APM onboarding experience for customers deploying Java, NodeJS, .NET, Python and Ruby applications in VMs and docker environments. Datadog software installed on the machine will be intercept the startup of your application and it will inject the tracer library automatically. The OnBoarding scenarios reproduce different environments and check the library injection is done correctly. More detailled documentation can be found [here](https://github.com/DataDog/system-tests/blob/main/docs/scenarios/onboarding.md).
+Automatic library injection simplifies the APM onboarding experience for customers deploying Java, Node.js, .NET, Python and Ruby applications in VMs and docker environments. Datadog software installed on the machine will be intercept the startup of your application and it will inject the tracer library automatically. The OnBoarding scenarios reproduce different environments and check the library injection is done correctly. More detailled documentation can be found [here](https://github.com/DataDog/system-tests/blob/main/docs/scenarios/onboarding.md).
 
 ### Kubernetes Auto-Inject scenarios
 
 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, DotNet 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).

docs/scenarios/k8s_lib_injection.md

@@ -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, DotNet 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.
 
@@ -64,7 +64,7 @@ These test components are also involved through the testing process:
 
 - **System-tests runner:** The core of the system-tests is the reponsible for orchestrate the tests execution and manage the tests results.
 - **Dev test agent:**  The APM Test Agent container help us to perform the validations ([APM Test Agent](https://github.com/DataDog/dd-apm-test-agent)).
-- **Sample app/weblog:** Containerized sample application implemented on Java, Nodejs, dotNet, Ruby or Python.
+- **Sample app/weblog:** Containerized sample application implemented on Java, Node.js, .NET, Ruby or Python.
 
 The following image represents, in general terms, the necessary and dependent architecture to be able to run the K8s library injection tests:
 
@@ -208,22 +208,22 @@ or if you don't have the permission to push the image to GHCR, you can use your
 
 The sample applications currently available in GHCR are:
 
-|  LANG | WEBLOG IMAGE |
-|---|---|
-| Java |  ghcr.io/datadog/system-tests/dd-lib-java-init-test-app:latest  |
-| Java | ghcr.io/datadog/system-tests/dd-djm-spark-test-app:latest  |
-| DotNet  | ghcr.io/datadog/system-tests/dd-lib-dotnet-init-test-app:latest  |
-| Nodejs  | ghcr.io/datadog/system-tests/sample-app:latest  |
+| LANG    | WEBLOG IMAGE |
+|---------|--------------|
+| Java    | ghcr.io/datadog/system-tests/dd-lib-java-init-test-app:latest  |
+| Java    | ghcr.io/datadog/system-tests/dd-djm-spark-test-app:latest  |
+| .NET    | ghcr.io/datadog/system-tests/dd-lib-dotnet-init-test-app:latest  |
+| Node.js | ghcr.io/datadog/system-tests/sample-app:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-django:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-django-gunicorn:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-django-gunicorn-alpine:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-django-preinstalled:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-django-unsupported-package-force:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-django-uvicorn:latest  |
 | Python  | ghcr.io/datadog/system-tests/dd-lib-python-init-test-protobuf-old:latest  |
-| Ruby  | ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails:latest  |
-| Ruby  | ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails-explicit":latest  |
-| Ruby  | ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails-gemsrb:latest  |
+| Ruby    | ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails:latest  |
+| Ruby    | ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails-explicit":latest  |
+| Ruby    | ghcr.io/datadog/system-tests/dd-lib-ruby-init-test-rails-gemsrb:latest  |
 
 ##### Library init image
 
@@ -233,18 +233,18 @@ The library init images are created by each tracer library and these images will
 
 The list of available images is:
 
-|  LANG | LIB INIT IMAGE |
-|---|---|
-| Java |  gcr.io/datadoghq/dd-lib-java-init:latest |
-| Java | ghcr.io/datadog/dd-trace-java/dd-lib-java-init:latest_snapshot  |
-| DotNet  | gcr.io/datadoghq/dd-lib-dotnet-init:latest |
-| DotNet  | ghcr.io/datadog/dd-trace-dotnet/dd-lib-dotnet-init:latest_snapshot |
-| Nodejs  | gcr.io/datadoghq/dd-lib-js-init:latest |
-| Nodejs  | ghcr.io/datadog/dd-trace-js/dd-lib-js-init:latest_snapshot |
+| LANG    | LIB INIT IMAGE |
+|---------|----------------|
+| Java    | gcr.io/datadoghq/dd-lib-java-init:latest |
+| Java    | ghcr.io/datadog/dd-trace-java/dd-lib-java-init:latest_snapshot  |
+| .NET    | gcr.io/datadoghq/dd-lib-dotnet-init:latest |
+| .NET    | ghcr.io/datadog/dd-trace-dotnet/dd-lib-dotnet-init:latest_snapshot |
+| Node.js | gcr.io/datadoghq/dd-lib-js-init:latest |
+| Node.js | ghcr.io/datadog/dd-trace-js/dd-lib-js-init:latest_snapshot |
 | Python  | gcr.io/datadoghq/dd-lib-python-init:latest |
 | Python  | ghcr.io/datadog/dd-trace-py/dd-lib-python-init:latest_snapshot  |
-| Ruby  | gcr.io/datadoghq/dd-lib-ruby-init:latest  |
-| Ruby  | ghcr.io/datadog/dd-trace-rb/dd-lib-ruby-init:latest_snapshot |
+| Ruby    | gcr.io/datadoghq/dd-lib-ruby-init:latest  |
+| Ruby    | ghcr.io/datadog/dd-trace-rb/dd-lib-ruby-init:latest_snapshot |
 
 ##### Datadog Cluster Agent
 

docs/scenarios/onboarding.md

@@ -23,7 +23,7 @@
 
 # Overall
 
-Similarly to Library Injection in Kubernetes environments via the admission controller, Library injection simplifies the APM onboarding experience for customers auto-intrumenting Java, Python, NodeJS, .NET, PHP or Ruby applications running on host or in docker environments.
+Similarly to Library Injection in Kubernetes environments via the admission controller, Library injection simplifies the APM onboarding experience for customers auto-intrumenting Java, Python, Node.js, .NET, PHP or Ruby applications running on host or in docker environments.
 
 The target of this testing feature is to test the distinct injection environments.
 

docs/scenarios/parametric.md

@@ -232,11 +232,11 @@ The http server implementations for each tracer can be found at the following lo
 * [Python](/utils/build/docker/python/parametric/apm_test_client/server.py)
 * [Ruby](/utils/build/docker/ruby/parametric/server.rb)
 * [Php](/utils/build/docker/php/parametric/server.php)
-* [Nodejs](/utils/build/docker/nodejs/parametric/server.js)
+* [Node.js](/utils/build/docker/nodejs/parametric/server.js)
 * [Java Datadog](/utils/build/docker/java/parametric/src/main/java/com/datadoghq/trace/opentracing/controller/OpenTracingController.java)
 * [Java Otel](/utils/build/docker/java/parametric/src/main/java/com/datadoghq/trace/opentelemetry/controller/OpenTelemetryController.java)
-* [Dotnet Datadog](/utils/build/docker/dotnet/parametric/Endpoints/ApmTestApi.cs)
-* [Dotnet Otel](/utils/build/docker/dotnet/parametric/Endpoints/ApmTestApiOtel.cs)
+* [.NET Datadog](/utils/build/docker/dotnet/parametric/Endpoints/ApmTestApi.cs)
+* [.NET Otel](/utils/build/docker/dotnet/parametric/Endpoints/ApmTestApiOtel.cs)
 * [Go Datadog](/utils/build/docker/golang/parametric/main.go)
 * [Go Otel](/utils/build/docker/golang/parametric/otel.go)
 

lib-injection/README.md

@@ -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.
 
@@ -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:
 

tests/integrations/crossed_integrations/test_sqs.py

@@ -125,7 +125,7 @@ def test_produce(self):
     @missing_feature(library="ruby", reason="Expected to fail, Ruby does not propagate context")
     @missing_feature(
         library="java",
-        reason="Expected to fail, Dotnet does not propagate context via msg attrs or uses xray which also doesn't work",
+        reason="Expected to fail, .NET does not propagate context via msg attrs or uses xray which also doesn't work",
     )
     def test_produce_trace_equality(self):
         """This test relies on the setup for produce, it currently cannot be run on its own"""
@@ -190,7 +190,7 @@ def test_consume(self):
 
     @missing_feature(library="golang", reason="Expected to fail, Golang does not propagate context")
     @missing_feature(library="ruby", reason="Expected to fail, Ruby does not propagate context")
-    @missing_feature(library="dotnet", reason="Expected to fail, Dotnet does not propagate context")
+    @missing_feature(library="dotnet", reason="Expected to fail, .NET does not propagate context")
     def test_consume_trace_equality(self):
         """This test relies on the setup for consume, it currently cannot be run on its own"""
         producer_span = self.get_span(
@@ -261,7 +261,7 @@ class Test_SQS_PROPAGATION_VIA_AWS_XRAY_HEADERS(_Test_SQS):
 
     @missing_feature(
         library="nodejs",
-        reason="Expected to fail, NodeJS will not create a response span \
+        reason="Expected to fail, Node.js will not create a response span \
                      propagating context since it cannot extract AWSTracerHeader context that Java injects",
     )
     def test_consume(self):
@@ -275,7 +275,7 @@ def test_produce_trace_equality(self):
     @missing_feature(library="golang", reason="Expected to fail, Golang does not propagate context")
     @missing_feature(library="ruby", reason="Expected to fail, Ruby does not propagate context")
     @missing_feature(library="python", reason="Expected to fail, Python does not propagate context")
-    @missing_feature(library="nodejs", reason="Expected to fail, Nodejs does not propagate context")
-    @missing_feature(library="dotnet", reason="Expected to fail, Dotnet will not extract from XRay headers")
+    @missing_feature(library="nodejs", reason="Expected to fail, Node.js does not propagate context")
+    @missing_feature(library="dotnet", reason="Expected to fail, .NET will not extract from XRay headers")
     def test_consume_trace_equality(self):
         super().test_consume_trace_equality()

tests/integrations/test_db_integrations_sql.py

@@ -294,7 +294,7 @@ def test_obfuscate_query(self, excluded_operations=()):
                 expected_obfuscation_count = 1
             elif db_operation == "procedure":
                 # Insert and procedure:These operations also receive two parameters, but are obfuscated as only one.
-                # Nodejs: The proccedure has a input parameter, but we are calling through method `execute`` and we can't see the parameters in the traces
+                # Node.js: The proccedure has a input parameter, but we are calling through method `execute`` and we can't see the parameters in the traces
                 expected_obfuscation_count = 0 if context.library.library == "nodejs" else 2
             else:
                 expected_obfuscation_count = 2

tests/integrations/test_dsm.py

@@ -170,7 +170,7 @@ def setup_dsm_rabbitmq_dotnet_legacy(self):
     def test_dsm_rabbitmq_dotnet_legacy(self):
         assert self.r.text == "ok"
 
-        # Dotnet sets the tag for `has_routing_key` to `has_routing_key:True` instead of `has_routing_key:true` like
+        # .NET sets the tag for `has_routing_key` to `has_routing_key:True` instead of `has_routing_key:true` like
         # the other tracer libraries, which causes the resulting hash to be different.
         DsmHelper.assert_checkpoint_presence(
             hash_=12547013883960139159,
@@ -529,7 +529,7 @@ def setup_dsm_manual_checkpoint_intra_process(self):
             timeout=DSM_REQUEST_TIMEOUT,
         )
 
-    @irrelevant(library="nodejs", reason="NodeJS doesn't sort the DSM edge tags and has different hashes.")
+    @irrelevant(library="nodejs", reason="Node.js doesn't sort the DSM edge tags and has different hashes.")
     def test_dsm_manual_checkpoint_intra_process(self):
         assert self.produce.status_code == 200
         assert self.produce.text == "ok"
@@ -602,7 +602,7 @@ def setup_dsm_manual_checkpoint_inter_process(self):
             timeout=DSM_REQUEST_TIMEOUT,
         )
 
-    @irrelevant(library="nodejs", reason="NodeJS doesn't sort the DSM edge tags and has different hashes.")
+    @irrelevant(library="nodejs", reason="Node.js doesn't sort the DSM edge tags and has different hashes.")
     def test_dsm_manual_checkpoint_inter_process(self):
         assert self.produce_threaded.status_code == 200
         assert self.produce_threaded.text == "ok"

tests/integrations/utils.py

@@ -45,7 +45,7 @@ def _setup(self):
                 "/db", params={"service": self.db_service, "operation": db_operation}
             )
         if self.db_service == "mssql":
-            # Nodejs opentelemetry-instrumentation-mssql is too old and select query is not tracer allways
+            # Node.js opentelemetry-instrumentation-mssql is too old and select query is not tracer allways
             # see https://github.com/mnadeem/opentelemetry-instrumentation-mssql
             # Retry to avoid flakyness
             logger.debug("Retry select query for mssql .....")

tests/parametric/test_otel_env_vars.py

@@ -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",

tests/parametric/test_otel_span_methods.py

@@ -429,7 +429,7 @@ def test_otel_get_span_context(self, test_agent, test_library):
                         # Some languages e.g. PHP return a hexadecimal span id
                         assert context.get("span_id") == span.span_id
                     else:
-                        # Some languages e.g. Nodejs using express need to return as a string value
+                        # Some languages e.g. Node.js using express need to return as a string value
                         # due to 64-bit integers being too large.
                         assert context.get("span_id") == "{:016x}".format(int(span.span_id))
                     assert context.get("trace_flags") == "01"