fix: lint

content/manuals/testcontainers/benefits.md

@@ -8,7 +8,7 @@
 - /testcontainers/benefits/
 ---
 
-### Benefits of using Testcontainers:
+### Benefits of using Testcontainers
 
 * **On-demand isolated infrastructure provisioning:**
 You don't need to have a pre-provisioned integration testing infrastructure. 
@@ -34,8 +34,8 @@
 
 * **Automatic clean up:**
 The Testcontainers library takes care of removing any created resources (containers, volumes, networks etc.) 
 automatically after the test execution is complete by using the Ryuk sidecar container. 
 While starting the required containers, Testcontainers attaches a set of labels to the 
 created resources (containers, volumes, networks etc) and Ryuk automatically performs 
 resource clean up by matching those labels. 
 This works reliably even when the test process exits abnormally (e.g. sending a SIGKILL).

content/manuals/testcontainers/getting-started/go.md

@@ -20,15 +20,15 @@
 
 From the [Go Release Policy](https://go.dev/doc/devel/release#policy):
 
 > Each major Go release is supported until there are two newer major releases. For example, Go 1.5 was supported until the Go 1.7 release, and Go 1.6 was supported until the Go 1.8 release. We fix critical problems, including critical security problems, in supported releases as needed by issuing minor revisions (for example, Go 1.6.1, Go 1.6.2, and so on).
 
 _Testcontainers for Go_ is tested against those two latest Go releases, therefore we recommend using any of them.
 
 ## Step 1:Install _Testcontainers for Go_
 
 _Testcontainers for Go_ uses [go mod](https://blog.golang.org/using-go-modules) and you can get it installed via:
 
-```
+```bash
 go get github.com/testcontainers/testcontainers-go
 ```
 
@@ -67,21 +67,21 @@
 * `Image` is the Docker image the container starts from.
 * `ExposedPorts` lists the ports to be exposed from the container.
 * `WaitingFor` is a field you can use to validate when a container is ready. It
   is important to get this set because it helps to know when the container is
   ready to receive any traffic. In this case, we check for the logs we know come
   from Redis, telling us that it is ready to accept requests.
 
 When you use `ExposedPorts` you have to imagine yourself using `docker run -p
 <port>`.  When you do so, `dockerd` maps the selected `<port>` from inside the
 container to a random one available on your host.
 
 In the previous example, we expose `6379` for `tcp` traffic to the outside. This
 allows Redis to be reachable from your code that runs outside the container, but
 it also makes parallelization possible because if you add `t.Parallel` to your
 tests, and each of them starts a Redis container each of them will be exposed on a
 different random port.
 
 `testcontainers.GenericContainer` creates the container. In this example we are
 using `Started: true`. It means that the container function will wait for the
 container to be up and running. If you set the `Start` value to `false` it won't
 start, leaving to you the decision about when to start it.
@@ -93,7 +93,7 @@
 
 > [!TIP]
 >
-> Look at [features/garbage_collector](/features/garbage_collector/) to know another
+> Look at [features/garbage_collector](https://golang.testcontainers.org/features/garbage_collector/) to know another
 > way to clean up resources.
 
 ## Step 3: Make your code talk to the container

content/manuals/testcontainers/getting-started/java.md

@@ -8,11 +8,11 @@
 weight: 20
 ---
 
 - [JUnit 4 Quickstart](#junit-4-quickstart)
 - [JUnit 5 Quickstart](#junit-5-quickstart)
 - [Spock Quickstart](#spock-quickstart)
 
 ## JUnit 4 Quickstart
 
 It's easy to add Testcontainers to your project - let's walk through a quick example to see how.
 
@@ -84,7 +84,7 @@
     .withExposedPorts(6379);
 ```
 
 The `@Rule` annotation tells JUnit to notify this field about various events in the test lifecycle.
 In this case, our rule object is a Testcontainers `GenericContainer`, configured to use a specific Redis image from Docker Hub, and configured to expose a port.
 
 If we run our test as-is, then regardless of the actual test outcome, we'll see logs showing us that Testcontainers:
@@ -97,7 +97,7 @@
 
 ### Step 3: Make sure our code can talk to the container
 
 Before Testcontainers, we might have hardcoded an address like `localhost:6379` into our tests.
 
 Testcontainers uses *randomized ports* for each container it starts, but makes it easy to obtain the actual port at runtime.
 We can do this in our test `setUp` method, to set up our component under test:
@@ -117,7 +117,7 @@
 > not work on your current or future CI environment. As such, **avoid hard-coding** the address, and use 
 > `getHost()` instead.
 
-### Step 4: Run the tests!
+### Step 4: Run the tests
 
 That's it!
 
@@ -282,7 +282,7 @@
 current environment. Set `disabledWithoutDocker` to `true`.
 * Enable parallel container initialization instead of sequential (by default). Set `parallel` to `true`.
 
-### Step 5: Run the tests!
+### Step 5: Run the tests
 
 That's it!
 
@@ -431,7 +431,7 @@
 > not work on your current or future CI environment. As such, **avoid hard-coding** the address, and use 
 > `containerIpAddress` instead.
 
-### Step 4: Run the tests!
+### Step 4: Run the tests
 
 That's it!