[updatecli] update elastic stack version for testing 9.0.0-e70a10ac-SNAPSHOT

[github-actions]

Bump elastic-stack to latest snapshot version

Update snapshot.yml

1 file(s) updated with "$1=9.0.0-e70a10ac-SNAPSHOT": * dev-tools/integration/.env

GitHub Action workflow link

---

Created automatically by Updatecli Options: Most of Updatecli configuration is done via its manifest(s). If you close this pull request, Updatecli will automatically reopen it, the next time it runs. If you close this pull request and delete the base branch, Updatecli will automatically recreate it, erasing all previous commits made. Feel free to report any issues at github.com/updatecli/updatecli. If you find this tool useful, do not hesitate to star our GitHub repository as a sign of appreciation, and/or to tell us directly on our chat!

[mergify]

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

[michel-laterman]

@jlind23 this pr updates the 8.16.x snapshot on main; it's going to fail until we have 9.x images for main.
Also do we need to do anything to activate similar prs for the 8.x branch?

[ycombinator]

do we need to do anything to activate similar prs for the 8.x branch?

I suspect this has something to do with

fleet-server/.github/workflows/bump-elastic-stack-snapshot.yml

Line 20 in 7d9a469

uses: elastic/oblt-actions/elastic/active-branches@v1

At the moment this step appears to be generating ["7.17", "8.15", "main"] as its output (example).

@v1v might be able to help figure out why 8.x is not being included in the list.

[v1v]

@v1v might be able to help figure out why 8.x is not being included in the list.

Because the first snapshot in the Unified Release was not published when the GitHub workflow ran.

Those files are generated and use https://artifacts-api.elastic.co/v1/versions as the source of truth. It will not be shown if that entrypoint does not contain those details.

That's not the case anymore since https://storage.googleapis.com/artifacts-api/snapshots/branches.json now contains the new branch.

and I triggered this GH workflow and now things are back to normal

#3905 is the one targeting 8.x

[ycombinator]

buildkite test this

[jlind23]

buildkite test this

[michel-laterman]

The current error is Error response from daemon: manifest for docker.elastic.co/elasticsearch/elasticsearch:9.0.0-d56464e5-SNAPSHOT-amd64 not found: manifest unknown: manifest unknown

I can recreate this failure locally; but it works if I remove the amd64 suffix (which is also done in #3904)

[v1v]

The current error is Error response from daemon: manifest for docker.elastic.co/elasticsearch/elasticsearch:9.0.0-d56464e5-SNAPSHOT-amd64 not found: manifest unknown: manifest unknown

That's something to be reported to the Release team,

$ curl -s https://artifacts-api.elastic.co/v1/versions/8.15.1-SNAPSHOT/builds/latest | jq .build.build_id
"8.15.1-67a5416d"
$ docker pull docker.elastic.co/elasticsearch/elasticsearch:8.15.1-67a5416d-SNAPSHOT-amd64
...
$ curl -s https://artifacts-api.elastic.co/v1/versions/8.16-SNAPSHOT/builds/latest | jq .build.build_id
"8.16.0-874a7f05"

$ docker pull docker.elastic.co/elasticsearch/elasticsearch:8.16.0-874a7f05-SNAPSHOT-amd64 
Error response from daemon: manifest for docker.elastic.co/elasticsearch/elasticsearch:8.16.0-874a7f05-SNAPSHOT-amd64 not found: manifest unknown: manifest unknown

$ curl -s https://artifacts-api.elastic.co/v1/versions/8.15-SNAPSHOT/builds/latest | jq .build.build_id
"8.15.2-7f2cd899"

$ docker pull docker.elastic.co/elasticsearch/elasticsearch:8.15.2-7f2cd899-SNAPSHOT-amd64
Error response from daemon: manifest for docker.elastic.co/elasticsearch/elasticsearch:8.15.2-7f2cd899-SNAPSHOT-amd64 not found: manifest unknown: manifest unknown

for some reason 8.x, main, 8.15 are not producing those docker images anymore.

While 8.15.1 is the latest version with support for -amd64

[jlind23]

@v1v the double dots in your command looks weird to me:
8..16

[jlind23]

Maybe @rdner would know why we are not producing those 🤷🏼

[v1v]

@v1v the double dots in your command looks weird to me:

A typo in my end, i reviewed those commands and updated the comment with the output.

Maybe @rdner would know why we are not producing those 🤷🏼

Those are docker images related to elasticsearch

BTW, I asked in the internal slack channel about this behaviour and you are in the loop, in case it helps

[jlind23]

Those are docker images related to elasticsearch

🤦🏼 sorry missed it.

[michel-laterman]

buildkite test this

[michel-laterman]

cloud e2e tests are failing:

╷
--
  | │ Error: failed creating deployment
  | │
  | │   with ec_deployment.deployment,
  | │   on main.tf line 46, in resource "ec_deployment" "deployment":
  | │   46: resource "ec_deployment" "deployment" {
  | │
  | │ api error: 1 error occurred:
  | │ 	* deployments.identity.invalid_acs: Failed to calculate ACS for [kibana] resource [8ee3719c35104aac97a823ec1ebc0bd1]
  | │
  | │
  | ╵
  | ╷
  | │ Error: failed creating deployment
  | │
  | │   with ec_deployment.deployment,
  | │   on main.tf line 46, in resource "ec_deployment" "deployment":
  | │   46: resource "ec_deployment" "deployment" {
  | │
  | │ set "request_id" to "oe500xbo896pai5r7b7mfk2q385zx0bwnqk0sqh7jl7w6ylyay4uydmfp900cge9" to recreate the deployment resources
  | ╵

[michel-laterman]

buildkite test this

[michel-laterman]

buildkite test this

[michel-laterman]

buildkite test this

[michel-laterman]

Tracked with #3920

[michel-laterman]

buildkite test this

[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