feat: bump go to 1.23.4

[kruskall]

What does this PR do?

Update dockerfile go versions
Update documentation go version
Update go.mod
Remove go version from golangci config so it
defaults to the one used in go.mod

Why is it important?

Bump to the latest go version: https://go.dev/doc/go1.23
Also adds some nice feature that allows us to drop two more dependency (x/exp and copy)

Checklist

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have made corresponding change to the default configuration files
• I have added tests that prove my fix is effective or that my feature works
• I have added an entry in ./changelog/fragments using the changelog tool
• I have added an integration test or an E2E test

Disruptive User Impact

How to test this PR locally

Related issues

Questions to ask yourself

• How are we going to support this in production?
• How are we going to measure its adoption?
• How are we going to debug this?
• What are the metrics I should take care of?
• ...

[mergify]

This pull request does not have a backport label. Could you fix it @kruskall? 🙏
To fixup this pull request, you need to add the backport labels for the needed
branches, such as:

• backport-v./d./d./d is the label to automatically backport to the 8./d branch. /d is the digit

NOTE: backport-skip has been added to this pull request.

[elasticmachine]

Pinging @elastic/elastic-agent-control-plane (Team:Elastic-Agent-Control-Plane)

[blakerouse]

This cannot be merged or get a green CI until 1.23 is released here https://github.com/elastic/golang-crossbuild

A PR would also need to be done for github.com/elastic/beats as we want to keep the go versions in sync between Elastic Agent and beats.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b bump/go1.23 upstream/bump/go1.23
git merge upstream/main
git push upstream bump/go1.23

[ycombinator]

Thanks for this PR, @kruskall. Just wondering if there is any specific reason to create this manually, since we do have automation for Go version updates, e.g. #5305

[blakerouse]

@ycombinator Automation only bumps minors of golang, not majors. Golang 1.22 required me to do a manual PR - #5036

[v1v]

/package

[v1v]

IIUC,

elastic-agent/.buildkite/pull-requests.json

Line 28 in fd477ec

"trigger_comment_regex": "^(?:(?:buildkite\\W+)?(?:package)\\W+(?:this|it))|^/package$",

explains that /package is a valid command

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b bump/go1.23 upstream/bump/go1.23
git merge upstream/main
git push upstream bump/go1.23

[kruskall]

@v1v seems to fail with gvm: error: unknown version 1.23 for ubuntu and macOS. Any idea what's happening ?

[v1v]

@v1v seems to fail with gvm: error: unknown version 1.23 for ubuntu and macOS. Any idea what's happening ?

Unfortunately, I don't know much about this project's existing build and CI system. AFAIS, those are not related to the packaging but the build/test itself. Maybe those CI runners have been configured with some tools and gvm does not support 1.23 yet.

https://github.com/andrewkroh/gvm is the tool If I recall correctly and I cannot reproduce the error locally using macOS m2:

elastic-agent/.buildkite/scripts/common.sh

Lines 12 to 14 in f29717e

	if [[ -z "${SETUP_GVM_VERSION-""}" ]]; then
	SETUP_GVM_VERSION="v0.5.0" # https://github.com/andrewkroh/gvm/issues/44#issuecomment-1013231151
	fi

, so I guess the version needs to be bumped from v0.5.0 to v0.5.2.

Let me contribute to your PR and see if it works; otherwise, it's worth asking the @elastic/ingest-eng-prod or @elastic/elastic-agent-control-plane if they know what's happening.

[v1v]

