* Add Dependabot docker updates for run-jammy-tiny on supported release branches
The runtime base image is pinned on each release branch and was only
bumped by hand during CVE patch releases, so it goes stale between
releases (release-1.18 pinned 0.2.177, release-1.17 pins 0.2.90).
Add docker ecosystem entries targeting the supported release branches
(the current minor and N-1), limited to the paketobuildpacks/run-jammy-tiny
image and to patch updates.
Dependabot cannot compute target-branch, so add
hack/update-dependabot-release-branches.sh, which regenerates those
entries from the two newest minors with a GA vX.Y.0 tag, and a workflow
that runs it when a release is published (plus weekly and on demand) and
opens a pull request if dependabot.yml changed. Pre-release tags do not
count, so release-1.19 is only picked up once 1.19.0 is out.
Related to https://github.com/velero-io/velero/issues/10681
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Address review feedback on Dependabot release-branch automation
- Replace head with sed in the tag pipeline: with pipefail set, head
closing early can SIGPIPE the upstream sort and fail the script.
- Allow minor version updates for the runtime base image (only
semver-major stays ignored), per Paketo's stack bump policy:
minors are maintainer-selected feature additions that should
surface as PRs for review. Regenerated dependabot.yml.
- Update development.md wording to match (patch or minor).
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* Scope Dependabot automation workflow commit to dependabot.yml
Commit only .github/dependabot.yml instead of all modified files when the automation workflow pushes its branch.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
* fix(tilt): make the dev setup work on a clean checkout and on arm64
Following tilt.md from a clean checkout failed during Tiltfile load:
Error in default_registry: validating defaultRegistry: host: Required value
The docs correctly say to leave default_registry empty for a local cluster,
where Tilt loads the image into the cluster and nothing is pushed, but
default_registry("") is rejected. Only call it when a value is set. For the
build, hack/build.sh also refuses an empty REGISTRY; that value is only the
image prefix baked into the binary, so fall back to the stock one.
Working past that, both binary builds failed with "GOBIN: unbound variable",
which hack/build.sh has required since b1d95cf2a. Pass it.
Everything was also hardcoded to amd64 -- the three binary builds, the
downloaded kubectl helper, the runtime base image, and both docker_build
calls -- so the setup was broken on an arm64 host. Resolve cluster_goarch
once, from an explicit setting, then what `kubectl get nodes` reports, then
the local architecture, and use it throughout. The local CLI build follows
the host instead, since it is meant to be run there.
The provider path deliberately does not get GOBIN: released plugins ship
their own hack/build.sh, which builds ${PKG}/${BIN} and does not require it.
Only its amd64 assumptions change here.
Finally, pin the Delve version. @latest meant the debugger could change
between rebuilds with no change to the checkout.
Verified: Tiltfile loads with an empty and a non-empty registry, with debug
on and off, continue-on-start on and off, and with an explicit
cluster_goarch override; the generated Dockerfiles carry the right arch,
dlv pin, kubectl and docker CLI URLs; the provider path was exercised
against velero-plugin-for-aws; and hack/build.sh produced an aarch64 binary
when GOARCH=arm64.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* docs(tilt): correct the settings reference and the examples
The settings example is not valid JSON: a trailing comma follows the azure
entry, so copying it gives a parse error on the next `tilt up`.
It also enables "csi" in enable_providers while giving it no entry under
providers, so the example advertises a provider it does not define.
provider_repos is documented as a settings field but nothing reads it; the
list of plugins to load is providers. Replace it with cluster_goarch, which
the Tiltfile does read, and say what an empty default_registry means, since
leaving it empty is what a local cluster wants.
The Tilt version floor moves to v0.30.0, the first with
docker_build(platform=...), without which the arm64 support does not load.
Drop the Kubernetes v1.16 floor, which no longer means anything here.
The example deployment gets 3Gi when debugging. delve indexes the DWARF of
the unoptimized binary, and against a 512Mi limit the container is killed
before the debugger finishes starting.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* changelog: add an entry for the Tilt dev setup fixes
The filename is keyed to the PR number, which only exists once the PR does.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* fix(tilt): use pullable MinIO images in the dev setup example
The example tilt-settings.json ships "setup-minio": true, and tilt.md tells
contributors that this creates "a running instance of MinIO inside your
cluster", after which they can "create backups/restores and fully operate
Velero". That is no longer reachable: minio/minio:latest and minio/mc:latest
are no longer pullable from Docker Hub, so the MinIO deployment and its setup
Job both sit in ImagePullBackOff and no backup storage location can validate.
$ docker pull minio/minio:latest
Error response from daemon: {"message":"denied: requested access to the
resource is denied"}
The kind e2e workflow already stopped using these images and builds MinIO from
a reviewed bitnami/containers commit instead. Follow the same namespace here
rather than building from source, since this example runs on a contributor's
laptop: the bitnami legacy mirrors are pullable and need no Dockerfile.
bitnami splits the server and client into separate images, so the setup Job's
minio/mc must move to bitnamilegacy/minio-client, which provides mc on PATH.
Verified both images pull, run as non-root against the emptyDir mounts, and
that the Job completes ("Bucket created successfully `velero/velero`"). With
these images the backup storage location reports Available and a backup
completes and lands in the bucket.
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* fix(tilt): extract kubectl where the Dockerfile copies it from
The helper stage unpacks the kubectl tarball without -C, so it lands in the
golang image's WORKDIR (/go) rather than /tmp, but the COPY that follows reads
from /tmp. The build fails with:
checking on sources under ".../tmp/kubernetes/client/bin/kubectl"
Unpack to /tmp, matching the docker CLI download on the next line and the
COPY --from path.
While here, note next to the dlv pin that it has to move with the golang
image: delve refuses a binary built by a newer Go than it understands
("Version of Delve is too old for Go version go1.x.y"), so the pin goes stale
quietly on the next Go bump.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
* fix(tilt): glob the CRDs instead of listing them
The hardcoded list has to be edited whenever a branch adds a CRD, and silently
drops it from the cluster until someone notices. Glob config/crd/*/bases/*.yaml
instead; it resolves to the same 13 files today.
The glob is a local() call, and Tilt refuses local() while the current kube
context might be a production one, so the k8s_yaml() sits after
allow_k8s_contexts() rather than at the top of the file with the other
manifests.
Co-Authored-By: Claude Code <noreply@anthropic.com>
Note: Posted using claude code
Model: rits/deepseek-ai/DeepSeek-V4.1-Flash-1017
Signed-off-by: Joseph <jvaikath@redhat.com>
---------
Signed-off-by: Joseph <jvaikath@redhat.com>
Signed-off-by: Joseph Antony Vaikath <jvaikath@redhat.com>
Co-authored-by: Claude Code <noreply@anthropic.com>
* Update Go dependencies to address main image vulnerabilities
* Bump Go build version to 1.27
* Align Tilt helper image with Go 1.27 trixie
* Align Go tooling with Go 1.27
* Resolve retry deprecation findings from updated staticcheck
* Use explicit retry interval while waiting for target PVC
Signed-off-by: Xun Jiang <xun.jiang@broadcom.com>
* e2e: run the FSBackup backup deletion case on kind under CSI
The Snapshot variant of this case has run in the CSI job since #10658.
Its FSBackup twin is in no matrix row at all, so the backup deletion
path has never been exercised on kind with file system backup.
That exclusion predates file system backup working on kind. #10680
established that it does, once Kibishii's PVs come from the kind-csi
overlay rather than rancher.io/local-path, because isHostPathVolume
stops matching a PV carrying pv.Spec.CSI.
Run on kind with EnableCSI and Kibishii at the commit this workflow
pins:
Backups && Deletion && FSBackup Ran 1 of 70 Specs in 502.394 seconds
Worth being precise about what that shows. The case backs up with
--default-volumes-to-fs-backup, deletes the backup, and verifies it is
gone from object storage. It does not query PodVolumeBackups or verify
restored data, so unlike the cases in #10680 the log does not contain
PVB names. What this run demonstrates is that an FSBackup-flagged backup
completes and deletes cleanly on kind, which is the path the case is
about.
The row selects only this one case; Backups && Deletion && Snapshot
keeps its own row.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10764
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
This commit refines the "For maintainers" page on the website.
It fixes the link to the GOVERNANCE.md
It removes the helm chart from the repositories to be consistent with
the GOVERNANCE.md
It clarify the process of reviewer assignment
Signed-off-by: Daniel Jiang <daniel.jiang@broadcom.com>
Dependabot security updates are not covered by version-update groups, so each
vulnerable dependency opens its own PR. Add a group with
applies-to: security-updates to both gomod entries so they arrive as a single
PR per module.
Signed-off-by: Tiger Kaovilai <passawit.kaovilai@gmail.com>
Co-authored-by: Claude Code (model: Claude Sonnet 5.5) <noreply@anthropic.com>
* ci: add CodeQL analysis for Go
The Scorecard SAST check scores 0 because the repository only uses
github/codeql-action to upload SARIF from Scorecard and Trivy, and does
not run any static analysis. Add a CodeQL workflow for Go that runs on
pushes and pull requests to main and weekly, with actions pinned by
commit SHA. Skipped on forks.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude Code (model: Claude Sonnet 5.5) <noreply@anthropic.com>
* ci: use autobuild for CodeQL Go analysis
The Go extractor does not support build-mode none. Set up Go from go.mod
and use autobuild.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude Code (model: Claude Sonnet 5.5) <noreply@anthropic.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-authored-by: Claude Code (model: Claude Sonnet 5.5) <noreply@anthropic.com>
Move the resourcemodifiers package from internal/ to pkg/ so that external
plugins, such as Restore Item Action (RIA) plugins, can import and reuse
Velero's built-in resource modifier implementation.
Due to Go's internal package visibility restrictions, external plugins
cannot import packages located under internal/. Relocating resourcemodifiers
to pkg/ allows plugins to evaluate and apply resource modifier rules to
in-memory resource objects prior to validation or restore execution,
ensuring consistent behavior with the Velero server without duplicate code.
Update all internal import paths and add an unreleased changelog entry.
Fixes#10668
Signed-off-by: Adam Zhang <adam.zhang@broadcom.com>
* docs: add data mover memory and upload concurrency tuning guidance
Explain that CPU, memory and upload concurrency are separate settings,
that data mover memory grows with --parallel-files-upload and
--parallel-blocks-upload, and how to tune them for the environment.
Add an example from one environment and link the guidance from the
backup, CSI data movement and fs-backup docs.
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude Code (model: Claude Opus 5.5) <noreply@anthropic.com>
* docs: note network bandwidth as a throughput factor for data mover concurrency
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude Code (model: Claude Opus 5.5) <noreply@anthropic.com>
* docs: explain when raising or lowering data mover concurrency helps
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude Code (model: Claude Opus 5.5) <noreply@anthropic.com>
* docs: add measured bandwidth and parallel-blocks-upload example for data mover tuning
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-Authored-By: Claude Code (model: Claude Opus 5.5) <noreply@anthropic.com>
---------
Signed-off-by: Tiger Kaovilai <tkaovila@redhat.com>
Co-authored-by: Claude Code (model: Claude Opus 5.5) <noreply@anthropic.com>
* e2e: run the BSL deletion snapshot case on kind under CSI
The case was unskipped on kind by #10658 but left out of the matrix,
because nobody had checked whether it worked there. It does.
Run on kind with EnableCSI and Kibishii at the commit this workflow
pins:
BSL && Deletion && Snapshot Ran 1 of 70 Specs in 214.819 seconds
Kibishii installs from kubernetes/yaml/kind-csi, e2e-storage-class comes
from testdata/storage-class/kind-csi.yaml, and the snapshot checkpoint
reports EnableCSI with a real CSI snapshot handle rather than an empty
list, so the case verified a snapshot rather than passing with nothing to
check.
The row selects only the Snapshot variant. BSL && Deletion && FSBackup
is a separate case and stays out, since file system backup through a
deleted BackupStorageLocation has not been run here.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10747
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: add a target that runs the tests on a kind cluster it creates
Running the e2e tests locally means assembling a cluster, an object
store with two buckets, a credentials file, an address the cluster can
reach MinIO on, and a Velero image built and loaded, before any
GINKGO_LABELS is useful. That is a lot of setup to get wrong, and
nothing in the repo does it.
Add hack/run-e2e-kind.sh and a run-e2e-kind target that wraps it. It
creates the cluster, starts MinIO, builds and loads the image, runs the
suite, and removes what it created on the way out, including when the
tests fail or the run is interrupted. FAIL_FAST=true keeps the test bed
and prints how to remove it, as it does for the suite itself.
The cluster's kubeconfig is written to a temporary directory rather than
merged into the caller's, so ~/.kube/config is untouched and the current
context does not change.
The MinIO container is named after the cluster, and the script refuses to
start if that name is already taken rather than removing a container it
did not create. FEATURES=EnableCSI delegates to
hack/install-csi-hostpath.sh.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10652
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: point the kind target's CSI runs at a CSI-backed StorageClass
The target installs csi-driver-host-path when EnableCSI is asked for, but
left the suite's own StorageClass alone. InstallStorageClasses falls back
to testdata/storage-class/<provider>.yaml when --storage-class-file is
not given, and the kind one provisions with rancher.io/local-path, so the
run installed a snapshot-capable driver and then created
e2e-storage-class on a provisioner that cannot snapshot. The example in
the script's own header could not have worked.
Pass kind-csi.yaml for a CSI run, which is the file the CSI job in CI
already uses. Non-CSI runs pass an empty value, which is what the
Makefile defaults to, so they are unchanged.
While here, match FEATURES as the comma-separated list the flag accepts
rather than comparing the whole value, so EnableCSI,EnableAPIGroupVersions
still installs the driver. Same reasoning as the Go side in #10661.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: fix five faults in the kind runner found in review
Teardown deleted the cluster whether or not this run created it. The EXIT
trap is installed before the cluster exists, so an early exit, including
the check that refuses an existing MinIO container, removed a cluster
named velero-e2e that belonged to someone else. The script already
refused to remove a MinIO container it did not create, after an earlier
version deleted one that was in use; the cluster needed the same rule and
did not have it. It now refuses a cluster name that is taken and tracks
whether it created one.
MinIO was started with "server /data", which replaces the entrypoint. CI
passes no command and relies on the image starting the server itself, and
the bitnami image this script tells the user to build runs as UID 1001
and cannot create a data directory at the filesystem root, so the
recommended image could not come up. The command is now empty by default,
with MINIO_ARGS for an image that needs one, such as upstream
minio/minio, and the readiness failure says so.
The image name was taken with ${VELERO_IMAGE%%:*}, which strips from the
first colon, so localhost:5000/velero:e2e-local became "localhost" and
the load asked for a tag that was never built. Strip only the final tag.
The loaded tag was hardcoded to -linux-amd64, but the container target
appends the platform from go env when BUILD_OUTPUT_TYPE is docker, so an
arm64 workstation built -linux-arm64 and the load failed before any test
ran. Resolve the platform once and use it for both the load and the
suite.
Finally, the resolved tag was handed to the inner make through the
environment. A command-line assignment to the outer make propagates
through MAKEFLAGS and outranks the environment, so
"make -C test run-e2e-kind VELERO_IMAGE=velero:custom" ran the suite
against velero:custom while the script had loaded
velero:custom-linux-amd64. Pass it as an argument instead.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: take only the architecture from go env, the image OS is always linux
The container target fixes ALL_OS to linux when BUILD_OUTPUT_TYPE is
docker and takes only the architecture from go env, so the tag it
produces ends in -linux-<arch> on every host. Deriving the OS from
go env GOOS instead meant a Darwin workstation computed
-darwin-<arch> and tried to load a tag that was never built, which
matters because a Darwin host still needs a Linux image to load into
kind.
Suggested in review.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: finish converting the CSI feature checks to FeatureEnabled
#10661 routed every check for EnableCSI through FeatureEnabled, which
splits the comma-separated --features value instead of comparing the
whole thing. One site was left on strings.EqualFold, because #10658
introduced it after #10661 had branched and the rebase applied cleanly
without noticing.
The result is that KibishiiVolumesAreHostPath and the Kind branch of
installKibishii, which are inverses of each other and sit twenty-odd
lines apart with comments saying so, disagree whenever a second feature
is enabled. With --features=EnableCSI,EnableAPIGroupVersions on kind the
mapping swaps in the CSI-backed overlay and the predicate still reports
the volumes as hostPath, so the five cases install a cluster they can
snapshot and then skip.
Convert the last site and test the predicate against the list, case and
single-feature shapes, which fails on the list cases before the change.
The test would not have run in CI either: hack/test.sh listed ./test but
not the other unit-testable packages under test/, so the two existing
tests in this package and the five in test/pkg/client and
test/util/velero were never executed. List all four. The e2e and perf
suites stay out, since they call RunSpecs and need a cluster.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10678
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* e2e: run the Kibishii file system backup cases on kind under CSI
The two Basic FSBackup cases were unskipped on kind by #10658 but left
out of the matrix, because whether a PodVolumeBackup would pick up
Kibishii's volumes on a CSI-backed class had not been checked. It does.
isHostPathVolume in pkg/podvolume/backupper.go matches pv.Spec.HostPath,
and the kind-csi overlay provisions through hostpath.csi.k8s.io, so the
PV carries pv.Spec.CSI and the check stops matching. The driver's name
has nothing to do with the field, which is what made this worth running
rather than reasoning about.
Both cases pass on kind with EnableCSI, with a PodVolumeBackup per
Kibishii PVC rather than volumes skipped:
Basic && FSBackup && !RetainPV Ran 2 of 70 Specs in 529.790 seconds
Basic && FSBackup && RetainPV Ran 1 of 70 Specs in 303.670 seconds
The second resolves overlays/sc-reclaim-policy/kind-csi, so the reclaim
overlay is exercised on the file system backup path too.
The row is Basic && FSBackup, which selects exactly those two cases and
nothing else.
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
* Add changelog for #10680
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
---------
Signed-off-by: krishhna24 <krishhnatupedev@gmail.com>
dependabot[bot]
Xun Jiang/Bruce Jiang
lyndon-li
Tiger Kaovilai
Joseph Antony VaikathandClaude Code
Lyndon-Li
KrishhnaT
Daniel Jiang
Adam Zhang