[automation] update elastic stack version for testing 8.3.0-1ecd9720

[apmmachine]

What

Bump stack version with the latest one.

Further details

[start_time:Thu, 31 Mar 2022 12:15:08 GMT, release_branch:master, prefix:, end_time:Fri, 1 Apr 2022 02:36:15 GMT, manifest_version:2.0.0, version:8.3.0-SNAPSHOT, branch:master, build_id:8.3.0-1ecd9720, build_duration_seconds:51667]

[botelastic]

This pull request doesn't have a Team:<team> label.

[elasticmachine]

💔 Build Failed

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-04-01T05:10:02.203+0000

• Duration: 20 min 0 sec

Test stats 🧪

Test	Results
Failed	0
Passed	3
Skipped	0
Total	3

Steps errors

Expand to view the steps failures

Error signal

• Took 0 min 0 sec . View more details here
• Description: Error 'java.io.NotSerializableException: java.util.regex.Matcher'

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

• /package : Generate the packages and run the E2E tests.

• /beats-tester : Run the installation tests with beats-tester.

• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[ruflin]

@v1v We currently have "odd" build failures on the linting stage and I'm not sure what is going on. This one failed with the packaetbeat-lint, this one with osquerybeat-lint: #31101 I wondered if you could take a look and see something obvious.

Another thing that came to mind is a recent linting change from @rdner #30896 I wonder if there is some relation here that linting takes long / too long? Just thinking out loud.

[jlind23]

/test

[v1v]

Thanks for poking, it seems some weird serialisation in some internals in the CI:

ERROR: Error 'java.io.NotSerializableException: java.util.regex.Matcher'

I thought it was already solved back in the days:

• Fix serialisation issue with java.util.regex.Matcher apm-pipeline-library#1336

But it seems it's happening again and randomly :/

Let me dig into it

[rdner]

@ruflin just FYI, the linting stage was moved from Jenkins to Github in this PR #30985 and now does not block/affect the build in the CI (Jenkins).

[ruflin]

@rdner I still see linting builds from Jenkins in the list below. Does this mean it happens twice?

[rdner]

@ruflin this linting was there before my initial change, that's something else (like Python linting, dependency check, etc):

From the Jenkins file

beats/Jenkinsfile

Line 221 in 7e22a97

cmd(label: 'make check-default', script: 'make check-default')

From the Makefile:

beats/Makefile

Lines 107 to 113 in 7e22a97

	check-default:
	@$(MAKE) check-python
	@echo "The update goal is skipped to speed up the checks in the CI on a PR basis."
	@$(MAKE) notice
	@$(MAKE) check-headers
	@$(MAKE) check-go
	@$(MAKE) check-no-changes

Also, each beat is allowed to have something custom on top of this default linting.

[ruflin]

Got it. I think we should rename the lint state to checks or similar as otherwise it is confusing.

[rdner]

@ruflin any idea why the assertion in x-pack/auditbeat-build is failing?

[v1v]

/test

[rdner]

@v1v @ruflin the x-pack/auditbeat-build failure is unrelated to the change in this PR and appeared consistently after this PR got merged #30942

I think we can merge this one ignoring this failure.

[ruflin]

@cmacknz @rdner Lets not merge red PR's even if we think it is not related. It is a slipper slope we have been on in the past. Lets ensure only green PR's go in and skip failing tests quickly and file bug reports but not merge things in.

[rdner]

@ruflin, normally I would agree but this PR blocked a lot of tests in all current builds, lots of the PRs were affected. Merging this PR was a partial fix to the failing builds. I'm still trying to find out about the x-pack/auditbeat-build failures.

[rdner]

x-pack/auditbeat-build tests were fixed in #31131