After bumping the version in 8fa9c4b (#5309) no gvm: error: unknown version 1.23 are found:

installing golang 1.23.0 for linux/amd64
--
  | ~/builds/bk-agent-prod-gcp-1725434213542305391/elastic/elastic-agent ~/builds/bk-agent-prod-gcp-1725434213542305391/elastic/elastic-agent
  | go version go1.23.0 linux/amd64
  | ~/builds/bk-agent-prod-gcp-1725434213542305391/elastic/elastic-agent
  | ~/builds/bk-agent-prod-gcp-1725434213542305391/elastic/elastic-agent ~/builds/bk-agent-prod-gcp-1725434213542305391/elastic/elastic-agent
  | go version go1.23.0 linux/amd64

[v1v]

AFAIU, the packaging stage does not run for forked PRs even when using the /packaging command, so it is worth contacting the team so they can tell you how to test the packing on a PR before merging it.

[mergify]

backport-v8.x has been added to help with the transition to the new branch 8.x.

[mergify]

backport-v8.x has been added to help with the transition to the new branch 8.x.

[mergify]

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b bump/go1.23 upstream/bump/go1.23
git merge upstream/main
git push upstream bump/go1.23

[cmacknz]

One of the failed tests actually has the status error message:

beat/metrics State:4 Message:Failed: failed job assignment "C:\\Program Files\\Elastic\\Agent\\data\\elastic-agent-9.0.0-SNAPSHOT-18edfd\\components\\agentbeat.exe": The handle is invalid.

elastic-agent/main.go

Line 24 in 54932dc

pj, err := process.CreateJobObject()

elastic-agent/pkg/core/process/process.go

Lines 169 to 173 in 54932dc

	// Hook to JobObject on windows, noop on other platforms.
	// This ties the application processes lifespan to the agent's.
	// Fixes the orphaned beats processes left behind situation
	// after the agent process gets killed.
	if err := JobObject.Assign(cmd.Process); err != nil {

This is the Windows job hierarchy we create between the agent and sub-processes so that agent terminating also terminates the sub-processes like it does on Linux.

[ycombinator]

CI is failing on a couple of tests — TestLogIngestionFleetManaged and TestLongRunningAgentForLeaks — in the same way:

...
[=   ] Enrolling Elastic Agent with Fleet  [6s] 
[=   ] Waiting For Enroll...  [6s] {"log.level":"info","@timestamp":"2024-12-19T01:12:50.557Z","log.origin":{"function":"github.com/elastic/elastic-agent/internal/pkg/agent/cmd.(*enrollCmd).enrollWithBackoff","file.name":"cmd/enroll_cmd.go","file.line":520},"message":"Starting enrollment to URL: https://61f19a4a87634e8e8e5711e61b56d909.fleet.us-west2.gcp.elastic-cloud.com:443/","ecs.version":"1.6.0"}
        {"log.level":"info","@timestamp":"2024-12-19T01:12:52.085Z","log.origin":{"function":"github.com/elastic/elastic-agent/internal/pkg/agent/cmd.(*enrollCmd).daemonReloadWithBackoff","file.name":"cmd/enroll_cmd.go","file.line":483},"message":"Restarting agent daemon, attempt 0","ecs.version":"1.6.0"}
        {"log.level":"info","@timestamp":"2024-12-19T01:12:52.090Z","log.origin":{"function":"github.com/elastic/elastic-agent/internal/pkg/agent/cmd.(*enrollCmd).Execute","file.name":"cmd/enroll_cmd.go","file.line":301},"message":"Successfully triggered restart on running Elastic Agent.","ecs.version":"1.6.0"}
        Successfully enrolled the Elastic Agent.
[   =] Enroll Completed  [8s] 
[   =] Done  [8s] 
[   =] Done  [8s] 
        Elastic Agent has been successfully installed.
    check.go:64: Agent fleet status: updating
    check.go:64: Agent fleet status: enrolling
    check.go:64: Agent fleet status: degraded
    check.go:64: Agent fleet status: degraded
    check.go:64: Agent fleet status: degraded
    check.go:64: Agent fleet status: degraded
    check.go:64: Agent fleet status: degraded
    ...

This is happening after retrying those build steps so it doesn't look like a flaky test issue. Also, this type of failure isn't currently being observed on main but it is seen on this PR even after rebasing it on main.

@kruskall do you mind investigating what's going on? Thanks.

[kruskall]

Yup, it's the same failure since 1.23.0. I don't know what's going on :(

I'll try to look into it, if anyone has any idea please feel free to chime in

[ycombinator]

There are diagnostics captured for the TestLongRunningAgentForLeaks failure, which is run as part of the Extended runtime leak tests. These might give a clue as to why Agent is going into and staying in DEGRADED state.

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube