Merge branch 'main' into feat/improve-grpc-testservice-pb

.github/workflows/README.md

@@ -12,6 +12,11 @@ The whole process should look like:
 
 `Checkout` -> `Lint` -> `Test` -> `Coverage` -> `Benchmark` -> `Release`
 
+There are some other stages that run for every push on the main branches:
+
+* [Snapshoty](./snapshoty.yml)
+* [Microbenchmark](./microbenchmark.yml)
+
 ### Scenarios
 
 * Matrix compatibility runs on branches, tags and PRs basis.
@@ -41,7 +46,6 @@ Every time there is a merge to main or any release branches the whole workflow w
 
 This process has been fully automated and it gets triggered when a tag release has been created, Continuous Deployment based, aka no input approval required.
 
-
 ### OpenTelemetry
 
 There is a GitHub workflow in charge to populate what the workflow run in terms of jobs and steps. Those details can be seen in [here](https://ela.st/oblt-ci-cd-stats) (**NOTE**: only available for Elasticians).

.github/workflows/ci-docs.yml

@@ -0,0 +1,26 @@
+# This workflow sets the test / all status check to success in case it's a docs only PR and test.yml is not triggered
+# https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/troubleshooting-required-status-checks#handling-skipped-but-required-checks
+name: ci # The name must be the same as in ci.yml
+
+on:
+  pull_request:
+    paths-ignore: # This expression needs to match the paths ignored on ci.yml.
+      - '**'
+      - '!**/*.md'
+      - '!**/*.asciidoc'
+
+permissions:
+  contents: read
+
+## Concurrency only allowed in the main branch.
+## So old builds running for old commits within the same Pull Request are cancelled
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}
+
+jobs:
+  # dummy steps that allow to bypass those mandatory checks for tests
+  ci:
+    runs-on: ubuntu-latest
+    steps:
+      - run: 'echo "Not required for docs"'

.github/workflows/ci.yml

@@ -17,6 +17,12 @@ on:
 permissions:
   contents: read
 
+## Concurrency only allowed in the main branch.
+## So old builds running for old commits within the same Pull Request are cancelled
+concurrency:
+  group: ${{ github.workflow }}-${{ github.ref }}
+  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}
+
 jobs:
   precheck:
     runs-on: ubuntu-latest
@@ -101,3 +107,21 @@ jobs:
           cache-dependency-path: '**/go.sum'
       - name: Unit tests
         run: make test
+
+  # Very last job to create a GitHub check with the status. This is handy to centralise the
+  # GitHub check validation in the Branch protection and to support the ci-docs.yml
+  ci:
+    if: always()
+    runs-on: ubuntu-latest
+    needs:
+      - check-update-modules
+      - precheck
+      - test
+      - test-macos
+      - test-windows
+    steps:
+      - id: check
+        uses: elastic/apm-pipeline-library/.github/actions/check-dependent-jobs@current
+        with:
+          needs: ${{ toJSON(needs) }}
+      - run: ${{ steps.check.outputs.isSuccess }}

docs/logs.asciidoc

@@ -6,14 +6,15 @@ The agent will automaticaly inject correlation IDs that allow navigation between
 
 This features is part of {observability-guide}/application-logs.html[Application log ingestion strategies].
 
-The {ecs-logging-go-ref}/intro.html[`ecs-logging-go`] library can also be used to use the {ecs-logging-ref}/intro.html[ECS logging] format without an APM agent.
+The {ecs-logging-go-logrus-ref}/intro.html[`ecslogrus`] and {ecs-logging-go-zap-ref}/intro.html[`ecszap`] libraries can also be used to use the {ecs-logging-ref}/intro.html[ECS logging] format without an APM agent.
 When deployed with the Go APM agent, the agent will provide <<log-correlation-ids,log correlation>> IDs.
 
 The Go agent provides integrations for popular logging frameworks that
 inject trace ID fields into the application's log records. You can find a list of
 the supported logging frameworks under <<supported-tech-logging, supported technologies>>.
 
 If your favorite logging framework is not already supported, there are two other options:
+
 * Open a feature request, or contribute code, for additional support as described in <<contributing>>.
 * Manually inject trace IDs into log records, as described below in <<log-correlation-manual>>.