* Support overriding Schedule annotations via template.metadata.annotations
Adds an Annotations field to BackupSpec.Metadata, mirroring the existing
Labels override. When Schedule.Spec.Template.Metadata.Annotations is set,
it is used for the resulting Backup's annotations instead of copying
Schedule.Annotations directly, allowing users to opt out of unwanted
annotations (e.g. ArgoCD tracking annotations) being propagated from
Schedule to Backup.
Fixes#5836
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
* Rename changelog fragment to match PR number 10045
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
---------
Signed-off-by: Lubron Zhan <lubronzhan@gmail.com>
Co-authored-by: Daniel Jiang <daniel.jiang@broadcom.com>
Stop force-including VolumeSnapshotContents via resourceMustHave on
every restore; CSI VolumeSnapshot/PVC RestoreItemActions now set
`restore.velero.io/must-include-additional-items` so bound snapshot
dependencies are restored only when their parent is restored.
Fixes: #9957
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Let RestoreItemActions opt in via annotation to
bypass global restore filters for AdditionalItems,
mirroring the backup-side must-include behavior.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Update the landing page CTA link from the outdated Velero 1.11 blog
post to the GitHub releases/latest URL, which always resolves to the
most recent release and will not go stale.
Fixes#10080
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Support set-based filter label selectors
Use matchLabels/matchExpressions in fine-grained filters.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
* omit the details of resource policy for cli
The reason to not resolve and display CLI is because it may go
out of sync, we want to avoid display it to mislead users.
We may consider to cpature those information and display it
in later release.
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
---------
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
Co-authored-by: Scott Seago <sseago@redhat.com>
* Derive Ginkgo CLI version from go.mod in test/Makefile
Hardcoded @v2.22.0 pin drifted from go.mod's v2.28.3, causing
Ginkgo CLI/package version mismatch warnings.
Fixes#10023
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Derive protoc-gen-go and goimports versions from go.mod in build-image
Same drift issue as #10023: Dockerfile hardcoded @v1.33.0 and @v0.33.0
while go.mod had moved on. Build context is hack/build-image, which
doesn't include go.mod, so versions are computed in the Makefile (which
does have go.mod) and passed through as build-args, same as GOPROXY.
protoc-gen-go-grpc and controller-gen/setup-envtest/golangci-lint are
left as-is: no matching go.mod entry, or independently versioned from
the module they live alongside.
Fixes#10023
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
The test assumed all ten Write calls succeed before any async goroutine
stores its error, but with a mock that fails instantly a goroutine can
poison the writer mid-loop, making a later Write correctly fail fast —
a timing-dependent test failure.
Rewrite the test to assert the real-world contract instead of one
schedule: a failed async block write either fails a subsequent Write
fast or surfaces at Result, and is never lost. Add a separate
deterministic case pinning the late-error schedule, holding async
writes until all writes are queued so Result alone must report the
error.
Verified with -race -count=100.
Fixes#10029
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
The Velero repositories have moved to the velero-io GitHub organization.
Update references in docs, GOVERNANCE.md, and SECURITY.md for repos
that have migrated (velero, plugin-for-aws, plugin-for-gcp,
plugin-for-microsoft-azure, plugin-for-example). References to repos
that have not moved (helm-charts, plugin-for-vsphere, plugin-for-csi)
are left unchanged.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Remove the unused collectGaugeCount helper and assert specific label
values survive after each deletion using testutil.ToFloat64.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Replace blanket Reset() with targeted DeleteLabelValues to avoid
briefly wiping metrics for schedules that still exist. Track known
schedules in a set and only delete stale entries on each resync.
Extract the wait.Until closure into resyncBackupMetrics() so tests
can call it directly without goroutine timing. Replace hand-rolled
collectGaugeCount helper with testutil.CollectAndCount.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add a test that exercises the actual updateTotalBackupMetric goroutine
with a fake client to verify stale backupLastSuccessfulTimestamp
entries are pruned during a real resync cycle.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Avoid clearing backupLastSuccessfulTimestamp on transient API errors.
The reset and re-set now only run when the backup List call succeeds,
so existing metric values remain stable across temporary failures.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Remove the exported method that was only used in tests. Use the
existing Metrics() getter to access the gauge directly in the
backup controller test instead.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
The periodic backup metrics resync in updateTotalBackupMetric only set
backupLastSuccessfulTimestamp values but never removed stale entries.
When a schedule was deleted and its backups removed, the gauge persisted
until the Velero pod was restarted.
Reset the gauge before re-setting current values so that deleted
schedules are pruned automatically each resync cycle.
Fixes#9239
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Add a method to reset all backupLastSuccessfulTimestamp gauge values.
This will be used by the backup controller's periodic resync to prune
stale metrics for deleted schedules.
Fixes#9239
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
curl piped straight into jq with no error check; a non-JSON or failed
HTTP response (rate limit, transient API error) broke jq with an
opaque parse error. Add --fail-with-body, retries, and validate the
parsed SHA before continuing.
Fixes#10048
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Wenkai Yin(尹文开)
Adam ZhangandGitHub
Scott SeagoandGitHub
lyndon-liandGitHub
Lyndon-Li
Xun Jiang/Bruce JiangandGitHub
Shubham PampattiwarandGitHub
dependabot[bot]andGitHub
Tiger KaovilaiandGitHub
