Replace GitInfo with Steeltoe's git.properties package

docs/docs/v2/tracing/index.md

@@ -92,7 +92,7 @@ Once that is done, then whenever your application issues any log statements, the
 
 When working with distributed tracing systems you will find that a trace context (for example, trace state information) must get propagated to all child processes to ensure that child spans originating from a root trace get collected and correlated into a single trace in the end.  The current trace and span IDs are just one piece of the required information that must get propagated.
 
-Steeltoe distributed tracing handles this for you by default when using the .NET HttpClient. When a downstream HTTP call is made, the current trace context is encoded as request headers and sent along with the request automatically.  Currently, Steeltoe encodes the context using [Zipkin B3 Propagation](https://github.com/openzipkin/b3-propagation) encodings. As a result, you will find that Steeltoe tracing is interoperable with several other instrumentation libraries such as [Spring Cloud Sleuth](https://cloud.spring.io/spring-cloud-sleuth/2.0.x/single/spring-cloud-sleuth.html).
+Steeltoe distributed tracing handles this for you by default when using the .NET HttpClient. When a downstream HTTP call is made, the current trace context is encoded as request headers and sent along with the request automatically.  Currently, Steeltoe encodes the context using [Zipkin B3 Propagation](https://github.com/openzipkin/b3-propagation) encodings. As a result, you will find that Steeltoe tracing is interoperable with several other instrumentation libraries such as [Spring Cloud Sleuth](https://enterprise.spring.io/projects/spring-cloud-sleuth/).
 
 ### Add Distributed Tracing
 

docs/docs/v3/stream/index.md

@@ -10,7 +10,7 @@ With Steeltoe Stream, developers can:
 * Decouple application responsibilities with event-centric thinking. An event can represent something that has happened in time, to which the downstream consumer applications can react without knowing where it originated or the producer's identity.
 * Port business logic onto messaging systems (such as RabbitMQ, etc).
 * Rely on the framework's automatic content-type support for common use-cases and yet is extendable to different data conversion types as needed.
-* Develop Stream components in .NET which can be deployed on [Spring Cloud Data Flow](https://spring.io/projects/spring-cloud-dataflow/).
+* Develop Stream components in .NET which can be deployed on [Spring Cloud Data Flow](https://enterprise.spring.io/projects/spring-cloud-dataflow/).
 
 For more reading about Steeltoe Stream:
 

docs/docs/v3/stream/stream-reference.md

@@ -1682,7 +1682,7 @@ When scaling up Stream applications horizontally, each instance can receive info
 Stream does this through the configuration setting `spring:cloud:stream:instanceCount` and `spring:cloud:stream:instanceIndex` settings.
 For example, if there are three instances of a "HDFS sink component", all three instances have `spring:cloud:stream:instanceCount` set to `3`, and the individual instances have `spring:cloud:stream:instanceIndex` set to `0`, `1`, and `2`, respectively.
 
-When Steeltoe Stream components are deployed through [Spring Cloud Data Flow](https://spring.io/projects/spring-cloud-dataflow/), these settings are configured automatically; when you launch the Stream components independently, these settings must be set correctly.
+When Steeltoe Stream components are deployed through [Spring Cloud Data Flow](https://enterprise.spring.io/projects/spring-cloud-dataflow/), these settings are configured automatically; when you launch the Stream components independently, these settings must be set correctly.
 By default, `spring:cloud:stream:instanceCount` is `1`, and `spring:cloud:stream:instanceIndex` is `0`.
 
 In a scaled-up scenario, correct configuration of these two settings is important for proper partitioning behavior (see below), and the two settings are always required by certain binders in order to ensure that data are split correctly across multiple consumer instances.
@@ -1775,4 +1775,4 @@ The binder allocates the partitions.
 This might be useful if you want messages for a particular partition to always go to the same instance.
 When a binder configuration requires them, it is important to set both values correctly in order to ensure that all of the data is consumed and that the application instances receive mutually exclusive datasets.
 
-While a scenario in which using multiple instances for partitioned data processing may be complex to set up in a standalone case, [Spring Cloud Data flow](https://spring.io/projects/spring-cloud-dataflow/) can simplify the process significantly by populating both the input and output values correctly and by letting you rely on the runtime infrastructure to provide information about the instance index and instance count.
+While a scenario in which using multiple instances for partitioned data processing may be complex to set up in a standalone case, [Spring Cloud Data flow](https://enterprise.spring.io/projects/spring-cloud-dataflow/) can simplify the process significantly by populating both the input and output values correctly and by letting you rely on the runtime infrastructure to provide information about the instance index and instance count.

docs/docs/v3/tracing/index.md

@@ -88,7 +88,7 @@ Steeltoe makes this easy by automatically configuring some of the instrumentatio
 * TracingCore builds on top of TracingBase, also configuring [instrumentation on inbound requests through ASP.NET Core and Grpc.AspNetCore](https://github.com/open-telemetry/opentelemetry-dotnet-contrib/blob/main/src/OpenTelemetry.Instrumentation.AspNetCore/README.md)
 * Additional instrumentation libraries can be added with the [`Action<TracerProviderBuilder>` parameter](#adding-to-tracerproviderbuilder)
 
- Steeltoe currently uses [Zipkin B3 Propagation](https://github.com/openzipkin/b3-propagation) by default, but can be configured to use [W3C trace context](https://www.w3.org/TR/trace-context/). As a result, you will find that Steeltoe tracing is interoperable with several other instrumentation libraries, such as [Spring Cloud Sleuth](https://spring.io/projects/spring-cloud-sleuth/).
+ Steeltoe currently uses [Zipkin B3 Propagation](https://github.com/openzipkin/b3-propagation) by default, but can be configured to use [W3C trace context](https://www.w3.org/TR/trace-context/). As a result, you will find that Steeltoe tracing is interoperable with several other instrumentation libraries, such as [Spring Cloud Sleuth]((https://enterprise.spring.io/projects/spring-cloud-sleuth/).
 
 ### Add Distributed Tracing
 

docs/docs/v4/management/info.md

@@ -70,9 +70,7 @@ This contributor exposes any values below the `Info` configuration key. For exam
 ### Git properties
 
 This contributor exposes information from the `git.properties` Spring Boot file, if available. The file contains information from git, such as branch/tag name, commit hash, and remote.
-
-> [!TIP]
-> For an example of how to use this contributor within MSBuild using [GitInfo](https://github.com/devlooped/GitInfo), see the [Steeltoe Management sample](https://github.com/SteeltoeOSS/Samples/tree/4.x/Management/src).
+See https://www.nuget.org/packages/Steeltoe.Management.GitProperties.Build for how to configure your project to ensure the file is generated.
 
 ### Runtime info
 

docs/docs/v4/tracing/index.md

@@ -25,7 +25,7 @@ Log correlation refers to the process of taking log entries from disparate syste
 The process is easier when important pieces of data are logged in the same format across different systems (such as .NET and Java apps communicating with each other).
 
 Steeltoe provides the class `TracingLogProcessor`, which is an `IDynamicMessageProcessor` for correlating logs. The processor is built for use with a [Steeltoe Dynamic Logging provider](../logging/index.md).
-It enriches log entries with correlation data using the same trace format popularized by [Spring Cloud Sleuth](https://cloud.spring.io/spring-cloud-sleuth/reference/html/#log-correlation),
+It enriches log entries with correlation data using the same trace format popularized by [Spring Cloud Sleuth](https://docs.spring.io/spring-cloud-sleuth/docs/2.2.x/reference/html/#log-correlation),
 that include `[<ApplicationName>,<TraceId>,<SpanId>,<ParentSpanId>,<IsAllDataRequested>]`.
 
 Consider this pair of log entries from the [Steeltoe Management sample applications](https://github.com/SteeltoeOSS/Samples/tree/4.x/Management/src/):

docs/docs/v4/welcome/whats-new.md

@@ -320,7 +320,7 @@ For more information, see the updated [Bootstrap documentation](../bootstrap/ind
 - New configuration provider to decrypt settings in Config Server (should be added as late as possible)
 - Reduced noise in Config Server logging
 - Universal configuration of client certificates, using ASP.NET Options pattern (named, with fallback to default)
-- Added support for reading from [Application Configuration Service for VMware Tanzu](https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/application-configuration-service-for-tanzu/2-4/app-config-service/overview.html) on Kubernetes
+- Added support for reading from [Application Configuration Service for VMware Tanzu](https://techdocs.broadcom.com/us/en/vmware-tanzu/standalone-components/tanzu-application-platform/1-12/tap/application-configuration-service-about.html) on Kubernetes
 - Improved support for ASP.NET Options pattern, responding to configuration changes at runtime
 - Removed configuration provider that directly interacts with the Kubernetes API
 

lychee.toml

@@ -3,7 +3,7 @@
 cache = true
 scheme = ["http", "https"]
 require_https = true
-include_fragments = true
+include_fragments = "full"
 retry_wait_time = 5
 root_dir = "."
 host_concurrency = 5