Sync upstream (5c0bdf84) — needs conflict resolution - #86
Open
cloud-api-adaptor-upstream-sync[bot] wants to merge 244 commits into
Open
cloud-api-adaptor-upstream-sync[bot] wants to merge 244 commits into
cloud-api-adaptor-upstream-sync[bot] wants to merge 244 commits into
Conversation
Move the cluster provisioning to BYOM to remove the dependency on the deprecated Docker provider. Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
This commit adds extensive unit test coverage for the libvirt cloud provider, while preserving all existing tests from the main branch. New unit tests added (using mocks): - TestGetGuestForArchType (6 subtests) - TestLookupMachine (5 subtests) - TestGetCanonicalMachineName (7 subtests) - TestCreateCloudInitISO (3 subtests) - TestGetLaunchSecurityTypeInvalidURI - TestCreateDomainXMLs390xWithMocks (mock-based unit test) - TestCreateDomainXMLaarch64WithMocks (mock-based unit test) - TestCreateDomainXMLx86_64 (3 subtests) - TestCreateDomainXML (3 subtests) - TestVerifyDomainXMLIOMMU (4 subtests) - Combined TestCreateDomainXMLs390x and TestCreateDomainXMLaarch64 into TestCreateDomainXMLArchitectures - Combined TestCreateDomainXMLs390xWithMocks and TestCreateDomainXMLaarch64WithMocks into TestCreateDomainXMLArchitecturesWithMocks - Improves code maintainability and reduces duplication Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com> Assisted-by: IBM Bob <noreply@ibm.com>
- Refactor TestCloudInit to use verifyISOContents helper and tabular format - Combined TestCreateCloudInitWithEmptyData, TestCreateCloudInitWithLargeData, TestCreateCloudInitWithSpecialCharacters, and TestCreateCloudInitVerifyVendorData into TestCreateCloudInitVariations - Add TestCreateCloudInitErrorHandling for boundary condition testing - All tests now use verifyISOContents helper for consistent ISO validation - Improves code maintainability and reduces duplication Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com> Assisted-by: IBM Bob <noreply@ibm.com>
- Add tests for Manager.ParseCmd() flag registration - Add tests for Manager configuration with values - Add tests for Manager.LoadEnv() and GetConfig() - Add tests for Manager.NewProvider() with valid/invalid configs - Add tests for default constants validation - Add tests for launch security, firmware, and data directory configuration - Covers all Manager initialization and configuration scenarios Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com> Assisted-by: IBM Bob <noreply@ibm.com>
Bumps [github.com/containerd/containerd](https://github.com/containerd/containerd) from 1.7.29 to 1.7.32. - [Release notes](https://github.com/containerd/containerd/releases) - [Changelog](https://github.com/containerd/containerd/blob/main/RELEASES.md) - [Commits](containerd/containerd@v1.7.29...v1.7.32) --- updated-dependencies: - dependency-name: github.com/containerd/containerd dependency-version: 1.7.32 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <support@github.com>
Now that agent-ctl tags based on sha, we can switch to use the main kata-containers version, rather than having a separate one. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump components to match the kata 3.31.0 release Assisted-by: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update to pick up the 3.31.0 release Assisted-by: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Pin kata-deploy to the 3.31.0 version in prep of the 0.21.0 release Assisted-by: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bumps [zizmorcore/zizmor-action](https://github.com/zizmorcore/zizmor-action) from 0.5.3 to 0.5.6. - [Release notes](https://github.com/zizmorcore/zizmor-action/releases) - [Commits](zizmorcore/zizmor-action@b1d7e1f...5f14fd0) --- updated-dependencies: - dependency-name: zizmorcore/zizmor-action dependency-version: 0.5.6 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Bump the go module to remediate CVEs: - GO-2026-5026 - GO-2026-4883 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bump the go module to remediate CVEs: - GO-2026-5013 - GO-2026-5017 - GO-2026-5018 - GO-2026-5019 - GO-2026-5020 Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update the helm charts with the latest image of CAA Signed-off-by: stevenhorsman <steven@uk.ibm.com>
But the appVersion to 0.21 to match the release and bump the version in peer-pods, peerpod-ctrl and webhook Signed-off-by: stevenhorsman <steven@uk.ibm.com>
The `kubectl apply` of the cert-manager manifest occasionally fails with an etcd timeout: ``` Error from server: error when creating ".../cert-manager.yaml": etcdserver: request timed out. ``` The manifest creates a large batch of resources (6 CRDs, RBAC, deployments, webhook configs) in a single apply, and individual writes can occasionally exceed the API server's request timeout under transient cluster load. Wrap the apply in a retry loop (3 attempts, 10s backoff). `kubectl apply` is idempotent, so retrying after a partial failure simply creates the missing resources without disturbing the ones already applied. On the observed failing run, everything except (likely) the last webhook config got created, and the retry will fill in the gap. For `kubectl wait`, the Endpoints object isn't created by the cert-manager manifest directly. It's created by the kube-controller-manager's endpoints controller after the Service is created and once matching pods exist. Right after `kubectl apply` returns, there's a brief window where the Service exists but its Endpoints object hasn't been populated yet. The apply just finished, so `kubectl wait` raced ahead of the controller. Assisted-by: IBM Bob Signed-off-by: Hyounggyu Choi <Hyounggyu.Choi@ibm.com>
The podvm-ubuntu-mkosi job calls podvm_mkosi_ubuntu.yaml which requires artifact-metadata: write permission for the actions/attest@v4.1.0 action to write attestation metadata. Without this permission, the workflow fails with "The nested job 'build-image' is requesting 'artifact-metadata: write', but is only allowed 'artifact-metadata: none'." This matches the permission already granted to the podvm-mkosi job on line 84. Signed-off-by: stevenhorsman <steven@uk.ibm.com> Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Also added MKOSI_VERSION environment variable to image build steps in both podvm_mkosi.yaml and podvm_mkosi_ubuntu.yaml workflows to ensure the mkosi version from versions.yaml is explicitly passed to make commands, maintaining consistency with the binaries build step. Signed-off-by: stevenhorsman <steven@uk.ibm.com> Generated-By: IBM Bob
The image target was calling mkosi with '--image system' argument which is not supported in mkosi v26, causing build failures with: "mkosi: error: argument verb: invalid Verb value: 'system'" This argument was a remnant from mkosi v22 that wasn't removed during the v26 upgrade. The image-debug and image-sftp targets were already correct, so this change aligns the image target with them. Fixes the s390x production image builds. Signed-off-by: stevenhorsman <steven@uk.ibm.com> Generated-By: IBM Bob
The cross-build script was failing on ARM64 native builds because it compared ARCH=arm64 with uname -m=aarch64, which didn't match, causing it to incorrectly attempt cross-compilation and fail with: "E: Unable to locate package qemu-system-aarch64" Added replacement pattern to handle this Co-authored-by: Magnus Kulke <magnuskulke@microsoft.com> Signed-off-by: stevenhorsman <steven@uk.ibm.com> Generated-By: IBM Bob
Implement IRSA support for the AWS provider to enable workload identity authentication on EKS, eliminating the need for static credentials stored in Kubernetes secrets. NewEC2Client now supports three authentication methods: 1. Static credentials (AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY) 2. Shared AWS profile (AWS_PROFILE, currently, only non-containerized CAA binary execution is supported) 3. Default credential chain (for IRSA support) The default credential chain automatically supports IRSA via AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN Entrypoint validation updated to accept either: - Both AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY (static credentials) - AWS_WEB_IDENTITY_TOKEN_FILE and AWS_ROLE_ARN (IRSA) Fixes: confidential-containers#3027 Signed-off-by: Snir Schreiber <ssheribe@redhat.com> Assisted-by: Claude AI
Add unit tests to verify the two authentication paths in NewEC2Client: 1. Static credentials (AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY) 2. Default credential chain (IRSA, IMDS, environment variables, etc.) Tests cover: - Static credentials path with both access key and secret key - Default credential chain path when no static credentials provided - Partial credentials (only access key) falls through to default chain Assisted-by: Claude AI Signed-off-by: Snir Schreiber <ssheribe@redhat.com>
Added comprehensive guide for configuring IRSA with cloud-api-adaptor and peerpod-ctrl on Amazon EKS. The guide covers: - IAM trust policy configuration - Kubernetes service account annotations - Deployment configuration examples - Troubleshooting steps Assisted-by: Claude AI Signed-off-by: Snir Schreiber <ssheribe@redhat.com>
It looks like when the arm "support" for podvm builds was added, it wasn't updated to use the native arm runner, so update this, for simpler workflows Signed-off-by: stevenhorsman <steven@uk.ibm.com>
In case we want to support cross-compilation in future e.g. for local dev, fix up the logic. The cross-build script was using architecture names directly as QEMU package names, but Debian/Ubuntu package names don't always match: - x86_64 → qemu-system-x86 (not qemu-system-x86_64) - aarch64 → qemu-system-arm (not qemu-system-aarch64) - s390x → qemu-system-s390x (matches) Added architecture-to-package mapping for Debian/Ubuntu systems to use correct package names. Package names verified against Ubuntu 24.04. Signed-off-by: stevenhorsman <steven@uk.ibm.com> Assisted-by: IBM Bob
As we are doing a 0.21.1 release, we should update the charts to match this version. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
This reverts commit a1633eb. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
This reverts commit 02bb592. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update the CITATION.cff for the 0.21.1 release Signed-off-by: stevenhorsman <steven@uk.ibm.com>
debian:trixie-slim ships without CA certificates. The dev build got them transitively via openssh-client, but the release build only installed iptables, causing Go TLS verification to fail against ec2.<region>.amazonaws.com with x509: certificate signed by unknown authority. Signed-off-by: Pradipta Banerjee <pradipta.banerjee@gmail.com>
Bumps [actions/stale](https://github.com/actions/stale) from 10.2.0 to 10.3.0. - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@b5d41d4...eb5cf3a) --- updated-dependencies: - dependency-name: actions/stale dependency-version: 10.3.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Update default sys-type to s1022 as s922 is being deprecated across different regions. Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
Add validation for required field - NetworkID, ServiceInstanceID and Zone. Also validate ProcessorType and SystemType against their allowed values. Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
The mount unit was deleted in b2ba085, remove the references to it in setup byom script and the Dockerfile. Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
Instead of defaulting to normal VMs, default to TrustedLaunch. When DisableCVM is false, the ConfidentialVM security profile with VMGuestStateOnly disk encryption is applied. For standard VM sizes, a TrustedLaunch security profile with Secure Boot and vTPM is used instead. This also simplifies the security profile logic: TrustedLaunch is always set as the baseline (with SecureBoot and vTPM), and only upgraded to ConfidentialVM when the size supports it and CVM is not disabled. Signed-off-by: Emanuele Giuseppe Esposito <eesposit@redhat.com>
- Add root user check to fail early - Add check for Subsytem sftp replace instead of append and prevent duplicate entries - Validate sshd config before restart - Clean /tmp/files and docker container to avoid error on re-run - Fix wrong $svc variable in agent-protocol-forwarder error path Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
checkDomainExistsByName returned the input vmConfig unchanged when a domain existed. v.instanceID is still "" at that point — the UUID is only assigned after DomainDefineXML/GetUUIDString, which that path never reaches. The empty ID silently bypasses the cleanup guard in cloud.go (instance.ID != ""), leaving the ghost domain running. Inline LookupDomainByName into CreateDomain, populate instanceID and ips from the existing domain before returning, and remove checkDomainExistsByName (dead code). Also eliminates the double libvirt round-trip the old pattern caused. Fixes: confidential-containers#3247 Assisted-by: IBM Bob <noreply@ibm.com> Signed-off-by: Ajay Victor <ajvictor@in.ibm.com>
During development, several of us have hit times where being able to access a failing peer pod VM has been crucial to debugging issues. The general approach to this is to add a sleep before, or comment out `DeleteInstance`, but this involved rebuilding the CAA image, so instead we can provide an option to set `PODVM_DEVELOPER_MODE=true` in peer-pods-cm which will skip this peer pod vm delete. Assisted-By: IBM Bob Signed-off-by: Chathurya Adapa <Adapa.Chathurya1@ibm.com> Signed-off-by: stevenhorsman <steven@uk.ibm.com>
If we are in developer mode then set the default peerpods-limit-per-node to be 1 to avoid Kubernetes creating multiple instances of a pod which has issues. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Replace the kustomize-based Trustee/KBS provisioner with Helm, mirroring the approach taken by kata-containers in kata-containers/kata-containers#12982. - In test/provisioner/provision.go: replace installOverlay + privateKey fields in KeyBrokerService with a single adminToken string - In test/provisioner/trustee_kbs.go: rewrite to clone the trustee repo, run helm upgrade --install against deployment/helm-chart/, and extract the admin JWT from the bootstrap Secret (trustee-bootstrap-user-keys); remove TLS cert generation, kustomize helpers, ed25519 key management, and the hardcoded coco-tenant/kbs names; IBM SE creds copy over SCP is retained, only the manual PV YAML patching is replaced by Helm values - Namespace changes: coco-tenant -> coco-trustee - Service changes: kbs -> trustee-kbs (NodePort: trustee-kbs-nodeport) - Auth changes: ed25519 key + --cert-file -> JWT + --admin-token-file - Scheme changes: https:// -> http:// (Helm chart NodePort is plain HTTP) The Attestation Service initialises a gRPC connection pool to RVPS at startup. On a fresh install all three pods (KBS, AS, RVPS) start simultaneously; if AS initialises before the RVPS pod is Ready the connection attempt times out and the AS process exits with: "transport error: Create rvps failed: gRPC pool error" Fix this with a two-phase deploy: 1. helm upgrade --install without --wait: submits all resources so the RVPS pod has time to become Ready before AS initialises. 2. helm upgrade with --set dnsHostAliasWorkaround=true --wait: re-renders the chart (lookup now finds live ClusterIPs for the hostAliases workaround) and waits for all pods to be Ready. Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Reduce to just pulling the kbs-client binary via oras; trustee repo is now cloned at deploy time by the provisioner Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Update the debug script to reflect the namespace and resource name changes introduced by the Helm-based trustee deployment: - Replace coco-tenant namespace with coco-trustee - Replace deployment/kbs log collection with label-based selector - Add log collection for attestation-service and rvps pods Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
It appears that some variants of containerd return `401 Unauthorized` and some `401 UNAUTHORIZED` if the image can't be pulled, so make the check case insensitive to handle both simply. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
We no longer have anything that calls the kustomize helper, so delete it. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Now that we aren't using kustomize remove the install from the workflows Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bumps [azure/login](https://github.com/azure/login) from 3.0.0 to 3.0.1. - [Release notes](https://github.com/azure/login/releases) - [Commits](Azure/login@532459e...f5d393a) --- updated-dependencies: - dependency-name: azure/login dependency-version: 3.0.1 dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: dependabot[bot] <support@github.com>
Currently the builds pass through a secret to quay.io. This will
prohibit the building of the images on forks for pull request builds,
forcing the use of the insecure pull-request-target mechanism in e2e
tests, even though podvm builds can be executed safely on forks.
This change removes the secret and its uses at the call site and
defaults to ghcr.io, which can be used in forks. For subsequent
pull request workflows registry should be set to
"ghcr.io/${{ github.repository_owner }}".
Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
In the release podvm publish worfklow we mirror the ghcr image to quay. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
golang.org/x/mod@v0.37.0 is affected by two HIGH advisories: - GO-2026-6179 (CVE-2026-56865, NVD 8.4): transparency log tile verification bypass in sumdb/tlog - GO-2026-6180 (CVE-2026-56864, NVD 7.5): unauthenticated hash accepted in Lookup in sumdb x/mod is indirect in both modules. Primary consumer in peerpod-ctrl is github.com/onsi/ginkgo/v2@v2.27.2; in cloud-api-adaptor it is kata-containers/src/runtime. Neither ginkgo v2.32.1 (latest) nor any other direct dep pulls x/mod to v0.40.0 yet, so pinning explicitly is the correct fix. go mod tidy in peerpod-ctrl also advances sibling x/ packages (crypto, net, text, tools) as required by MVS when x/mod is pinned at v0.40.0. Generated-By: IBM Bob Signed-off-by: Ajay Victor <ajvictor@in.ibm.com>
In confidential-containers#3257 we found that the change made in confidential-containers#3261 caused a mis-match with the generated provider yaml. The cause was that the workflow job that checks it, didn't run on that PR, so add an extra path trigger to plug this gap. Whilst we are at it, add the workflow to it's own trigger list, so we can test changes made to it, before merging. Signed-off-by: stevenhorsman <steven@uk.ibm.com>
In confidential-containers#3261 the provider.yaml update was missed, so fix that now by running `make -C src/cloud-providers sync-chart-values` Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Bumps [docker/login-action](https://github.com/docker/login-action) from 4.4.0 to 4.6.0. - [Release notes](https://github.com/docker/login-action/releases) - [Commits](docker/login-action@af1e73f...dbcb813) --- updated-dependencies: - dependency-name: docker/login-action dependency-version: 4.6.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [actions/stale](https://github.com/actions/stale) from 10.3.0 to 11.0.0. - [Release notes](https://github.com/actions/stale/releases) - [Changelog](https://github.com/actions/stale/blob/main/CHANGELOG.md) - [Commits](actions/stale@eb5cf3a...4391f3d) --- updated-dependencies: - dependency-name: actions/stale dependency-version: 11.0.0 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Bumps [docker/setup-buildx-action](https://github.com/docker/setup-buildx-action) from 4.2.0 to 4.3.0. - [Release notes](https://github.com/docker/setup-buildx-action/releases) - [Commits](docker/setup-buildx-action@bb05f3f...37fe631) --- updated-dependencies: - dependency-name: docker/setup-buildx-action dependency-version: 4.3.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
Add helm chart support for the BYOM SSH host key allowlist feature. When host keys are configured, the chart automatically mounts a Secret containing the public keys at /etc/byom/ssh-host-keys and injects SSH_HOST_KEY_ALLOWLIST_DIR into the peer-pods-cm ConfigMap. Two modes are supported: - create: supply keys via providerSecrets.byom.hostKeys; Helm creates the byom-ssh-host-keys Secret - reference: set secrets.existingByomHostKeySecretName to a pre-existing Secret managed externally Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
- Add TestByomSSHHostKeysAllowlist test case to verify the SSH host key allowlist functionality - Make helm install, namespace, and secret creation idempotent for cluster reuse Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
Add a second test phase to verify the SSH host key allowlist against the existing cluster with VERIFY_HOST_KEYS enabled. Signed-off-by: Amulyam24 <amulmek1@in.ibm.com>
Bumps google.golang.org/grpc v1.83.1 across all Go modules to fix CVE-2026-84304. Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
Fixes GO-2026-6354 and GO-2026-6355 — both DoS vulnerabilities in golang.org/x/crypto/ssh (deadlocked undecided and established channels). Generated-By: IBM Bob Signed-off-by: stevenhorsman <steven@uk.ibm.com>
GHCR_IMAGE needs to be lowercased. Signed-off-by: Magnus Kulke <magnuskulke@microsoft.com>
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 3 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 5c0bdf8. Configure here.
| image_tag: ${{ inputs.podvm_image_tag }} | ||
| git_ref: ${{ inputs.git_ref }} | ||
| arch: s390x | ||
| git_ref: ${{ github.sha }} |
There was a problem hiding this comment.
Azure podvm built from wrong ref
Medium Severity
podvm_mkosi_azure checks out github.sha while every other job in this workflow uses inputs.git_ref. A workflow_dispatch with a non-default ref builds the Azure PodVM from a different commit than the CAA image and the tests that consume it.
Reviewed by Cursor Bugbot for commit 5c0bdf8. Configure here.
| run: | | ||
| sudo apt-get update | ||
| sudo apt-get install -y --no-install-recommends \ | ||
| qemu-utils |
There was a problem hiding this comment.
Azure e2e skips Helm install
High Severity
The new Azure e2e workflow never installs Helm. make test-e2e with TEST_PROVISION=yes deploys CAA through the provisioner Helm charts, so this job will fail when it tries to invoke helm.
Reviewed by Cursor Bugbot for commit 5c0bdf8. Configure here.
| role-to-assume: ${{ secrets.ALIBABA_CLOUD_ROLE_ARN }} | ||
| oidc-provider-arn: ${{ secrets.ALIBABA_CLOUD_OIDC_PROVIDER_ARN }} | ||
| role-session-name: github-actions-caa-e2e | ||
| role-session-expiration: 3600 |
There was a problem hiding this comment.
Alibaba credentials expire during tests
Medium Severity
The Alibaba OIDC session is limited to 3600 seconds while TEST_E2E_TIMEOUT is 90 minutes. Cluster bring-up plus the e2e suite can outlive the credentials, causing later steps to fail with expired tokens.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit 5c0bdf8. Configure here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Upstream sync — manual merge needed
Upstream has new commits to merge into
cohere, but there are conflicts.Upstream HEAD:
5c0bdf84How to resolve
The sync branch already contains the upstream commits (it points at
origin/main). To make it mergeable intocohere,merge cohere into the sync branch and resolve conflicts there:
Your IDE will show the native merge conflict UI with accept-theirs /
accept-ours / accept-both options for each conflict. Once the push
succeeds, the PR will become mergeable.
Review checklist
Note
Medium Risk
Large CI and release-path changes affect how pod VM images and multi-cloud e2e run; Azure e2e and secret handling changes need verification after merge conflict resolution.
Overview
This upstream sync restructures Pod VM build and CI around a single
podvmtree (replacingpodvm-mkosipaths in docs and workflows) and drops legacy Packer-based podvm builder/binaries/image pipelines, CSI wrapper image builds, Docker-provider e2e, and the old standalone Azure e2e/podvm release workflows.E2E orchestration in
e2e_run_all.yamlnow builds mkosi images (including an Azure CVMaz-cvm-vtpmvariant), wires callable Alibaba Cloud e2e (OIDC, optional skip without secrets), and addse2e_azure.yamlthat publishes a gallery image then runs provisioned AKS tests—Azure e2e is limited to schedule/dispatch, not labeled PR runs. Libvirt/AWS tests use mkosi qcow2 artifacts; BYOM e2e builds podvm images in-job (optional input podvm) and adds an SSH host-key allowlist test pass. PR e2e dropstest_e2e_docker, addstest_e2e_alibabacloud, and passes dummy Azure secrets onpull_request_target.Workflow hygiene: broad GitHub Actions upgrades (checkout v7, setup-go v6.5, Docker/CodeQL/zizmor/stale bumps),
allow-unsafe-pr-checkoutfor PR-target builds, dependabot CodeQL grouping, removed packer-check from lint/Makefile, govulncheck ignore list for containerd CRI findings, release docs/README de-CSI, CITATION 0.22.0, and merged Ubuntu podvm smoke tests into one workflow.Reviewed by Cursor Bugbot for commit 5c0bdf8. Bugbot is set up for automated code reviews on this repo. Configure here.