[9.1][Automation] Update versions

[github-actions]

These files are used for picking the starting (pre-upgrade) or ending (post-upgrade) agent versions in upgrade 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.1.0

{
  "UpgradeToVersion": "9.1.0",
  "CurrentMajors": 1,
  "PreviousMajors": 1,
  "PreviousMinors": 2,
  "SnapshotBranches": [
    "9.1",
    "9.0",
    "8.19",
    "7.17"
  ]
}

[elasticmachine]

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

[elasticmachine]

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

[ycombinator]

CI is failing on this PR like so:

=== FAIL: testing/integration/ess TestUpgradeIntegrationsServer/8.19.0_to_9.1.1-SNAPSHOT (0.86s)
--
  | upgrade_integrations_server_test.go:66: Creating ECH deployment with version [8.19.0] in region [gcp-us-west2]
  | upgrade_integrations_server_test.go:73:
  | Error Trace:	/opt/buildkite-agent/builds/bk-agent-prod-aws-1754391697668155448/elastic/elastic-agent/testing/integration/ess/upgrade_integrations_server_test.go:73
  | Error:      	Received unexpected error:
  | failed to create ESS cloud for version 8.19.0: failed to create: (clusters.cluster_invalid_plan) Version [8.19.0] is not available. Please use one of the available versions
  | Test:       	TestUpgradeIntegrationsServer/8.19.0_to_9.1.1-SNAPSHOT
  | --- FAIL: TestUpgradeIntegrationsServer/8.19.0_to_9.1.1-SNAPSHOT (0.86s)

I checked cloud.elastic.co and 8.19.0 is no longer available as a version in the CFT environment. It appears it was still available as of a week ago, when this test passed on the a similar PR.

We may need to update where the test is sourcing this version from to ensure the version is actually available in the ESS Production CFT environment.

[ycombinator]

We may need to update where the test is sourcing this version from to ensure the version is actually available in the ESS Production CFT environment.

Currently, this test is sourcing the list of versions (to start the upgrade from) from upgradetest.GetUpgradableVersions(), which itself sources them from the testing/integration/testdata/.upgrade-test-agent-versions.yml. As we can see in this PR, that file now includes 8.19.0. However, this version is not available in the ESS region this test is running against (today that's the Production CFT region; in the near future it will be the Staging GovCloud region).

I'm wondering if we should source the list of versions for this test from this ESS API instead: https://cloud.elastic.co/api/v1/regions/gcp-us-central1/stack/versions?show_deleted=false&show_unusable=false (note that the domain name and region path parameter will need to be adjusted). Thoughts @pkoutsovasilis @pchila?

[pkoutsovasilis]

Hey @ycombinator 👋 thanks for chiming in!

Off the top of my head, I’m thinking along these lines: having these tests triggered in the Update versions PR feels right, but given what you’ve outlined, it’s a bit more complicated.

How about we keep using testing/integration/testdata/.upgrade-test-agent-versions.yml as the source of truth for which versions to test, but filter them dynamically against the list of versions reported by the ESS API?

• If a version exists in our YAML but is no longer available in the ESS region we’re testing against, we simply skip the test with a clear message.
• This way, we continue to test the relevant versions per branch, but avoid hard failures when a version disappears from the environment.
• Down the line, we could update the logic to query Staging GovCloud instead, once that becomes the primary region for these tests.

WDYT? This seems like a reasonable middle ground without losing coverage on the versions that are actually deployable.

[ycombinator]

How about we keep using testing/integration/testdata/.upgrade-test-agent-versions.yml as the source of truth for which versions to test, but filter them dynamically against the list of versions reported by the ESS API?

Yep, this is exactly what I was thinking too. Will make the necessary changes, thanks!

[ycombinator]

How about we keep using testing/integration/testdata/.upgrade-test-agent-versions.yml as the source of truth for which versions to test, but filter them dynamically against the list of versions reported by the ESS API?

Yep, this is exactly what I was thinking too. Will make the necessary changes, thanks!

Put up a separate PR for this change so we can keep this PR here clean, i.e. only for updating the versions file. Will test the new PR with the testing/integration/testdata/.upgrade-test-agent-versions.yml file changes from the PR here to make sure the new logic works as expected. Once that PR is merged, I will rebase this PR here on main and hopefully it will pass CI after that.

[ycombinator]

How about we keep using testing/integration/testdata/.upgrade-test-agent-versions.yml as the source of truth for which versions to test, but filter them dynamically against the list of versions reported by the ESS API?

PR with this change is now in review: #9266.

[ycombinator]

How about we keep using testing/integration/testdata/.upgrade-test-agent-versions.yml as the source of truth for which versions to test, but filter them dynamically against the list of versions reported by the ESS API?

PR with this change is now in review: #9266.

PR has been merged and backported to 9.1 and 8.19 branches. Going to rebase this PR here on 9.1 to see if it passes CI now.

[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

[elasticmachine]

💛 Build succeeded, but was flaky

• Buildkite Build
• Commit: 5b939e3

Failed CI Steps

• arm:sudo: fleet
• x86_64:sudo: fleet

History

• 💔 Build #24637 failed f752dde