chore(deps): update docker/setup-qemu-action action to v3.7.0#2
Closed
renovate[bot] wants to merge 2 commits into
Closed
chore(deps): update docker/setup-qemu-action action to v3.7.0#2renovate[bot] wants to merge 2 commits into
renovate[bot] wants to merge 2 commits into
Conversation
![renovate-approve[bot]](https://avatars.githubusercontent.com/in/7394?s=60&v=4){kind=small}
auto-merge was automatically disabled
November 13, 2025 15:51
Pull request was closed
renovate
Bot
dismissed
renovate-approve[bot]’s stale review
The merge-base changed after approval.
Contributor
Author
Renovate Ignore NotificationBecause you closed this PR without merging, Renovate will ignore this update ( If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR. |
9 tasks
peter-svensson
added a commit
that referenced
this pull request
May 7, 2026
Five fixes surfaced by smoke testing the secretBackend.kubernetes path against Scaleway managed PostgreSQL: 1. config/manager/manager.yaml: drop --leader-elect arg The flag was no longer registered (LeaderElection is hardcoded true for safe multi-replica operation), so the binary aborted on the unknown flag at startup. Removing the arg matches the new behaviour. BREAKING for kustomize users overriding the arg list. 2. internal/controller/database_controller.go: backend-aware default for secretName. Kubernetes Secret names reject '/'; the rds/<eng>/<db> path-shape was AWS-SM-friendly only. Use rds-<eng>-<db> for the kubernetes backend, keep slashes for AWS / Infisical. 3. RBAC marker: secrets verbs now include create/update/patch/delete. The kubernetes backend needs to write/delete Secrets, not just read. Regenerated config/rbac/role.yaml via 'make manifests'. 4. database_controller.go recovery: when userExists && !secretExists (and not a region-change), rotate the password via CreateUser (idempotent ALTER USER WITH PASSWORD) and recreate the secret instead of aborting with 'cannot recover password'. Previously left CRs perma-stuck because the kubernetes backend's finalizer also failed on the '/'-in-name issue from #2. 5. internal/database/postgres.go: resolve CURRENT_USER to a literal role name before issuing GRANT. Some managed PG providers (Scaleway managed RDB confirmed) reject 'GRANT role TO CURRENT_USER' with XX000 'cannot use special role specifier'. The literal-name form succeeds on RDS and on Scaleway (idempotent — Scaleway's _rdb_superadmin trigger already grants membership at CREATE USER).
peter-svensson
added a commit
that referenced
this pull request
May 7, 2026
Five fixes surfaced by smoke testing the secretBackend.kubernetes path against Scaleway managed PostgreSQL: 1. config/manager/manager.yaml: drop --leader-elect arg The flag was no longer registered (LeaderElection is hardcoded true for safe multi-replica operation), so the binary aborted on the unknown flag at startup. Removing the arg matches the new behaviour. BREAKING for kustomize users overriding the arg list. 2. internal/controller/database_controller.go: backend-aware default for secretName. Kubernetes Secret names reject '/'; the rds/<eng>/<db> path-shape was AWS-SM-friendly only. Use rds-<eng>-<db> for the kubernetes backend, keep slashes for AWS / Infisical. 3. RBAC marker: secrets verbs now include create/update/patch/delete. The kubernetes backend needs to write/delete Secrets, not just read. Regenerated config/rbac/role.yaml via 'make manifests'. 4. database_controller.go recovery: when userExists && !secretExists (and not a region-change), rotate the password via CreateUser (idempotent ALTER USER WITH PASSWORD) and recreate the secret instead of aborting with 'cannot recover password'. Previously left CRs perma-stuck because the kubernetes backend's finalizer also failed on the '/'-in-name issue from #2. 5. internal/database/postgres.go: resolve CURRENT_USER to a literal role name before issuing GRANT. Some managed PG providers (Scaleway managed RDB confirmed) reject 'GRANT role TO CURRENT_USER' with XX000 'cannot use special role specifier'. The literal-name form succeeds on RDS and on Scaleway (idempotent — Scaleway's _rdb_superadmin trigger already grants membership at CREATE USER).
peter-svensson
added a commit
that referenced
this pull request
May 7, 2026
Five fixes surfaced by smoke testing the secretBackend.kubernetes path against Scaleway managed PostgreSQL: 1. config/manager/manager.yaml: drop --leader-elect arg The flag was no longer registered (LeaderElection is hardcoded true for safe multi-replica operation), so the binary aborted on the unknown flag at startup. Removing the arg matches the new behaviour. BREAKING for kustomize users overriding the arg list. 2. internal/controller/database_controller.go: backend-aware default for secretName. Kubernetes Secret names reject '/'; the rds/<eng>/<db> path-shape was AWS-SM-friendly only. Use rds-<eng>-<db> for the kubernetes backend, keep slashes for AWS / Infisical. 3. RBAC marker: secrets verbs now include create/update/patch/delete. The kubernetes backend needs to write/delete Secrets, not just read. Regenerated config/rbac/role.yaml via 'make manifests'. 4. database_controller.go recovery: when userExists && !secretExists (and not a region-change), rotate the password via CreateUser (idempotent ALTER USER WITH PASSWORD) and recreate the secret instead of aborting with 'cannot recover password'. Previously left CRs perma-stuck because the kubernetes backend's finalizer also failed on the '/'-in-name issue from #2. 5. internal/database/postgres.go: resolve CURRENT_USER to a literal role name before issuing GRANT. Some managed PG providers (Scaleway managed RDB confirmed) reject 'GRANT role TO CURRENT_USER' with XX000 'cannot use special role specifier'. The literal-name form succeeds on RDS and on Scaleway (idempotent — Scaleway's _rdb_superadmin trigger already grants membership at CREATE USER).
opzkit-auto-merge Bot
pushed a commit
that referenced
this pull request
May 7, 2026
) * refactor(secrets): introduce Backend interface + factory Adds a backend-agnostic Backend interface (Exists, Get, Create, Update, Delete, Locator, SyncTags) and a NewBackend factory that picks an implementation based on the Database CR spec. Existing AWSSecretsManagerClient gains adapter methods so it satisfies Backend without renaming any of its current public methods — call sites that need AWS-specific behaviour (cross-region migration, source-side GetSecretString) continue to work unchanged. No behaviour change. Tests still pass. This is the first of two refactor commits towards supporting additional secret backends (Kubernetes Secret, Infisical Cloud). * refactor(secrets): replace SecretARN+SecretRegion with SecretLocator The two AWS-specific Database status fields are folded into a single generic SecretLocator string. For the AWS backend the locator is the ARN, which already carries the region; the cross-region migration logic now derives the previously-used region from the stored ARN via secrets.AWSRegionFromARN. Other backends (Kubernetes Secret, Infisical — added in subsequent phases) will populate SecretLocator with their own identifiers. The "Region" printcolumn becomes "Locator" with priority=1 (hidden by default in `kubectl get`, visible with -o wide). Behaviour preserved: - Cross-region migration still detects, fetches password from old region, creates in new region, deletes old after success. - Tag-sync, idempotent reconciliation, restore-from-deletion unchanged. This is the second commit of the Phase 1 refactor (Backend interface extraction). Phase 2 adds the Kubernetes Secret backend; Phase 3 adds Infisical Cloud. * chore(crds): regenerate from controller-gen v0.19.0 Output of `make manifests && make helm-crds`. No semantic change beyond the field rename done in the previous commit; this just refreshes the CRD to the current controller-gen formatting (description reflow, Condition struct doc, etc.) and populates config/crd/bases/ which was empty. * refactor!(api): nest backends under spec.secretBackend / spec.connectionString BREAKING CHANGE — drops the v0.1.x flat-field shape: spec.connectionStringSecretRef → spec.connectionString.kubernetes spec.connectionStringAWSSecretRef → spec.connectionString.aws spec.awsSecretsManager → spec.secretBackend.aws The new spec.secretBackend.{aws,kubernetes,infisical} oneOf is the seam for upcoming backends. Phase 2 fills in spec.secretBackend.kubernetes (KubernetesSecretBackend already declared). Phase 3 fills in the Infisical backend (InfisicalSecretBackend already declared with ProjectSlug/EnvironmentSlug/AuthSecretRef etc). Validation: the controller's existing oneOf checks for connectionString remain; secrets.NewBackend returns ErrMultipleBackendsConfigured / ErrNoBackendConfigured if zero or multiple secretBackend.* are set. Sample manifests, CRDs, and unit tests updated. AWSSecretsManagerConfig, SecretKeyReference, AWSSecretReference types removed. Refs Phase 2 / Phase 3 / Phase 4 release work. * feat(secrets): add Kubernetes Secret backend internal/secrets/kubernetes.go implements the Backend interface against controller-runtime's client.Client, storing the DatabaseSecret JSON blob under a single 'credentials' key in a Kubernetes Secret. Shape matches the AWS Secrets Manager backend so consumers can decode the same JSON regardless of which backend is configured. - Locator format: <namespace>/<name> - Description lands in the database.opzkit.io/description annotation (Kubernetes Secrets have no native description field) - Tags are mapped onto Secret labels (caller is responsible for ensuring values pass Kubernetes label validation) - Delete is idempotent on missing secrets (matches AWS impl) - Create overwrites an existing Secret to mirror AWS's restore-from-soft-deletion behaviour - forceDelete is ignored — Kubernetes Secrets have no soft-delete Wired into secrets.NewBackend via the new spec.secretBackend.kubernetes case. The factory signature gains a client.Client parameter (used by the K8s backend; ignored by AWS and Infisical). Tests cover create/get/update/delete/exists/syncTags via controller-runtime's fake client. Also adds the requested AWSRegionFromARN unit test. The controller still calls AWSSecretsManagerClient directly for now; the next commit refactors it to use the Backend interface so spec.secretBackend.kubernetes works end-to-end. * refactor(controller): route destination secret ops through Backend Replaces direct AWSSecretsManagerClient calls in the destination secret create/update/delete/exists/get/sync-tags paths with the generic secrets.Backend interface (constructed via secrets.NewBackend). spec.secretBackend.kubernetes now works end-to-end against a Kubernetes Secret in the cluster; spec.secretBackend.aws continues to behave exactly as before (AWS adapter satisfies the interface). AWS-specific paths kept direct: - Cross-region migration in reconcileDatabase + secret reconciliation paths (oldRegionClient — only triggered when SecretBackend.AWS is set and the locator is an AWS ARN whose region differs from spec) - Source-side reading from AWS Secrets Manager via getConnectionStringFromAWSSecret (the connectionString.aws path) Removed dead helpers tagsEqual / getTagsToRemove / getTagsToAdd — each backend implements SyncTags internally. Their unit tests went with them. Status field rename: secretARN local var → secretLocator throughout the create/update flow, populated from backend.Locator() / backend return values. Build green, full test suite passes. * feat(secrets): add Infisical Cloud backend internal/secrets/infisical.go implements the Backend interface against Infisical (Cloud or self-hosted) via Universal Auth. The DatabaseSecret JSON blob is stored as a single Infisical secret value, matching the shape used by AWS Secrets Manager and the Kubernetes backend. - Authentication: Universal Auth (clientId + clientSecret) read from a Kubernetes Secret in the same namespace as the Database, referenced by spec.secretBackend.infisical.authSecretRef. - Locator format: infisical://<projectID>/<env><path>/<key> - Secret-key sanitisation: slashes in the supplied name (default rds/<engine>/<db>) are replaced with underscores so the result is a valid Infisical secret key. - Restore-on-create: if the secret already exists, Create overwrites it via Update — same semantics as AWS / Kubernetes. - SyncTags is a no-op: Infisical tags are first-class entities with their own UUIDs; mapping AWS-style key/value tags onto them is out of scope. - Versioning: Infisical's V3 secrets API doesn't expose per-secret version IDs, so Create/Update return an empty version string. Wired into secrets.NewBackend via the spec.secretBackend.infisical case. Factory reads the auth Secret using the K8s client. CRD: spec.secretBackend.infisical now exposes ProjectID (UUID) and Environment (slug) instead of the previously declared ProjectSlug / EnvironmentSlug — the Infisical V3 API requires the UUID for create/update/delete, slug only works on retrieve. Tests use an in-memory fake implementing the InfisicalSecretClient interface, covering create/get/update/delete/exists/sync-tags + key sanitisation and login-error propagation. Adds dependency github.com/infisical/go-sdk v0.7.1 (and its transitive google.golang.org/api / OpenTelemetry / grpc deps — substantial; see v0.2.0 release notes). Sample manifest under config/samples/. Closes Phase 3 of the multi-backend refactor. * fix(controller): address PR #135 smoke-test blockers Five fixes surfaced by smoke testing the secretBackend.kubernetes path against Scaleway managed PostgreSQL: 1. config/manager/manager.yaml: drop --leader-elect arg The flag was no longer registered (LeaderElection is hardcoded true for safe multi-replica operation), so the binary aborted on the unknown flag at startup. Removing the arg matches the new behaviour. BREAKING for kustomize users overriding the arg list. 2. internal/controller/database_controller.go: backend-aware default for secretName. Kubernetes Secret names reject '/'; the rds/<eng>/<db> path-shape was AWS-SM-friendly only. Use rds-<eng>-<db> for the kubernetes backend, keep slashes for AWS / Infisical. 3. RBAC marker: secrets verbs now include create/update/patch/delete. The kubernetes backend needs to write/delete Secrets, not just read. Regenerated config/rbac/role.yaml via 'make manifests'. 4. database_controller.go recovery: when userExists && !secretExists (and not a region-change), rotate the password via CreateUser (idempotent ALTER USER WITH PASSWORD) and recreate the secret instead of aborting with 'cannot recover password'. Previously left CRs perma-stuck because the kubernetes backend's finalizer also failed on the '/'-in-name issue from #2. 5. internal/database/postgres.go: resolve CURRENT_USER to a literal role name before issuing GRANT. Some managed PG providers (Scaleway managed RDB confirmed) reject 'GRANT role TO CURRENT_USER' with XX000 'cannot use special role specifier'. The literal-name form succeeds on RDS and on Scaleway (idempotent — Scaleway's _rdb_superadmin trigger already grants membership at CREATE USER). * docs: update CRD examples and prose for new spec.connectionString/secretBackend Mass rename across README and docs: spec.connectionStringSecretRef -> spec.connectionString.kubernetes spec.connectionStringAWSSecretRef -> spec.connectionString.aws spec.awsSecretsManager -> spec.secretBackend.aws Also refreshed TROUBLESHOOTING.md prose to reflect that AWS permissions are now optional (depend on the chosen backend, not always required) and removed the stale --leader-elect example since the flag is no longer registered. * fix(database): grant admin role WITH INHERIT, SET for PG 16+ PG 16 changed GRANT defaults to NOINHERIT, NOSET, NOADMIN. CREATE/ALTER DATABASE ... OWNER now requires the executor to hold SET privilege on the owner role, not just bare membership. Aurora/RDS paper over this via an event trigger on CREATE ROLE that grants WITH INHERIT, SET, ADMIN OPTION. Scaleway managed RDB and self-hosted PG 16+ do not, so the operator failed with 'must be able to SET ROLE' (42501) on those providers. Add WITH INHERIT TRUE, SET TRUE to the admin-grant statement. PG <16 honours INHERIT and ignores the SET column cleanly. * docs: document supported database versions PostgreSQL 14+ (tested on 15/16/17), MySQL 8.0+, MariaDB 10.6+. Also clarify AWS credentials are only required when the AWS backends (secretBackend.aws or connectionString.aws) are used. * test(integration): update CRs to new spec.connectionString/secretBackend shape Old ConnectionStringSecretRef + bare SecretName fields removed in 158fda5. Integration tests still referenced them and failed to build. Replace with spec.connectionString.kubernetes (admin DSN source) and spec.secretBackend.aws (generated-credential dest) across all 12 createDatabase call sites. * test(integration): assert recovery (not error) when secret missing Old test expected phase=Error with message about cannot recover password. New behaviour (introduced with the smoke-test blocker fix in e619043): controller rotates the password via ALTER USER and recreates the secret. Updated test now waits for Ready phase and verifies the secret reappears in AWS Secrets Manager with the same username and a non-empty password.
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
1 participant
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.
This PR contains the following updates:
v3.3.0->v3.7.0Release Notes
docker/setup-qemu-action (docker/setup-qemu-action)
v3.7.0Compare Source
Full Changelog: docker/setup-qemu-action@v3.6.0...v3.7.0
v3.6.0Compare Source
Full Changelog: docker/setup-qemu-action@v3.5.0...v3.6.0
v3.5.0Compare Source
Full Changelog: docker/setup-qemu-action@v3.4.0...v3.5.0
v3.4.0Compare Source
Full Changelog: docker/setup-qemu-action@v3.3.0...v3.4.0
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.