Merge remote-tracking branch 'upstream/main' into control-protocol-ch…

…unking

.buildkite/pipeline.yml

@@ -243,15 +243,6 @@ steps:
       manual:
         allowed: true
 
-  - wait: ~
-    continue_on_failure: true
-  - label: "Processing test results"
-    agents:
-      provider: "gcp"
-    plugins:
-      - junit-annotate#v2.4.1:
-          artifacts: build/TEST-go-integration*.xml
-
   # Triggers a dynamic step: Sync K8s
   # Runs only on main and if k8s files are changed
   - label: "Trigger k8s sync"

.buildkite/scripts/steps/beats_tests.sh

@@ -12,14 +12,19 @@ source .buildkite/scripts/common.sh
 STACK_PROVISIONER="${1:-"serverless"}"
 
 run_test_for_beat(){
+    export GOFLAGS='-buildvcs=false'
     local beat_name=$1
 
     #build
-    export WORKSPACE="build/beats/x-pack/${beat_name}"
+    export WORKSPACE="/tmp/beats-build/beats/x-pack/${beat_name}"
+    pushd $WORKSPACE
+    whoami
+    ls -la
     SNAPSHOT=true PLATFORMS=linux/amd64 PACKAGES=tar.gz,zip mage package
+    popd
 
     #run
-    export AGENT_BUILD_DIR="build/beats/x-pack/${beat_name}/build/distributions"
+    export AGENT_BUILD_DIR="/tmp/beats-build/beats/x-pack/${beat_name}/build/distributions"
     export WORKSPACE=$(pwd)
 
     set +e
@@ -33,11 +38,13 @@ run_test_for_beat(){
 #the setup scripts will do a few things that assume we're running out of elastic-agent and will break things for beats, so run before we do actual setup
 mage -l
 
-mkdir -p build
-cd build
+# mkdir -p build
+# cd build
+mkdir -p /tmp/beats-build
+pushd /tmp/beats-build
 
-git clone --filter=tree:0 git@github.com:elastic/beats.git
-cd ..
+git clone git@github.com:elastic/beats.git
+popd
 
 # export WORKSPACE=beats/x-pack/metricbeat
 

.github/dependabot.yml

@@ -15,3 +15,25 @@ updates:
     reviewers:
       - "elastic/elastic-agent-control-plane"
     open-pull-requests-limit: 10
+  - package-ecosystem: "gomod"
+    directory: "/"
+    schedule:
+      interval: "daily"
+    labels:
+      - automation
+      - skip-changelog
+      - Team:Elastic-Agent
+    groups:
+        otel-dependencies:
+            patterns:
+             - "*"
+            update-types:
+             - "minor"
+             - "patch"
+    allow:
+      # Only update internal dependencies for now while we evaluate this workflow.
+      - dependency-name: "go.opentelemetry.io/collector/*"
+      - dependency-name: "github.com/open-telemetry/opentelemetry-collector-contrib/*"
+    reviewers:
+      - "elastic/elastic-agent-control-plane"
+    open-pull-requests-limit: 10

.github/workflows/golangci-lint.yml

@@ -28,7 +28,7 @@ jobs:
         uses: golangci/golangci-lint-action@v3
         with:
           # Optional: version of golangci-lint to use in form of v1.2 or v1.2.3 or `latest` to use the latest version
-          version: v1.51.2
+          version: v1.55.2
 
           # Give the job more time to execute.
           # Regarding `--whole-files`, the linter is supposed to support linting of changed a patch only but,

.go-version

@@ -1 +1 @@
-1.20.11
+1.21.5

.golangci.yml

@@ -116,7 +116,7 @@ linters-settings:
 
   gosimple:
     # Select the Go version to target. The default is '1.13'.
-    go: "1.20.11"
+    go: "1.21.5"
 
   nakedret:
     # make an issue if func has more lines of code than this setting and it has naked returns; default is 30
@@ -136,17 +136,17 @@ linters-settings:
 
   staticcheck:
     # Select the Go version to target. The default is '1.13'.
-    go: "1.20.11"
+    go: "1.21.5"
     checks: ["all"]
 
   stylecheck:
     # Select the Go version to target. The default is '1.13'.
-    go: "1.20.11"
+    go: "1.21.5"
     checks: ["all"]
 
   unused:
     # Select the Go version to target. The default is '1.13'.
-    go: "1.20.11"
+    go: "1.21.5"
 
   gosec:
     excludes:

CONTRIBUTING.md

@@ -1,17 +1,61 @@
-Please post all questions and issues first on
-[https://discuss.elastic.co/c/beats](https://discuss.elastic.co/c/beats)
-before opening a Github Issue.
+# Contributing to Elastic Agent
 
-# Contributing to Beats
+## Got Questions?
 
-The Beats are open source and we love to receive contributions from our
-community — you!
+Have a problem you want Elastic Agent to solve for you?
 
-There are many ways to contribute, from writing tutorials or blog posts,
-improving the documentation, submitting bug reports and feature requests or
-writing code for implementing a whole new protocol.
+* You can ask a question in the [forum](https://discuss.elastic.co/c/elastic-stack/elastic-agent).
+* You are welcome to join Elastic Stack Community slack (https://elasticstack.slack.com) and ask for help on the #elastic-agent channel.
+
+## Have an Idea or Feature Request?
+
+* File an issue on [GitHub](https://github.com/elastic/elastic-agent/issues). Please remember that GitHub is used only for bugs and feature requests. If you have a general question, the [forum](https://discuss.elastic.co/c/elastic-stack/elastic-agent) or Elastic Stack Community slack (https://elasticstack.slack.com) is the best place to ask.
+
+## Something Not Working? Found a Bug?
+
+If you think you found a bug, it probably is a bug. Fill it in [GitHub](https://github.com/elastic/elastic-agent/issues)
+
+## Found a Security Issue?
+
+If you've found a security issue, before submitting anything via a PR, please
+get in touch with our security team [here](https://www.elastic.co/community/security).
+
+# Pull Request Guidelines
+
+The following exists as a way to set expectations for yourself and for the review process. We *want* to merge fixes and features, so let's describe how we can achieve this:
+
+## Goals
+
+* To constantly make forward progress on PRs
+
+* To have constructive discussions on PRs
+
+## Overarching Guiding Principles
+
+Keep these in mind as both authors and reviewers of PRs:
+
+* Have empathy in both directions (reviewer <--> reviewee/author)
+* Progress over perfection and personal preferences
+* Authors and reviewers should proactively address questions of pacing in order to reach an acceptable balance between meeting the author's expected timeline for merging the PR and the reviewer's ability to keep up with revisions to the PR.
+
+## As a reviewee (i.e. author) of a PR:
+
+* I must put up atomic PRs. This helps the reviewer of the PR do a high quality review fast. "Atomic" here means two things:
+  - The PR must contain related changes and leave out unrelated changes (e.g. refactorings, etc. that could be their own PR instead).
+  - If the PR could be broken up into two or more PRs either "vertically" (by separating concerns logically) or horizontally (by sharding the PR into a series of PRs --- usually works well with mass refactoring or cleanup type PRs), it should. A set of such related PRs can be tracked and given context in a meta issue.
+
+* I must strive to please the reviewer(s). In other words, bias towards taking the reviewers suggestions rather than getting into a protracted argument. This helps move the PR forward. A convenient "escape hatch" to use might be to file a new issue for a follow up discussion/PR. If you find yourself getting into a drawn out argument, ask yourself: is this a good use of our time?
+
+## As a reviewer of a PR:
+
+* I must first focus on whether the PR works functionally -- i.e. does it solve the problem (bug, feature, etc.) it sets out to solve.
+
+* Then I should ask myself: can I understand what the code in this PR is doing and, more importantly, why it's doing whatever it's doing, within 1 or 2 passes over the PR?
+
+  * If yes, approve the PR!
+
+  * If no, ask for clarifications on the PR. This will usually lead to changes in the code such as renaming of variables/functions or extracting of functions or simply adding "why" inline comments. But first ask the author for clarifications before assuming any intent on their part.
+
+* I must not focus on personal preferences or nitpicks. If I understand the code in the PR but simply would've implemented the same solution a different way that's great but it is not feedback that belongs in the PR. Such feedback only serves to slow down progress for little to no gain.
 
-If you want to contribute to the Beats project, you can start by reading
-the [contributing guidelines](https://www.elastic.co/guide/en/beats/devguide/current/beats-contributing.html)
-in the _Beats Developer Guide_.
 

Dockerfile

@@ -1,4 +1,4 @@
-ARG GO_VERSION=1.20.11
+ARG GO_VERSION=1.21.5
 FROM circleci/golang:${GO_VERSION}
 
 

Dockerfile.skaffold

@@ -1,4 +1,4 @@
-ARG GO_VERSION=1.20.11
+ARG GO_VERSION=1.21.5
 ARG crossbuild_image="docker.elastic.co/beats-dev/golang-crossbuild"
 ARG AGENT_VERSION=8.9.0-SNAPSHOT
 ARG AGENT_IMAGE="docker.elastic.co/beats/elastic-agent"