* e2e: fail the suite when a label filter selects no specs
A label expression that matches nothing is reported as a pass. Ginkgo
runs zero specs, prints SUCCESS!, and exits 0, so a run that tested
nothing is indistinguishable from one that tested everything asked of it:
$ GINKGO_LABELS='Basic && BackupsSync' make -C test/ run-e2e
Ran 0 of 70 Specs in 0.001 seconds
SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 70 Skipped
That expression looks reasonable and selects nothing, because the backup
sync case is labelled Backups rather than Basic. The same shape of
mistake kept the VolumeGroupSnapshot case from running for months, where
CSISnapshot did not select CSIVolumeGroupSnapshot because a bare token is
matched by equality rather than as a substring.
Pass --fail-on-empty, which ginkgo has supported for far longer than the
version in go.mod, so the above now ends in:
FAIL! - Detected no specs ran and --fail-on-empty is set
It cannot affect a run that selects specs and then skips them at run
time, which this suite does constantly on kind. The flag tests
specs.CountWithoutSkip(), and that Skip field is set only while the label
filter is applied, before anything runs; a Skip() call during a spec sets
the spec's state instead. Checked all five label rows the kind workflow
uses against every labelled Describe in the suite: the smallest selects
two specs, so none of them starts failing.
run-perf keeps the old behaviour. It takes its own labels for a different
workload, and an empty selection there is not what this is about.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10674
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: match --features as the comma-separated list it is
--features takes a comma-separated list, but every check for EnableCSI in
the suite compares the whole flag value against the single feature name.
With --features=EnableCSI,EnableAPIGroupVersions none of them match, so a
CSI run quietly behaves as a non-CSI one: BeforeSuite skips installing the
VolumeSnapshotClass, installKibishii picks the provider's plain overlay
rather than its CSI one, and BuildSnapshotCheckPointFromVolumeInfo returns
a checkpoint with EnableCSI false and no snapshot handles, so the CSI
snapshot count is never compared against the expected one.
One site already used strings.Contains instead, which handles a list but
matches any feature whose name merely starts with this one, and misses a
value that differs only in case.
Add FeatureEnabled, which splits on commas and compares each entry whole
and case-insensitively, and route all eleven call sites through it. The
table test covers the list, case and prefix shapes that the two previous
idioms each got wrong.
hack/test.sh listed only ./pkg/..., ./internal/... and ./cmd/..., so
nothing under test/ was ever unit tested and this table would not have run
in CI. Add ./test, which holds the suite's shared types and nothing that
needs a cluster. The e2e suites live in subpackages and stay unlisted.
Found while reviewing the kind-csi mapping in #10657, which copied the
EqualFold form from the Azure and AWS branches beside it.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10661
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
e2e: run the RetainPV case too, and move the predicate beside the mapping
The RetainPV case was left out of the matrix on the assumption that it
needed checking first. It did not: it passes. Run on kind with
EnableCSI, Ran 1 of 70 Specs in 354 seconds, 1 passed, installing from
overlays/sc-reclaim-policy/kind-csi and taking two real CSI snapshots of
Kibishii's PVCs. So drop the exclusion rather than add a second row, and
the label becomes plain Basic && Snapshot, which selects the plain
snapshot case and the retained-PV one.
That overlay is the other half of the Kibishii change, and nothing
exercised it until now.
KibishiiVolumesAreHostPath moves from test/types.go to sit beside
installKibishii, since it is the inverse of that function's Kind branch
and the two have to agree on what enabling CSI means. Each now points at
the other in a comment. There is no import cycle: the kibishii package
already dot-imports test, and every call site already dot-imports
kibishii.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: point Kibishii at the kind-csi overlay when CSI is enabled
installKibishii maps the cloud platform to a Kibishii overlay directory
and already swaps Azure and AWS for their CSI variants when EnableCSI is
set. Kind has no such branch, so a CSI run on kind gets the plain kind
overlay, whose StorageClass provisions with rancher.io/local-path. Those
PVs are hostPath volumes and Velero skips them for both CSI snapshots
and PodVolumeBackups, which is why the snapshot cases are guarded off on
kind today.
Add the kind branch alongside the other two, and move KIBISHII_COMMIT to
the commit that adds the overlay. The pin delta is additive: the only
difference between the two trees is the new kind-csi directory and its
reclaim-policy overlay, so the plain kind overlay that run-e2e-test uses
still builds on rancher.io/local-path.
Nothing selects a Kibishii case under EnableCSI yet, so this changes no
observable behaviour on its own. Narrowing the kind guards and adding a
label set to the CSI job follow separately.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10657
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: run the CSI cases on kind in CI
The CSI cases have never run in CI. kind has no driver that can take
snapshots, so they were skipped by omission: no label set selects them
and FEATURES is never set.
Add a job that installs the snapshot stack with
hack/install-csi-hostpath.sh and runs them against it, with the
StorageClass pointed at a hostpath definition so the volumes can actually
be snapshotted.
It is a separate job rather than a fifth entry in the existing matrix.
Installing the stack measures at about 3.4 minutes, which every job would
pay, and ResourceFiltering already peaks six minutes under its timeout.
This also keeps a CSI problem from reddening a job that has nothing to do
with CSI.
It runs on the newest three Kubernetes versions. csi-driver-host-path
ships deploy manifests only for recent releases, so the older end of the
matrix has nothing to install.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10644
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
This commit makes change to the code, scripts and some template files to
reflect the change of the org after donation to CNCF.
The files under "/site" "/changelogs" and "/design" are deliberately
excluded in this change. I'll make follow up changes in these
directories when needed.
Signed-off-by: Daniel Jiang <daniel.jiang@broadcom.com>
The CSI-on-kind section told readers to sed the provisioner in
test/testdata/storage-class/kind.yaml, with a warning not to commit it,
because nothing on main could point the suite at a different definition.
--storage-class-file can, so describe that instead.
The manifest is given inline rather than referencing a file in the tree,
so the instructions do not depend on which CSI test data happens to
exist, and the warning about mutating shared test data goes away with
the sed.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
The e2e suite creates both of its StorageClasses from the provider's file
under testdata/storage-class, so running against a cluster whose volumes
need a different provisioner or parameters means editing test data every
other job also reads. On kind that is the only way to get a class a CSI
driver can snapshot.
Take the definition as a flag instead. --storage-class-file and
--storage-class-file-2 name a manifest each, and the suite keeps creating
and deleting what it applied, so nothing adopts resources it did not make.
The class names stay fixed. Every spec refers to e2e-storage-class and
e2e-storage-class-2, and CreateStorageClassFromYaml already takes a name
override, so only the definition needs to vary.
An empty --storage-class-file-2 runs without a second StorageClass, and
the three cases that map between two of them skip with a message saying
how to enable them. Which specs need it cannot be worked out in
BeforeSuite, since the label filter is not visible there yet, so this is
expressed as an opt-out rather than detection.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: add VolumeGroupSnapshot coverage
Velero groups PVCs that share a label into one VolumeGroupSnapshot, but
nothing in the e2e suite exercises that path, so a regression in it would
go unnoticed.
Add a case alongside the other backup-volume-info CSI cases. It creates
two PVCs carrying the grouping label the Velero server defaults to,
velero.io/volume-group, and asserts that the backup's volume info reports
the same VolumeGroupSnapshotHandle for both. One shared handle is what
distinguishes a group snapshot from the volumes having been snapshotted
one at a time, which is the part worth asserting.
The suite installs a VolumeGroupSnapshotClass beside the
VolumeSnapshotClass and removes it afterwards. Only providers that have
the test data get one, so the case runs where a class exists and is
skipped elsewhere, in the same way the existing CSI cases are skipped
when the CSI feature is off. Removing it afterwards matters: Velero
cannot choose between two classes carrying the selector label, and fails
every VolumeGroupSnapshot backup on that cluster if one is left behind.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10598
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: log the VolumeGroupSnapshotHandle the VGS case asserts on
CSISnapshotInfo is a pointer, so printing the VolumeInfo with %+v emits
CSISnapshotInfo:0x270e179b4900 and nothing about the handle. This case
exists to check that every volume in the group reports the same handle,
so a failure in CI currently gives no way to see what the handles
actually were.
Print the handle per PVC alongside the existing line. The other
backup-volume-info cases print the same way; changing those belongs in
its own change.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: correct why the kind backup cases are skipped
The comment attributes the File System Backup skip to kind, saying hostpath
volumes are "the only volumes created on kind clusters". That stopped being
true once csi-driver-host-path can be installed, and it points at the wrong
cause: isHostPathVolume matches pv.Spec.HostPath, so a CSI-backed class
produces pv.Spec.CSI and PodVolumeBackups are created normally.
Both halves of the skip come from the same place, the StorageClass behind
Kibishii's PVCs, which the kind overlay defines on rancher.io/local-path.
Say that instead, and name what unskipping these would actually need, so the
next person does not go looking for a velero-side fix that cannot exist.
No behaviour change.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10636
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: document running the CSI cases on kind
The CSI cases are skipped on a plain kind cluster and nothing says how to
change that. Describe what hack/install-csi-hostpath.sh installs and why
kind needs it, how to run the CSI and VolumeGroupSnapshot label sets, and
the StorageClass changes the cases need until those definitions are
configurable, Kibishii's own class included.
Also two failure modes that are hard to read from their symptoms: two
VolumeGroupSnapshotClasses carrying the selector label, which makes
Velero refuse to pick one, and a csi-snapshotter sidecar whose caches
never sync, which makes snapshots hang rather than fail.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10630
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: note the WSL2 address and the exact label matching
Two things that cost time to find out and are not written down anywhere.
CI builds the BSL URL from $(hostname -i), which is correct on a runner but
resolves to an address the cluster cannot reach under WSL2, so the
BackupStorageLocation is unreachable and every backup fails to upload. Point
readers at the kind network's gateway instead.
A Ginkgo label filter matches a bare token by exact equality, not as a
substring, so a filter naming CSISnapshot does not select a case labelled
CSIVolumeGroupSnapshot. Say so next to the filter, because the failure mode is
a case that silently never runs rather than an error.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: verify CSI snapshots on kind
Four snapshot cases cannot run on kind today. The backup itself succeeds
and the volume info lists the snapshots, but verification fails with
"Cloud provider kind is not valid": getProvider knows aws, vsphere, gcp
and azure, and CheckSnapshotsInProvider exempts only vanilla-zfs, so kind
falls through to a cloud lookup it has no API for.
Check kind in the cluster instead. A backup's VolumeSnapshotContents
exist only briefly while it is being created, so they cannot be counted
afterwards the way the cloud providers count snapshots; what Velero
recorded in the backup's volume info can be, one ready CSI snapshot per
volume. That is a weaker statement than the cloud checks make, since it
says the snapshots were taken and reported ready rather than that they
still exist in the storage provider. A backup expected to have none left,
after its deletion, is checked the other way round: nothing for it may
remain in the cluster, which reuses CheckVolumeSnapshotCR.
BuildSnapshotCheckPointFromVolumeInfo only collected those snapshot
handles for AWS and Azure, so on kind the checkpoint arrived with no
handles and EnableCSI false even with FEATURES=EnableCSI. Include kind.
This does not remove any of the CloudProvider == Kind skips; they need
Kibishii to offer a CSI StorageClass for kind as well.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10593
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: check the snapshot handles rather than their count
Comparing the number of recorded snapshots against the number expected
cannot fail. BuildSnapshotCheckPointFromVolumeInfo already returns an
error when a volume is not ready to use, and again when the counts do not
match, and it appends to the list in that same loop, so the length is
settled before the check is reached.
It does not look at the handle it recorded, so a volume reported ready
with an empty snapshot handle passes today. Check that instead, which is
the difference between Velero saying a snapshot was taken and something
having been provisioned.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Migrate VolumeGroupSnapshot API from v1beta2 to v1
Signed-off-by: Prasad Joshi <prajoshi@redhat.com>
* Add changelog
Signed-off-by: Prasad Joshi <prajoshi@redhat.com>
* Detect VolumeGroupSnapshot API version at runtime
Velero hardcoded the VolumeGroupSnapshot (VGS) API version, so VGS backup and
restore failed on clusters that serve a different version than Velero expects.
For example OCP 5.0 serves only groupsnapshot.storage.k8s.io/v1 and OCP 4.22
serves only v1beta1, while Velero targeted a single version and failed with
"no matches for kind" on the others.
Detect the served VGS API version at runtime via the discovery client
(preferring v1 > v1beta2 > v1beta1) and perform all VGS, VGSClass and VGSContent
I/O through the dynamic client, converting to and from the canonical v1 typed
structs. The controller-runtime typed client cannot negotiate versions because
it sends the GVK of the Go type, so the dynamic client is used at the I/O
boundary instead. Owner-reference matching is now version-independent (Kind and
UID), since the CSI controller stamps refs with whatever version the cluster
serves.
This builds on the v1 migration and external-snapshotter client bump from the
previous commits.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Add changelog for VGS runtime version detection
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* docs: VGS supports v1/v1beta2/v1beta1 via runtime detection
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Remove superseded changelog for #10600 (covered by #10601)
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
* Use crClient + unstructured for VGS access instead of a dynamic client
Address review feedback: rather than a dedicated VGSClient wrapping
dynamic.Interface + discovery.DiscoveryInterface, perform all VolumeGroupSnapshot
I/O through the existing controller-runtime client with *unstructured.Unstructured.
The object's GVK is stamped to the served version and controller-runtime routes it
via its RESTMapper, giving the same multi-version behavior (v1/v1beta2/v1beta1)
that the typed client cannot.
This removes the extra client plumbing: no constructor signature changes to
NewRestoreFinalizerReconciler or server.go, no Factory DynamicClient/DiscoveryClient
mock churn, and no separate fake client package. The version is resolved from the
client's RESTMapper (preferring v1 > v1beta2 > v1beta1), and the helpers convert
to and from the canonical v1 typed structs.
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
---------
Signed-off-by: Prasad Joshi <prajoshi@redhat.com>
Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
Co-authored-by: Prasad Joshi <prajoshi@redhat.com>
* e2e: add kind VolumeGroupSnapshotClass test data
Velero selects a VolumeGroupSnapshotClass by the
velero.io/csi-volumegroupsnapshot-class label, and csi-driver-host-path
ships no VolumeGroupSnapshotClass at all, so there is nothing for the
selector to find on a kind cluster. Any VolumeGroupSnapshot e2e coverage
needs a class to exist first.
Add the kind entry alongside the existing volume-snapshot-class test
data, following the same layout and naming. Verified against a kind
cluster running external-snapshotter v8.6.0 and csi-driver-host-path:
applying this file and creating a VolumeGroupSnapshot that selects two
labelled PVCs reaches readyToUse with both member snapshots ready.
Nothing applies this file yet. It is a prerequisite for the
VolumeGroupSnapshot specs tracked in #7507, kept separate so the class
can be reviewed on its own.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10582
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add e2e test for namespace selection by label in resource policy
Covers design step 8 of #9772: a backup with no explicit
--include-namespaces (the same shape a Schedule with no
includedNamespaces produces), relying entirely on a ResourcePolicy
ConfigMap's includedNamespacesByLabel to select which namespaces to
back up.
Creates labeled and unlabeled namespaces, backs up with a
ResourcePolicy ConfigMap setting includedNamespacesByLabel, and
verifies only the labeled namespaces are restored - closing the e2e
coverage gap #10275 deferred to velero-io/velero#10564.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Add changelog entry for e2e test PR
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Fix e2e test: create Backup directly, not via CLI's implicit --include-namespaces=*
The kind e2e run showed every unlabeled namespace getting backed up
and restored anyway. velero backup create's --include-namespaces flag
defaults to ["*"] when omitted (pkg/cmd/cli/backup/create.go), so
skipping the flag still sent an *explicit* wildcard - and
mergeNamespacesByLabel deliberately leaves an explicit "*" untouched
rather than narrowing it, so includedNamespacesByLabel never got a
chance to replace anything.
Create the Backup object directly via the controller-runtime client
instead, leaving BackupSpec.IncludedNamespaces genuinely unset - the
only way to exercise the "defaulted empty" narrowing path the CLI's
own default makes unreachable.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* test: use the Kind constant instead of the string literal
test/types.go defines `const Kind = "kind"` and most of the suite compares
against it, but three sites still use the bare string. deletion.go is
inconsistent with itself: the BeforeEach skip uses Kind while the one in
runBackupDeletionTests uses "kind", and its skip message hardcodes the
provider name where the other formats it.
namespace-mapping.go dot-imports test/e2e/test rather than test, so the
constant was not in scope there. Import the test package by name, as
test/e2e/migration/migration.go already does alongside its framework
import, and reference test.Kind.
No behavioural change: the constant's value is the string being replaced.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10524
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
- Replaced Expect().Should() and Expect().ShouldNot() with .To() and .ToNot() across 12 files (Task 1).
- Replaced synchronously evaluated Eventually() with Expect() in server_status_request_controller_test.go (Task 2B).
- Extracted Skip() calls inside lazy callbacks into conditional checks using slices.Contains() in enable_api_group_extentions.go (Task 3).
Signed-off-by: opbot_xd <awasthikrishna23052005@gmail.com>
The make-variable table for additional backup storage location flags
did not match test/Makefile. Align the README entries with the actual
flag names.
Signed-off-by: Pranjal Manhgaye <manhgayepranjal@gmail.com>
Rename apiextentions to apiextensions in the APIExtensions test
describe string. Test behavior is unchanged.
Signed-off-by: Pranjal Manhgaye <manhgayepranjal@gmail.com>
Correct a few spelling mistakes and a flag name typo in the e2e
documentation. No code changes.
Signed-off-by: Pranjal Manhgaye <manhgayepranjal@gmail.com>
Rename the local pvcBulder variable to pvcBuilder in the k8s test
helpers. No behavior change.
Signed-off-by: Pranjal Manhgaye <manhgayepranjal@gmail.com>
* refactor: use k8s.io/api well-known label constants
Several well-known Kubernetes label strings were hardcoded across the
codebase instead of using the constants already exported by
k8s.io/api/core/v1, which is an existing dependency:
"kubernetes.io/hostname" -> corev1api.LabelHostname
"kubernetes.io/os" -> corev1api.LabelOSStable
"topology.kubernetes.io/zone" -> corev1api.LabelTopologyZone
The local kube.NodeOSLabel and zoneLabel consts, which duplicated the
upstream values verbatim, are now defined in terms of the upstream
constants rather than repeating the literal. Both are kept: NodeOSLabel
is exported and referenced from four packages alongside NodeOSLinux and
NodeOSWindows, which have no upstream equivalent, and zoneLabel sits
beside the deprecated-label fallback it is compared against.
No functional change - every replacement is a constant with an identical
value.
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
* Add changelog for #10279
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
* Cover the selected-node path in createRestorePod
TestCreateRestorePod only exercised selectedNode == "", so the branch
that pins the restore pod to a node was never executed. Add a case with
a selected node and assert the resulting pod carries the hostname label
in its node selector.
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
* Also use constants for the arch and deprecated zone labels
Extends the same replacement to the two remaining well-known labels
raised on the issue:
"kubernetes.io/arch" -> corev1api.LabelArchStable
"failure-domain.beta.kubernetes.io/zone" -> corev1api.LabelFailureDomainBetaZone
zoneLabelDeprecated in item_backupper.go was the last local const still
repeating a literal that upstream already exports, so the zone pair now
reads consistently against k8s.io/api. The deprecation note upstream
applies to the label itself, not the constant; Velero reads that label
deliberately as the fallback for PVs created before the topology labels
existed.
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
---------
Signed-off-by: Harshit saini <harshitsaini1188@gmail.com>
BeforeSuite applies testdata/volume-snapshot-class/<provider>.yaml when
CSI is enabled, and there is no kind.yaml, so the suite fails before any
spec runs and none of the existing CSI tests can run on kind.
This adds a class for csi-driver-host-path. The driver ships its own, but
it lacks the velero.io/csi-volumesnapshot-class label so Velero never
selects it. Nothing sets FEATURES=EnableCSI for kind yet, so no test that
runs today is affected.
Signed-off-by: Sairam Bisoyi <sairamb2007.21@gmail.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>
Change errors.Cause to errors.Is, because github.com/cockroachdb/errors
New() function create a error with error stack with depth 1, but
github.com/pkg/errors's New() function create error with no depth.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
* Remove Restic references from E2E tests and CI workflows
Rename all Restic-labeled tests to FSBackup since they test the file
system backup path, not Restic specifically. Remove dead Restic code
including VeleroUpgrade, UpdateVeleroDeployment, UpdateNodeAgent,
IsSupportUploaderType, UseResticIfFSBackup, and UploaderTypeRestic —
the server now rejects Restic as an unsupported uploader type.
Fixes#9482
Signed-off-by: Joseph <jvaikath@redhat.com>
* Add changelog for PR #9867
Signed-off-by: Joseph <jvaikath@redhat.com>
---------
Signed-off-by: Joseph <jvaikath@redhat.com>
From 1.18.1, Velero adds some default affinity in the backup/restore pod,
so we can't directly compare the whole affinity,
but we can verify if the expected affinity is contained in the pod affinity.
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
KrishhnaTandGitHub
Chlins ZhangandGitHub
Daniel JiangandGitHub
Xun Jiang/Bruce JiangandGitHub
opbot_xd
Pranjal Manhgaye
harshit sainiandGitHub
Sairam BisoyiandGitHub
Xun Jiang
Joseph Antony VaikathandGitHub
Wenkai Yin(尹文开)andGitHub
lyndon-liandGitHub
dongqingcc