CAPZ v25.0.0 #1296

njuettner · 2024-06-27T10:05:00Z

We are using the same structure as we did for Azure Vintage, because we don't have any old installations left.

The release has been applied manually in gaggle and it has been tested. As soon as we have a new cluster-azure release (PR giantswarm/cluster-azure#305), we can start using releases.

tityosbot · 2024-06-27T10:05:03Z

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

releases_test.go

README.md

capa/archived/.gitkeep

azure/requests.yaml

capa/kustomization.yaml

.github/workflows/create-draft-release.yaml

azure/v25.0.0/release.yaml

njuettner · 2024-07-03T07:49:09Z

/run releases-test-suites

njuettner · 2024-07-03T07:51:31Z

/run releases-test-suites TARGET_SUITES=./providers/capz/standard TARGET_RELEASES=azure-25.0.0

yulianedyalkova · 2024-07-08T10:55:03Z

Do we want to have the release in azure or capz folder? For AWS we currently have aws for vintage and capa for the CAPI ones. Not sure why we decided to use a separate folder but would be nice to at least be consistent across providers.

njuettner · 2024-07-18T09:10:07Z

@yulianedyalkova from what I got we want to switch capa directory to aws at a time. Azure directory can be used because we don't have any installations which is on vintage.

* Update Kubernetes version from 1.25.16 to 1.26.15 * Update cluster-autoscaler to 1.27.3-gs10 * Update cloud-provider-aws to 1.26.11-gs1 * Remove CI that creates draft releases * Fix CAPA kustomization * Add announcement --------- Co-authored-by: yulianedyalkova <[email protected]> Co-authored-by: Daniel Simionato <[email protected]>

njuettner · 2024-07-23T09:50:53Z

/run releases-test-suites

njuettner · 2024-07-23T09:54:57Z

/run releases-test-suites TARGET_SUITES=./providers/capz/standard TARGET_RELEASES=azure-25.0.0

njuettner · 2024-07-23T12:20:42Z

/run releases-test-suites TARGET_SUITES=./providers/capz/standard

AverageMarcus · 2024-07-23T12:39:16Z

/run releases-test-suites

AverageMarcus · 2024-07-23T12:50:45Z

/run releases-test-suites TARGET_SUITES=./providers/capz/standard TARGET_RELEASES=azure-25.0.0

AverageMarcus · 2024-07-23T13:44:32Z

/run releases-test-suites

AverageMarcus · 2024-07-23T13:46:19Z

/run releases-test-suites TARGET_SUITES=./providers/capz/standard TARGET_RELEASES=azure-25.0.0

tinkerers-ci · 2024-07-23T14:23:35Z

releases-test-suites

Run name	`pr-releases-1296-releases-test-suiteszhrbs`
Commit SHA	`ef186f9`
Result	Succeeded ✅

📋 View full results in Tekton Dashboard

Rerun trigger:
/run releases-test-suites

Tip

To only re-run the failed test suites you can provide a TARGET_SUITES parameter with your trigger that points to the directory path of the test suites to run, e.g. /run releases-test-suites TARGET_SUITES=./providers/capa/standard to re-run the CAPA standard test suite. This supports multiple test suites with each path separated by a comma.

Alternatively, or in addition to, you can also specify TARGET_RELEASES to trigger tests for specific releases. E.g. /run releases-test-suites TARGET_SUITES=./providers/capa/standard TARGET_RELEASES=aws-25.0.0-test.1

njuettner · 2024-07-23T14:51:03Z

/run conformance-tests RELEASE_VERSION=v25.0.0 PROVIDER=capz

njuettner · 2024-07-23T16:52:28Z

Two failing tests are fine due to Kyverno and Cilium expected to fail.

Failed tests:
 - [It] [sig-network] HostPort validates that there is no conflict between pods with same hostPort but different hostIP and protocol [LinuxOnly] [Conformance]
	 - 
 - [It] [sig-node] Ephemeral Containers [NodeConformance] will start an ephemeral container in an existing pod [Conformance]