Apply Prettier to markdown files (#8968)

Author: trask

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,10 +1,9 @@
 ---
 name: Bug report
 about: Create a report to help us improve
-title: ''
+title: ""
 labels: bug
-assignees: ''
-
+assignees: ""
 ---
 
 **Describe the bug**

.github/ISSUE_TEMPLATE/feature_request.md

@@ -1,10 +1,9 @@
 ---
 name: Feature request
 about: Suggest an idea for this project
-title: ''
+title: ""
 labels: enhancement
-assignees: ''
-
+assignees: ""
 ---
 
 **Is your feature request related to a problem? Please describe.**

.github/repository-settings.md

@@ -6,13 +6,13 @@ settings](https://github.com/open-telemetry/community/blob/main/docs/how-to-conf
 
 ## General > Pull Requests
 
-* Allow squash merging > Default to pull request title
+- Allow squash merging > Default to pull request title
 
-* Allow auto-merge
+- Allow auto-merge
 
 ## Actions > General
 
-* Fork pull request workflows from outside collaborators:
+- Fork pull request workflows from outside collaborators:
   "Require approval for first-time contributors who are new to GitHub"
 
   (To reduce friction for new contributors,
@@ -22,14 +22,14 @@ settings](https://github.com/open-telemetry/community/blob/main/docs/how-to-conf
 
 ### `main`
 
-* Require branches to be up to date before merging: UNCHECKED
+- Require branches to be up to date before merging: UNCHECKED
 
   (PR jobs take too long, and leaving this unchecked has not been a significant problem)
 
-* Status checks that are required:
+- Status checks that are required:
 
-  * EasyCLA
-  * required-status-check
+  - EasyCLA
+  - required-status-check
 
 ### `release/*`
 
@@ -42,28 +42,28 @@ for [`dependabot/**/**`](https://github.com/open-telemetry/community/blob/main/d
 
 ### `gh-pages`
 
-* Everything UNCHECKED
+- Everything UNCHECKED
 
   (This branch is currently only used for directly pushing benchmarking results from the
   [Nightly overhead benchmark](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/nightly-benchmark-overhead.yml)
   job)
 
 ## Code security and analysis
 
-* Secret scanning: Enabled
+- Secret scanning: Enabled
 
 ## Secrets and variables > Actions
 
-* `GE_CACHE_PASSWORD`
-* `GE_CACHE_USERNAME`
-* `GPG_PASSWORD` - stored in OpenTelemetry-Java 1Password
-* `GPG_PRIVATE_KEY` - stored in OpenTelemetry-Java 1Password
-* `GRADLE_ENTERPRISE_ACCESS_KEY` - owned by [@trask](https://github.com/trask)
-  * Generated at https://ge.opentelemetry.io > My settings > Access keys
-  * format of env var is `ge.opentelemetry.io=<access key>`,
+- `GE_CACHE_PASSWORD`
+- `GE_CACHE_USERNAME`
+- `GPG_PASSWORD` - stored in OpenTelemetry-Java 1Password
+- `GPG_PRIVATE_KEY` - stored in OpenTelemetry-Java 1Password
+- `GRADLE_ENTERPRISE_ACCESS_KEY` - owned by [@trask](https://github.com/trask)
+  - Generated at https://ge.opentelemetry.io > My settings > Access keys
+  - format of env var is `ge.opentelemetry.io=<access key>`,
     see [docs](https://docs.gradle.com/enterprise/gradle-plugin/#via_environment_variable)
-* `GRADLE_PUBLISH_KEY`
-* `GRADLE_PUBLISH_SECRET`
-* `OPENTELEMETRYBOT_GITHUB_TOKEN` - owned by [@trask](https://github.com/trask)
-* `SONATYPE_KEY` - owned by [@trask](https://github.com/trask)
-* `SONATYPE_USER` - owned by [@trask](https://github.com/trask)
+- `GRADLE_PUBLISH_KEY`
+- `GRADLE_PUBLISH_SECRET`
+- `OPENTELEMETRYBOT_GITHUB_TOKEN` - owned by [@trask](https://github.com/trask)
+- `SONATYPE_KEY` - owned by [@trask](https://github.com/trask)
+- `SONATYPE_USER` - owned by [@trask](https://github.com/trask)

CHANGELOG.md

@@ -79,16 +79,16 @@
 - The `opentelemetry-runtime-metrics` artifact has been renamed and split into
   `opentelemetry-runtime-telemetry-java8` and `opentelemetry-runtime-telemetry-java17`
   ([#8165](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8165),
-   [#8715](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8715))
+  [#8715](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8715))
 - `InetSocketAddressNetServerAttributesGetter` and `InetSocketAddressNetClientAttributesGetter`
   have been deprecated
   ([#8341](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8341),
-   [#8591](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8591))
+  [#8591](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8591))
 - The new HTTP and network semantic conventions can be opted into using either the system
   property `otel.semconv-stability.opt-in` or the environment variable
   `OTEL_SEMCONV_STABILITY_OPT_IN`, which support two values:
   - `http` - emit the new, stable HTTP and networking attributes, and stop emitting the old
-   experimental HTTP and networking attributes that the instrumentation emitted previously.
+    experimental HTTP and networking attributes that the instrumentation emitted previously.
   - `http/dup` - emit both the old and the stable HTTP and networking attributes, allowing
     for a more seamless transition.
   - The default behavior (in the absence of one of these values) is to continue emitting
@@ -104,7 +104,7 @@
   ([#8487](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8487))
 - Reactor Kafka
   ([#8439](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8439),
-   [#8529](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8529))
+  [#8529](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8529))
 
 ### 📈 Enhancements
 
@@ -286,7 +286,7 @@
   ([#8174](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8174))
 - Spring scheduling: run error handler with the same context as task
   ([#8220](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8220))
-- Switch from http.flavor to net.protocol.*
+- Switch from http.flavor to net.protocol.\*
   ([#8131](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8131),
   [#8244](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/8244))
 - Support latest Armeria release
@@ -598,7 +598,7 @@
 
 ### 🧰 Tooling
 
-- Muzzle logs should be logged using the io.opentelemetry.* logger name
+- Muzzle logs should be logged using the io.opentelemetry.\* logger name
   ([#7446](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/7446))
 
 ## Version 1.21.0 (2022-12-13)
@@ -840,12 +840,12 @@ The `opentelemetry-instrumentation-api` artifact is declared stable in this rele
 
 - There were a few late-breaking changes in `opentelemetry-instrumentation-api`, prior to it being
   declared stable:
-  * `InstrumenterBuilder.addAttributesExtractors(AttributesExtractor...)` was removed, use instead
+  - `InstrumenterBuilder.addAttributesExtractors(AttributesExtractor...)` was removed, use instead
     `addAttributesExtractors(AttributesExtractor)` or
     `addAttributesExtractors(Iterable<AttributesExtractor>)`
-  * `SpanLinksExtractor.extractFromRequest()` was removed, use instead manual extraction
-  * `ErrorCauseExtractor.jdk()` was renamed to `ErrorCauseExtractor.getDefault()`
-  * `ClassNames` utility was removed with no direct replacement
+  - `SpanLinksExtractor.extractFromRequest()` was removed, use instead manual extraction
+  - `ErrorCauseExtractor.jdk()` was renamed to `ErrorCauseExtractor.getDefault()`
+  - `ClassNames` utility was removed with no direct replacement
 - The deprecated `io.opentelemetry.instrumentation.api.config.Config` and related classes
   have been removed
   ([#6501](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/6501))
@@ -1208,15 +1208,15 @@ The `opentelemetry-instrumentation-api` artifact is declared stable in this rele
 
 - Micrometer instrumentation is now automatically applied to spring-boot-actuator apps
 - Some configuration properties have been renamed:
-  * `otel.instrumentation.common.experimental.suppress-controller-spans`
+  - `otel.instrumentation.common.experimental.suppress-controller-spans`
     → `otel.instrumentation.common.experimental.controller-telemetry.enabled`
     (important: note that the meaning is inverted)
-  * `otel.instrumentation.common.experimental.suppress-view-spans`
+  - `otel.instrumentation.common.experimental.suppress-view-spans`
     → `otel.instrumentation.common.experimental.view-telemetry.enabled`
     (important: note that the meaning is inverted)
-  * `otel.instrumentation.netty.always-create-connect-span`
+  - `otel.instrumentation.netty.always-create-connect-span`
     → `otel.instrumentation.netty.connection-telemetry.enabled`
-  * `otel.instrumentation.reactor-netty.always-create-connect-span`
+  - `otel.instrumentation.reactor-netty.always-create-connect-span`
     → `otel.instrumentation.reactor-netty.connection-telemetry.enabled`
 - Runtime memory metric names were updated to reflect
   [semantic conventions](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/runtime-environment-metrics.md#jvm-metrics)
@@ -1519,7 +1519,7 @@ The `opentelemetry-instrumentation-api` artifact is declared stable in this rele
   ([#5112](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/5112))
 - Parameterize VirtualField field type
   ([#5165](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/5165))
-- Remove old TraceUtils and use InstrumentationTestRunner#run*Span() (almost) everywhere
+- Remove old TraceUtils and use InstrumentationTestRunner#run\*Span() (almost) everywhere
   ([#5160](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/5160))
 - Remove deprecated tracer API
   ([#5175](https://github.com/open-telemetry/opentelemetry-java-instrumentation/pull/5175))

RELEASING.md

@@ -18,20 +18,20 @@ the second Monday of the month (roughly a few of days after the monthly minor re
 
 ## Preparing a new major or minor release
 
-* Check that
+- Check that
   [dependabot has run](https://github.com/open-telemetry/opentelemetry-java-instrumentation/network/updates)
   sometime in the past day (this link is only accessible if you have write access to the
   repository), and check that all
   [dependabot PRs](https://github.com/open-telemetry/opentelemetry-java-contrib/pulls/app%2Fdependabot)
   have been merged.
-* Close the [release milestone](https://github.com/open-telemetry/opentelemetry-java-instrumentation/milestones)
+- Close the [release milestone](https://github.com/open-telemetry/opentelemetry-java-instrumentation/milestones)
   if there is one.
-* Merge a pull request to `main` updating the `CHANGELOG.md`.
-  * The heading for the unreleased entries should be `## Unreleased`.
-  * Use `.github/scripts/draft-change-log-entries.sh` as a starting point for writing the change log.
-* Run the [Prepare release branch workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/prepare-release-branch.yml).
-  * Press the "Run workflow" button, and leave the default branch `main` selected.
-  * Review and merge the two pull requests that it creates
+- Merge a pull request to `main` updating the `CHANGELOG.md`.
+  - The heading for the unreleased entries should be `## Unreleased`.
+  - Use `.github/scripts/draft-change-log-entries.sh` as a starting point for writing the change log.
+- Run the [Prepare release branch workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/prepare-release-branch.yml).
+  - Press the "Run workflow" button, and leave the default branch `main` selected.
+  - Review and merge the two pull requests that it creates
     (one is targeted to the release branch and one is targeted to `main`).
 
 ## Preparing a new patch release
@@ -41,31 +41,31 @@ All patch releases should include only bug-fixes, and must avoid adding/modifyin
 In general, patch releases are only made for regressions, security vulnerabilities, memory leaks
 and deadlocks.
 
-* Backport pull request(s) to the release branch.
-  * Run the [Backport workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/backport.yml).
-  * Press the "Run workflow" button, then select the release branch from the dropdown list,
+- Backport pull request(s) to the release branch.
+  - Run the [Backport workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/backport.yml).
+  - Press the "Run workflow" button, then select the release branch from the dropdown list,
     e.g. `release/v1.9.x`, then enter the pull request number that you want to backport,
     then click the "Run workflow" button below that.
-  * Review and merge the backport pull request that it generates.
-  * Note: if the PR contains any changes to workflow files, it will have to be manually backported,
+  - Review and merge the backport pull request that it generates.
+  - Note: if the PR contains any changes to workflow files, it will have to be manually backported,
     because the default `GITHUB_TOKEN` does not have permission to update workflow files (and the
     `opentelemetrybot` token doesn't have write permission to this repository at all, so while it
     can be used to open a PR, it can't be used to push to a local branch).
-* Merge a pull request to the release branch updating the `CHANGELOG.md`.
-  * The heading for the unreleased entries should be `## Unreleased`.
-* Run the [Prepare patch release workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/prepare-patch-release.yml).
-  * Press the "Run workflow" button, then select the release branch from the dropdown list,
+- Merge a pull request to the release branch updating the `CHANGELOG.md`.
+  - The heading for the unreleased entries should be `## Unreleased`.
+- Run the [Prepare patch release workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/prepare-patch-release.yml).
+  - Press the "Run workflow" button, then select the release branch from the dropdown list,
     e.g. `release/v1.9.x`, and click the "Run workflow" button below that.
-  * Review and merge the pull request that it creates for updating the version.
+  - Review and merge the pull request that it creates for updating the version.
 
 ## Making the release
 
-* Run the [Release workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/release.yml).
-  * Press the "Run workflow" button, then select the release branch from the dropdown list,
+- Run the [Release workflow](https://github.com/open-telemetry/opentelemetry-java-instrumentation/actions/workflows/release.yml).
+  - Press the "Run workflow" button, then select the release branch from the dropdown list,
     e.g. `release/v1.9.x`, and click the "Run workflow" button below that.
-  * This workflow will publish the artifacts to maven central and will publish a GitHub release
+  - This workflow will publish the artifacts to maven central and will publish a GitHub release
     with release notes based on the change log and with the javaagent jar attached.
-  * Review and merge the pull request that it creates for updating the change log in main
+  - Review and merge the pull request that it creates for updating the change log in main
     (note that if this is not a patch release then the change log on main may already be up-to-date,
     in which case no pull request will be created).
 

VERSIONING.md

@@ -9,15 +9,15 @@ Artifacts in this repository follow the same compatibility requirements describe
 EXCEPT for the following incompatible changes which are allowed in stable artifacts in this
 repository:
 
-* Changes to the telemetry produced by instrumentation
+- Changes to the telemetry produced by instrumentation
   (there will be some guarantees about telemetry stability in the future, see discussions
   in <https://github.com/open-telemetry/opentelemetry-specification/issues/1301>)
-* Changes to configuration properties that contain the word `experimental`
-* Changes to configuration properties under the namespace `otel.javaagent.testing`
+- Changes to configuration properties that contain the word `experimental`
+- Changes to configuration properties under the namespace `otel.javaagent.testing`
 
 This means that:
 
-* Changes to configuration properties (other than those that contain the word `experimental`
+- Changes to configuration properties (other than those that contain the word `experimental`
   or are under the namespace `otel.javaagent.testing`) will be considered breaking changes
   (unless they only affect telemetry produced by instrumentation)
 
@@ -39,24 +39,24 @@ where versioning stability is important.
 Bumping the minimum supported library version for library instrumentation is generally acceptable
 if there's a good reason because:
 
-* Users of library instrumentation have to integrate the library instrumentation during build-time
+- Users of library instrumentation have to integrate the library instrumentation during build-time
   of their application, and so have the option to bump the library version if they are using an
   unsupported library version.
-* Users have the option of staying with the old version of library instrumentation, without being
+- Users have the option of staying with the old version of library instrumentation, without being
   pinned on an old version of the OpenTelemetry API and SDK.
-* Bumping the minimum library version changes the artifact name, so it is not technically a breaking
+- Bumping the minimum library version changes the artifact name, so it is not technically a breaking
   change.
 
 ### Javaagent instrumentation
 
 The situation is much trickier for javaagent instrumentation:
 
-* A common use case of the javaagent is applying instrumentation at deployment-time (including
+- A common use case of the javaagent is applying instrumentation at deployment-time (including
   to third-party applications), where bumping the library version is frequently not an option.
-* While users have the option of staying with the old version of javaagent, that pins them on
+- While users have the option of staying with the old version of javaagent, that pins them on
   an old version of the OpenTelemetry API and SDK, which is problematic for the OpenTelemetry
   ecosystem.
-* While bumping the minimum library version changes the instrumentation module name, it does not
+- While bumping the minimum library version changes the instrumentation module name, it does not
   change the "aggregated" javaagent artifact name which most users depend on, so could be considered
   a breaking change for some users (though this is not a breaking change that we currently make any
   guarantees about).
@@ -68,8 +68,8 @@ When there is functionality in a new library version that requires changes to th
 instrumentation which are incompatible with the current javaagent base library version, some options
 that do not require bumping the minimum supported library version include:
 
-* Access the new functionality via reflection. This is a good technique only for very small changes.
-* Create a new javaagent instrumentation module to support the new library version. This requires
+- Access the new functionality via reflection. This is a good technique only for very small changes.
+- Create a new javaagent instrumentation module to support the new library version. This requires
   configuring non-overlapping versions in the muzzle check and applying `assertInverse` to confirm
   that the two instrumentations are never be applied to the same library version (see
   [class loader matchers](https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/contributing/writing-instrumentation-module.md#restrict-the-criteria-for-applying-the-instrumentation-by-extending-the-classloadermatcher-method)