[main][Automation] Update versions

[github-actions]

These files are used for picking agent versions in integration tests.

The content is based on responses from https://www.elastic.co/api/product_versions and https://snapshots.elastic.co

The current update is generated based on the following requirements:

Package version: 9.0.0

{
  "UpgradeToVersion": "9.0.0",
  "CurrentMajors": 1,
  "PreviousMajors": 1,
  "PreviousMinors": 2,
  "SnapshotBranches": [
    "8.x",
    "8.15",
    "7.17"
  ]
}

[elasticmachine]

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

[elasticmachine]

Pinging @elastic/elastic-agent (Team:Elastic-Agent)

[rdner]

Looks like now we have the 9.0 snapshot available but there are multiple unrelated failures:

• On serverless Fleet Server produces the Error: fail to enroll: fail to execute request to fleet-server: status code: 400, fleet-server returned an error: UnsupportedVersion, message: version is not supported error
• The agent integration tests are failing because there is no previous minor version. What should we do in such case? I don't expect the upgrade from 8.16 to 9.0 fully working, so does it make sense to test it?
• failed to create ESS cloud for version 9.0.0-SNAPSHOT: failed to create: (deployments.identity.invalid_acs) Failed to calculate ACS for [kibana] – the cloud team is already working on this issue

cc @ycombinator

[ycombinator]

The agent integration tests are failing because there is no previous minor version. What should we do in such case?

Looking at how the PreviousMinor() function works, it loops over the versions from the .agent-versions file to determine the previous minor for the Agent version under test (define.Version()). Perhaps we can add a special case to this function that if the version under test is the first minor of a major, it should use the latest/highest version from the .agent-versions list? So currently, that would mean PreviousMinor() would return 8.16.0-SNAPSHOT. Eventually, this will return the final version in 8.x series, which is an upgrade path that should work and therefore should be tested.

I don't expect the upgrade from 8.16 to 9.0 fully working, so does it make sense to test it?

I think we should test this path, at least for now. Once specific tests start failing, say for a starting version X of Agent, we can revisit what to do — whether to skip those specific tests if the starting Agent version is >= X or whether to skip all upgrade tests entirely if the starting Agent version is >= X.

Thoughts?

[rdner]

@ycombinator yes, this is why I wrote:

I don't expect the upgrade from 8.16 to 9.0 fully working, so does it make sense to test it?

in my original message.

We can indeed use the previous 8.x as a previous minor but would it be fare to test 9.0 against 8.x in this case?

[ycombinator]

@rdner Sorry, the formatting in my last comment (#5552 (comment)) got messed up but I tried to answer your question there.

[elastic-sonarqube]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarQube

[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 update-agent-versions-10913235591 upstream/update-agent-versions-10913235591
git merge upstream/main
git push upstream update-agent-versions-10913235591

[ycombinator]

Due to the changes made in #5522, I'm going to close this PR unmerged and let automation re-create it.