mirrors/velero
1
0
Fork 0
mirror of https://github.com/vmware-tanzu/velero.git synced 2026-08-16 04:06:06 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'main' into pvr-restorer-could-run-concurrently

Browse Source
This commit is contained in:
Lyndon-Li
2026-08-12 22:44:22 +08:00
parent d5089e621f 550bec10ed
commit 158f403d34
333 changed files with 16999 additions and 4618 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/CODEOWNERS
+2
View File
@@ -0,0 +1,2 @@
# maintainers are the overall code owners
* @velero-io/Maintainer
.github/copilot-instructions.md
+70
View File
@@ -0,0 +1,70 @@
# GitHub Copilot instructions for velero-io/velero
## Changelog requirement
Velero uses per-PR changelog fragments that are assembled into release notes.
### File naming convention
Every shipping PR must add exactly **one** file at:
```
changelogs/unreleased/<PR_NUMBER>-<github_username>
```
- `<PR_NUMBER>` is the pull request number (e.g. `10200`).
- `<github_username>` is the GitHub login of the PR author (e.g. `jdoe`).
- The file has **no extension**.
- The file content is a single line describing the change (the PR title is a
sensible default).
**Example:** PR #10200 by `jdoe` → `changelogs/unreleased/10200-jdoe`
The easiest way to create this file is:
```bash
make new-changelog CHANGELOG_BODY="Brief description of the change"
```
`make new-changelog` reads the PR number and author from `gh pr view`; the file
is written automatically to the correct path with the correct name.
The CI check (`hack/changelog-check.sh`) looks for
`changelogs/unreleased/<PR_NUMBER>-*` and fails if no file is found.
### When a changelog is NOT required
A changelog entry is **not** required when a PR exclusively changes non-shipping
content, i.e. the only files touched belong to one or more of these categories:
| Category | Paths |
|---|---|
| GitHub Actions / CI workflows | `.github/**` |
| Documentation | `site/content/docs/**`, `site/**`, `docs/**`, `*.md` |
| Website (non-docs) | `site/**` (excluding `site/content/docs/**`) |
When you open or review a PR that falls into one of the above categories (and does
**not** modify `pkg/`, `internal/`, `cmd/`, `vendor/`, `hack/`, `Makefile`,
`go.mod`, `go.sum`, or `changelogs/**`), apply the label
**`kind/changelog-not-required`** instead of requesting a changelog entry. The
`labeler.yml` auto-labeler handles this automatically for most cases; apply the
label manually if the auto-labeler did not.
## Backport / cherry-pick workflow
Velero uses `.github/workflows/backport.yml` to automate cherry-picks onto release
branches.
- **Before merge:** comment `/backport release-1.17` (or `/cherrypick release-1.17`)
to add the label `backport release-1.17` to the PR. Multiple branches can be
space-delimited: `/backport release-1.17 release-1.18`. The label causes the
backport to run automatically when the PR merges.
- **After merge:** the same comment immediately creates the backport PR.
- Only repository **owners, members, and collaborators** may trigger these commands.
## General coding guidelines
- Follow the existing code style of the file being edited.
- Add unit tests for new exported functions in `pkg/`.
- Do not commit secrets, credentials, or API tokens.
- Keep PRs focused; prefer small, reviewable changes over large omnibus PRs.
.github/dependabot.yml
+18
View File
@@ -5,6 +5,10 @@ updates:
directory: "/"
schedule:
interval: "weekly"
groups:
github-actions:
patterns:
- "*"
labels:
- "Dependencies"
- "github_actions"
@@ -15,6 +19,20 @@ updates:
schedule:
interval: "weekly"
labels:
- "Dependencies"
- "go"
- "kind/changelog-not-required"
ignore:
- dependency-name: "*"
update-types: ["version-update:semver-major", "version-update:semver-minor", "version-update:semver-patch"]
# Dependencies listed in pkg/apis/go.mod
- package-ecosystem: "gomod"
directory: "/pkg/apis" # Location of package manifests
schedule:
interval: "weekly"
labels:
- "Dependencies"
- "go"
- "kind/changelog-not-required"
ignore:
- dependency-name: "*"
.github/labeler.yml
+22
View File
@@ -31,3 +31,25 @@ has-e2e-2tests:
has-unit-tests:
- changed-files:
- any-glob-to-any-file: pkg/**/*_test.go
# PRs that only touch non-shipping files (.github/ config, workflows, or docs)
# do not need a changelog entry; auto-apply the label so the changelog check passes.
kind/changelog-not-required:
- all:
- changed-files:
- any-glob-to-any-file:
- .github/**/*
- site/content/docs/**/*
- site/**/*
- '*.md'
- docs/**/*
- all-globs-to-all-files:
- '!pkg/**'
- '!internal/**'
- '!cmd/**'
- '!vendor/**'
- '!hack/**'
- '!Makefile'
- '!go.mod'
- '!go.sum'
- '!changelogs/**'
- '!**/*.go'
.github/workflows/auto_assign_prs.yml
+68 -1
View File
@@ -6,6 +6,10 @@ name: "Auto Assign Author"
on:
pull_request_target:
types: [opened, reopened, ready_for_review]
# Watch for submitted reviews so we can re-request a second CODEOWNERS
# review once only one maintainer has approved.
pull_request_review:
types: [submitted]
permissions:
contents: read
@@ -14,9 +18,72 @@ permissions:
jobs:
# Automatically assigns reviewers and owner
add-reviews:
if: github.repository == 'velero-io/velero' && github.event_name == 'pull_request_target'
runs-on: ubuntu-latest
steps:
- name: Set the author of a PR as the assignee
uses: kentaro-m/auto-assign-action@v2.0.0
uses: kentaro-m/auto-assign-action@v2.0.2
with:
configuration-path: ".github/auto-assignees.yml"
# `.github/CODEOWNERS` automatically requests review from the
# velero-io/maintainer team, but that request is cleared as soon as a
# single member of the team submits a review. Since we require a minimum
# of 2 reviewers (see `number_of_reviewers` in auto-assignees.yml), this
# re-requests a review from the maintainer team whenever a PR still has
# fewer than the required number of approvals, so a second CODEOWNERS
# reviewer gets pinged.
re-request-review:
if: github.repository == 'velero-io/velero' && github.event_name == 'pull_request_review' && github.event.review.state == 'approved'
runs-on: ubuntu-latest
steps:
- name: Re-request review from maintainers if more approvals are needed
uses: actions/github-script@v7
with:
script: |
const requiredApprovals = 2;
const maintainerTeam = 'maintainer';
const { owner, repo } = context.repo;
const pull_number = context.payload.pull_request.number;
const { data: reviews } = await github.rest.pulls.listReviews({
owner,
repo,
pull_number,
});
// Count distinct users whose most recent review is an approval.
// The Reviews API does not guarantee chronological order, so
// sort by submission time before folding into the map.
const sortedReviews = [...reviews].sort(
(a, b) => new Date(a.submitted_at) - new Date(b.submitted_at)
);
const latestReviewByUser = new Map();
for (const review of sortedReviews) {
latestReviewByUser.set(review.user.login, review.state);
}
const approvedReviewers = [...latestReviewByUser.entries()].filter(
([, state]) => state === 'APPROVED'
);
if (approvedReviewers.length >= requiredApprovals) {
console.log(
`PR already has ${approvedReviewers.length} approvals, no need to re-request review.`
);
return;
}
console.log(
`PR has ${approvedReviewers.length}/${requiredApprovals} approvals, re-requesting review from @${owner}/${maintainerTeam}.`
);
try {
await github.rest.pulls.requestReviewers({
owner,
repo,
pull_number,
team_reviewers: [maintainerTeam],
});
} catch (error) {
core.warning(`Failed to re-request review from maintainers: ${error.message}`);
}
.github/workflows/auto_label_prs.yml
+2 -1
View File
@@ -15,8 +15,9 @@ permissions:
jobs:
# Automatically labels PRs based on file globs in the change.
triage:
if: github.repository == 'velero-io/velero'
runs-on: ubuntu-latest
steps:
- uses: actions/labeler@v5
- uses: actions/labeler@v7
with:
configuration-path: .github/labeler.yml
.github/workflows/auto_request_review.yml
-21
View File
@@ -1,21 +0,0 @@
---
name: "Auto Request Review"
on:
pull_request_target:
types: [opened, ready_for_review, reopened]
permissions:
contents: read
pull-requests: write
jobs:
auto-request-review:
name: Auto Request Review
runs-on: ubuntu-latest
steps:
- name: Request a PR review based on files types/paths, and/or groups the author belongs to
uses: necojackarc/auto-request-review@v0.13.0
with:
config: .github/auto-assignees.yml
token: ${{ secrets.GITHUB_TOKEN }}
.github/workflows/backport.yml
+163
View File
@@ -0,0 +1,163 @@
name: Backport merged pull request
# Automates cherry-picking merged PRs onto release branches.
#
# Pre-merge (open PR):
# An authorized /backport or /cherrypick comment adds one `backport <branch>`
# label per requested branch. These labels are then picked up automatically
# when the PR is merged (see the pull_request_target: closed trigger below).
#
# Post-merge (merged PR):
# - Label a PR with e.g. `backport release-1.17` before merging; the label
# triggers the backport automatically when the PR closes as merged.
# - Comment `/backport release-1.17` or `/cherrypick release-1.17` on an
# already-merged PR to create the backport PR immediately.
#
# In both cases multiple target branches can be space-delimited in a comment:
# /backport release-1.17 release-1.18
#
# See: https://github.com/velero-io/velero/issues/9603
on:
pull_request_target:
types: [closed]
issue_comment:
types: [created]
permissions: {}
# Shared condition for authorized /backport or /cherrypick comments.
# Used by both jobs below to avoid duplicating the gate logic.
env:
AUTHORIZED_COMMENT: >-
${{
github.event_name == 'issue_comment' &&
github.event.issue.pull_request != '' &&
github.event.comment.user.id != 97796249 &&
contains(
fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'),
github.event.comment.author_association
) &&
(
startsWith(github.event.comment.body, '/backport') ||
startsWith(github.event.comment.body, '/cherrypick')
)
}}
jobs:
# ── Pre-merge: convert a /backport or /cherrypick comment into labels ───────
# When the PR is still open the backport-action cannot run (it requires a
# merged commit). Instead, add one `backport <branch>` label per requested
# branch so that the post-merge job picks them up automatically on close.
label-for-backport:
name: Label PR for deferred backport
# Run only when an authorized command is posted on an *open* (unmerged) PR.
if: >
github.repository == 'velero-io/velero' &&
github.event_name == 'issue_comment' &&
github.event.issue.pull_request != '' &&
github.event.issue.state == 'open' &&
github.event.comment.user.id != 97796249 &&
contains(
fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'),
github.event.comment.author_association
) &&
(
startsWith(github.event.comment.body, '/backport') ||
startsWith(github.event.comment.body, '/cherrypick')
)
runs-on: ubuntu-latest
permissions:
issues: write # apply labels to the PR (PRs share the issues API)
steps:
- name: Parse branches and apply labels
env:
COMMENT_BODY: ${{ github.event.comment.body }}
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
REPO: ${{ github.repository }}
PR_NUMBER: ${{ github.event.issue.number }}
run: |
# Extract branch names from the first line of the comment.
# Strip the /backport or /cherrypick prefix; what remains is a
# space-delimited list of target branch names.
line=$(printf '%s' "$COMMENT_BODY" | head -n1 | tr -d '\r')
branches=$(printf '%s' "$line" | sed -E 's#^/(backport|cherrypick)[[:space:]]*##')
if [ -z "$branches" ]; then
echo "No target branches specified in comment; nothing to label."
exit 0
fi
for branch in $branches; do
label="backport ${branch}"
echo "Applying label: '${label}'"
# Create the label if it does not exist yet (idempotent).
gh label create "${label}" --repo "${REPO}" --color "0075ca" \
--description "Backport to ${branch}" 2>/dev/null || true
gh issue edit "${PR_NUMBER}" --repo "${REPO}" --add-label "${label}"
done
# ── Post-merge: create backport PRs ─────────────────────────────────────────
backport:
name: Backport pull request
# Exclude comments from the backport-action bot (user id 97796249) to prevent
# recursive triggers. The bot does not post /backport commands, so startsWith
# already blocks recursion; the id check is defense in depth.
if: >
github.repository == 'velero-io/velero' &&
(
(
github.event_name == 'pull_request_target' &&
github.event.pull_request.merged &&
contains(toJSON(github.event.pull_request.labels.*.name), '"backport ')
) || (
github.event_name == 'issue_comment' &&
github.event.issue.pull_request != '' &&
github.event.issue.state == 'closed' &&
github.event.comment.user.id != 97796249 &&
contains(
fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'),
github.event.comment.author_association
) &&
(
startsWith(github.event.comment.body, '/backport') ||
startsWith(github.event.comment.body, '/cherrypick')
)
)
)
runs-on: ubuntu-latest
permissions:
contents: write # push backport branches and comment
pull-requests: write # open backport PRs
steps:
- name: Parse target branches from comment
id: parse
if: github.event_name == 'issue_comment'
env:
COMMENT_BODY: ${{ github.event.comment.body }}
run: |
# First line only; strip /backport or /cherrypick prefix.
# Remaining text is a space-delimited list of target branches
# (may be empty, falls back to labels).
line=$(printf '%s' "$COMMENT_BODY" | head -n1 | tr -d '\r')
branches=$(printf '%s' "$line" | sed -E 's#^/(backport|cherrypick)[[:space:]]*##')
echo "branches=${branches}" >> "$GITHUB_OUTPUT"
- uses: actions/checkout@v7
with:
fetch-depth: 0
- name: Create backport pull requests
# Pin to commit SHA: workflow has contents/pull-requests write.
uses: korthout/backport-action@2e830a1d0b8269505846ddd407a70876913ad1f8 # v4.6.0
with:
# Labels like `backport release-1.17` select the target branch.
label_pattern: '^backport ([^ ]+)$'
# Prefer draft PRs with conflict markers over failing the job silently.
experimental: |
{
"conflict_resolution": "draft_commit_conflicts"
}
# Empty when triggered by merge labels; set when `/backport` or `/cherrypick` includes branches.
target_branches: ${{ steps.parse.outputs.branches }}
github_token: ${{ secrets.GITHUB_TOKEN }}
.github/workflows/e2e-test-kind.yaml
+26 -18
View File
@@ -1,6 +1,14 @@
name: "Run the E2E test on kind"
permissions:
contents: read
env:
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
# Reviewed commit pins for third-party sources this workflow clones and executes.
# Bump them deliberately after reviewing the upstream changes.
# bitnami/containers: [bitnami/minio] Release 2026.7.17-debian-12-r0
BITNAMI_CONTAINERS_COMMIT: 19fb570e551f15ab0c8264aafa93774266761b8d
# vmware-tanzu-experiments/distributed-data-generator: main as of 2025-07-15
KIBISHII_COMMIT: bce0469e5f9dd33f31432fab22ff90ad6f2b45ca
on:
push:
pull_request:
@@ -19,14 +27,12 @@ jobs:
build:
runs-on: ubuntu-latest
needs: get-go-version
outputs:
minio-dockerfile-sha: ${{ steps.minio-version.outputs.dockerfile_sha }}
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Set up Go version
uses: actions/setup-go@v6
uses: actions/setup-go@v7
with:
go-version: ${{ needs.get-go-version.outputs.version }}
@@ -56,23 +62,22 @@ jobs:
run: |
IMAGE=velero VERSION=pr-test BUILD_OUTPUT_TYPE=docker make container
docker save velero:pr-test-linux-amd64 -o ./velero.tar
# Check and build MinIO image once for all e2e tests
- name: Check Bitnami MinIO Dockerfile version
id: minio-version
run: |
DOCKERFILE_SHA=$(curl -s https://api.github.com/repos/bitnami/containers/commits?path=bitnami/minio/2026/debian-12/Dockerfile\&per_page=1 | jq -r '.[0].sha')
echo "dockerfile_sha=${DOCKERFILE_SHA}" >> $GITHUB_OUTPUT
# Build the MinIO image once for all e2e tests, from the reviewed bitnami/containers commit.
- name: Cache MinIO Image
uses: actions/cache@v4
id: minio-cache
with:
path: ./minio-image.tar
key: minio-bitnami-${{ steps.minio-version.outputs.dockerfile_sha }}
key: minio-bitnami-${{ env.BITNAMI_CONTAINERS_COMMIT }}
- name: Build MinIO Image from Bitnami Dockerfile
if: steps.minio-cache.outputs.cache-hit != 'true'
run: |
echo "Building MinIO image from Bitnami Dockerfile..."
git clone --depth 1 https://github.com/bitnami/containers.git /tmp/bitnami-containers
set -euo pipefail
echo "Building MinIO image from Bitnami Dockerfile at ${BITNAMI_CONTAINERS_COMMIT}..."
git init -q /tmp/bitnami-containers
git -C /tmp/bitnami-containers remote add origin https://github.com/bitnami/containers.git
git -C /tmp/bitnami-containers fetch --depth 1 origin "${BITNAMI_CONTAINERS_COMMIT}"
git -C /tmp/bitnami-containers checkout -q "${BITNAMI_CONTAINERS_COMMIT}"
cd /tmp/bitnami-containers/bitnami/minio/2026/debian-12
docker build -t bitnami/minio:local .
docker save bitnami/minio:local > ${{ github.workspace }}/minio-image.tar
@@ -114,10 +119,10 @@ jobs:
fail-fast: false
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Set up Go version
uses: actions/setup-go@v6
uses: actions/setup-go@v7
with:
go-version: ${{ needs.get-go-version.outputs.version }}
@@ -127,7 +132,7 @@ jobs:
id: minio-cache
with:
path: ./minio-image.tar
key: minio-bitnami-${{ needs.build.outputs.minio-dockerfile-sha }}
key: minio-bitnami-${{ env.BITNAMI_CONTAINERS_COMMIT }}
- name: Load MinIO Image
run: |
echo "Loading MinIO image..."
@@ -167,7 +172,10 @@ jobs:
curl -LO https://dl.k8s.io/release/v${{ matrix.k8s }}/bin/linux/amd64/kubectl
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
git clone https://github.com/vmware-tanzu-experiments/distributed-data-generator.git -b main /tmp/kibishii
git init -q /tmp/kibishii
git -C /tmp/kibishii remote add origin https://github.com/vmware-tanzu-experiments/distributed-data-generator.git
git -C /tmp/kibishii fetch --depth 1 origin "${KIBISHII_COMMIT}"
git -C /tmp/kibishii checkout -q "${KIBISHII_COMMIT}"
GOPATH=~/go \
CLOUD_PROVIDER=kind \
@@ -187,7 +195,7 @@ jobs:
timeout-minutes: 30
- name: Upload debug bundle
if: ${{ failure() }}
uses: actions/upload-artifact@v5
uses: actions/upload-artifact@v7
with:
name: DebugBundle-k8s-${{ matrix.k8s }}-job-${{ strategy.job-index }}
path: /home/runner/work/velero/velero/test/e2e/debug-bundle*
.github/workflows/get-go-version.yaml
+1 -1
View File
@@ -17,7 +17,7 @@ jobs:
version: ${{ steps.pick-version.outputs.version }}
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- id: pick-version
run: |
.github/workflows/nightly-trivy-scan.yml
+3 -3
View File
@@ -19,10 +19,10 @@ jobs:
steps:
- name: Checkout code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@57a97c7e7821a5776cebc9bb87c984fa69cba8f1
uses: aquasecurity/trivy-action@ed142fd0673e97e23eac54620cfb913e5ce36c25
with:
image-ref: 'docker.io/velero/${{ matrix.images }}:${{ matrix.versions }}'
severity: 'CRITICAL,HIGH,MEDIUM'
@@ -31,6 +31,6 @@ jobs:
output: 'trivy-results.sarif'
- name: Upload Trivy scan results to GitHub Security tab
uses: github/codeql-action/upload-sarif@v3
uses: github/codeql-action/upload-sarif@v4.37.6
with:
sarif_file: 'trivy-results.sarif'
.github/workflows/pr-changelog-check.yml
+2 -1
View File
@@ -7,12 +7,13 @@ on:
jobs:
build:
if: github.repository == 'velero-io/velero'
name: Run Changelog Check
runs-on: ubuntu-latest
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Changelog check
if: ${{ !(contains(github.event.pull_request.labels.*.name, 'kind/changelog-not-required') || contains(github.event.pull_request.labels.*.name, 'Design') || contains(github.event.pull_request.labels.*.name, 'Website') || contains(github.event.pull_request.labels.*.name, 'Documentation'))}}
.github/workflows/pr-ci-check.yml
+3 -3
View File
@@ -14,17 +14,17 @@ jobs:
fail-fast: false
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Set up Go version
uses: actions/setup-go@v6
uses: actions/setup-go@v7
with:
go-version: ${{ needs.get-go-version.outputs.version }}
- name: Make ci
run: make ci
- name: Upload test coverage
uses: codecov/codecov-action@v6
uses: codecov/codecov-action@v7
with:
token: ${{ secrets.CODECOV_TOKEN }}
files: coverage.out
.github/workflows/pr-codespell.yml
+2 -1
View File
@@ -3,12 +3,13 @@ on: [pull_request]
jobs:
codespell:
if: github.repository == 'velero-io/velero'
name: Run Codespell
runs-on: ubuntu-latest
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Codespell
uses: codespell-project/actions-codespell@master
.github/workflows/pr-containers.yml
+3 -3
View File
@@ -14,18 +14,18 @@ jobs:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/checkout@v7
name: Checkout
- name: Set up QEMU
id: qemu
uses: docker/setup-qemu-action@v3
uses: docker/setup-qemu-action@v4
with:
platforms: all
- name: Set up Docker Buildx
id: buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@v4
with:
version: latest
.github/workflows/pr-filepath-check.yml
+2 -1
View File
@@ -3,12 +3,13 @@ on: [pull_request]
jobs:
filepath-check:
if: github.repository == 'velero-io/velero'
name: Check for invalid characters in file paths
runs-on: ubuntu-latest
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Validate file paths for Go module compatibility
run: |
.github/workflows/pr-goreleaser.yml
+1 -1
View File
@@ -14,7 +14,7 @@ jobs:
name: Build
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/checkout@v7
name: Checkout
- name: Verify .goreleaser.yml and try a dryrun release.
.github/workflows/pr-linter-check.yml
+2 -2
View File
@@ -18,10 +18,10 @@ jobs:
needs: get-go-version
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@v7
- name: Set up Go version
uses: actions/setup-go@v6
uses: actions/setup-go@v7
with:
go-version: ${{ needs.get-go-version.outputs.version }}
.github/workflows/prow-action.yml
+2 -1
View File
@@ -11,9 +11,10 @@ permissions:
jobs:
execute:
if: github.repository == 'velero-io/velero'
runs-on: ubuntu-latest
steps:
- uses: jpmcb/prow-github-actions@v1.1.3
- uses: jpmcb/prow-github-actions@f4d01dd4b13f289014c23fe5a19878a2479cb35b # v1.1.3
with:
# TODO: before allowing the /lgtm command, see if we can block merging if changelog labels are missing.
prow-commands: |
.github/workflows/push-builder.yml
+1 -1
View File
@@ -12,7 +12,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/checkout@v7
with:
# The default value is "1" which fetches only a single commit. If we merge PR without squash or rebase,
# there are at least two commits: the first one is the merge commit and the second one is the real commit
.github/workflows/push.yml
+8 -5
View File
@@ -8,6 +8,9 @@ on:
tags:
- '*'
permissions:
contents: read
jobs:
get-go-version:
uses: ./.github/workflows/get-go-version.yaml
@@ -20,21 +23,21 @@ jobs:
needs: get-go-version
steps:
- name: Check out the code
uses: actions/checkout@v6
uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
- name: Set up Go version
uses: actions/setup-go@v6
uses: actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e # v7.0.0
with:
go-version: ${{ needs.get-go-version.outputs.version }}
- name: Set up QEMU
id: qemu
uses: docker/setup-qemu-action@v3
uses: docker/setup-qemu-action@96fe6ef7f33517b61c61be40b68a1882f3264fb8 # v4
with:
platforms: all
- name: Set up Docker Buildx
id: buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@bb05f3f5519dd87d3ba754cc423b652a5edd6d2c # v4.2.0
with:
version: latest
- name: Build
@@ -45,7 +48,7 @@ jobs:
- name: Test
run: make test
- name: Upload test coverage
uses: codecov/codecov-action@v6
uses: codecov/codecov-action@fb8b3582c8e4def4969c97caa2f19720cb33a72f # v7
with:
token: ${{ secrets.CODECOV_TOKEN }}
files: coverage.out
.github/workflows/rebase.yml
+25 -11
View File
@@ -1,18 +1,32 @@
on:
name: Automatic Rebase
on:
issue_comment:
types: [created]
name: Automatic Rebase
permissions: {}
jobs:
rebase:
name: Rebase
if: github.event.issue.pull_request != '' && contains(github.event.comment.body, '/rebase')
if: >-
github.repository == 'velero-io/velero' &&
github.event.issue.pull_request != null &&
github.event.comment.body == '/rebase' &&
contains(
fromJSON('["OWNER", "MEMBER", "COLLABORATOR"]'),
github.event.comment.author_association
)
runs-on: ubuntu-latest
permissions:
# contents: write is required because updating the pull request branch
# pushes commits to the head branch.
contents: write
pull-requests: write
steps:
- name: Checkout the latest code
uses: actions/checkout@v6
with:
fetch-depth: 0
- name: Automatic Rebase
uses: cirrus-actions/rebase@1.8
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- name: Rebase pull request
env:
GH_TOKEN: ${{ github.token }}
GH_REPO: ${{ github.repository }}
PR_NUMBER: ${{ github.event.issue.number }}
run: gh pr update-branch "$PR_NUMBER" --repo "$GH_REPO" --rebase
.github/workflows/stale-issues.yml
+1
View File
@@ -5,6 +5,7 @@ on:
jobs:
stale:
if: github.repository == 'velero-io/velero'
runs-on: ubuntu-latest
steps:
- uses: actions/stale@v10.1.1
CODE_OF_CONDUCT.md
-148
View File
@@ -1,148 +0,0 @@
# Velero Code of Conduct
Velero is a [Cloud Native Computing Foundation](https://www.cncf.io/) sandbox
project. As a CNCF project, the Velero community follows the
[**CNCF Code of Conduct**](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).
The text below is the project's adopted Code of Conduct, based on the
[Contributor Covenant](https://www.contributor-covenant.org/), and is
substantively aligned with the CNCF Code of Conduct. Where any conflict exists,
the CNCF Code of Conduct prevails.
Instances of unacceptable behavior may be reported to the CNCF Code of
Conduct Committee at [conduct@cncf.io](mailto:conduct@cncf.io). For more
detailed instructions on how to submit a report, including how to submit a
report anonymously, please see the CNCF
[Incident Resolution Procedures](https://github.com/cncf/foundation/blob/main/code-of-conduct/coc-incident-resolution-procedures.md).
You can expect a response within three business days.
---
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in the Velero project and our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socioeconomic status,
nationality, personal appearance, race, religion, or sexual identity
and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the
overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or
advances of any kind
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will communicate reasons for moderation
decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the CNCF Code of Conduct Committee at
[conduct@cncf.io](mailto:conduct@cncf.io).
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series
of actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or
permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within
the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
CONTRIBUTING.md
-3
View File
@@ -1,3 +0,0 @@
# Contributing
Authors are expected to follow some guidelines when submitting PRs. Please see [our documentation](https://velero.io/docs/main/code-standards/) for details.
GOVERNANCE.md
-135
View File
@@ -1,135 +0,0 @@
# Velero Governance
This document defines the project governance for Velero.
## Overview
**Velero**, an open source project, is committed to building an open, inclusive, productive and self-governing open source community focused on building a high quality tool that enables users to safely backup and restore, perform disaster recovery, and migrate Kubernetes cluster resources and persistent volumes. The community is governed by this document with the goal of defining how community should work together to achieve this goal.
## Code Repositories
The following code repositories are governed by Velero community and maintained under the `vmware-tanzu\Velero` organization.
* **[Velero](https://github.com/vmware-tanzu/velero):** Main Velero codebase
* **[Helm Chart](https://github.com/vmware-tanzu/helm-charts/tree/main/charts/velero):** The Helm chart for the Velero server component
* **[Velero CSI Plugin](https://github.com/vmware-tanzu/velero-plugin-for-csi):** This repository contains Velero plugins for snapshotting CSI backed PVCs using the CSI beta snapshot APIs
* **[Velero Plugin for vSphere](https://github.com/vmware-tanzu/velero-plugin-for-vsphere):** This repository contains the Velero Plugin for vSphere. This plugin is a volume snapshotter plugin that provides crash-consistent snapshots of vSphere block volumes and backup of volume data into S3 compatible storage.
* **[Velero Plugin for AWS](https://github.com/vmware-tanzu/velero-plugin-for-aws):** This repository contains the plugins to support running Velero on AWS, including the object store plugin and the volume snapshotter plugin
* **[Velero Plugin for GCP](https://github.com/vmware-tanzu/velero-plugin-for-gcp):** This repository contains the plugins to support running Velero on GCP, including the object store plugin and the volume snapshotter plugin
* **[Velero Plugin for Azure](https://github.com/vmware-tanzu/velero-plugin-for-microsoft-azure):** This repository contains the plugins to support running Velero on Azure, including the object store plugin and the volume snapshotter plugin
* **[Velero Plugin Example](https://github.com/vmware-tanzu/velero-plugin-example):** This repository contains example plugins for Velero
## Community Roles
* **Users:** Members that engage with the Velero community via any medium (Slack, GitHub, mailing lists, etc.).
* **Contributors:** Regular contributions to projects (documentation, code reviews, responding to issues, participation in proposal discussions, contributing code, etc.).
* **Maintainers**: The Velero project leaders. They are responsible for the overall health and direction of the project; final reviewers of PRs and responsible for releases. Some Maintainers are responsible for one or more components within a project, acting as technical leads for that component. Maintainers are expected to contribute code and documentation, review PRs including ensuring quality of code, triage issues, proactively fix bugs, and perform maintenance tasks for these components.
### Maintainers
New maintainers must be nominated by an existing maintainer and must be elected by a supermajority of existing maintainers. Likewise, maintainers can be removed by a supermajority of the existing maintainers or can resign by notifying one of the maintainers.
### Supermajority
A supermajority is defined as two-thirds of members in the group.
A supermajority of [Maintainers](#maintainers) is required for certain
decisions as outlined above. A supermajority vote is equivalent to the number of votes in favor being at least twice the number of votes against. For example, if you have 5 maintainers, a supermajority vote is 4 votes. Voting on decisions can happen on the mailing list, GitHub, Slack, email, or via a voting service, when appropriate. Maintainers can either vote "agree, yes, +1", "disagree, no, -1", or "abstain". A vote passes when supermajority is met. An abstain vote equals not voting at all.
### Decision Making
Ideally, all project decisions are resolved by consensus. If impossible, any
maintainer may call a vote. Unless otherwise specified in this document, any
vote will be decided by a supermajority of maintainers.
Votes by maintainers belonging to the same company
will count as one vote; e.g., 4 maintainers employed by fictional company **Valerium** will
only have **one** combined vote. If voting members from a given company do not
agree, the company's vote is determined by a supermajority of voters from that
company. If no supermajority is achieved, the company is considered to have
abstained.
## Proposal Process
One of the most important aspects in any open source community is the concept
of proposals. Large changes to the codebase and / or new features should be
preceded by a proposal in our community repo. This process allows for all
members of the community to weigh in on the concept (including the technical
details), share their comments and ideas, and offer to help. It also ensures
that members are not duplicating work or inadvertently stepping on toes by
making large conflicting changes.
The project roadmap is defined by accepted proposals.
Proposals should cover the high-level objectives, use cases, and technical
recommendations on how to implement. In general, the community member(s)
interested in implementing the proposal should be either deeply engaged in the
proposal process or be an author of the proposal.
The proposal should be documented as a separated markdown file pushed to the root of the
`design` folder in the [Velero](https://github.com/vmware-tanzu/velero/tree/main/design)
repository via PR. The name of the file should follow the name pattern `<short
meaningful words joined by '-'>_design.md`, e.g:
`restore-hooks-design.md`.
Use the [Proposal Template](https://github.com/vmware-tanzu/velero/blob/main/design/_template.md) as a starting point.
### Proposal Lifecycle
The proposal PR can follow the GitHub lifecycle of the PR to indicate its status:
* **Open**: Proposal is created and under review and discussion.
* **Merged**: Proposal has been reviewed and is accepted (either by consensus or through a vote).
* **Closed**: Proposal has been reviewed and was rejected (either by consensus or through a vote).
## Lazy Consensus
To maintain velocity in a project as busy as Velero, the concept of [Lazy
Consensus](http://en.osswiki.info/concepts/lazy_consensus) is practiced. Ideas
and / or proposals should be shared by maintainers via
GitHub with the appropriate maintainer groups (e.g.,
`@vmware-tanzu/velero-maintainers`) tagged. Out of respect for other contributors,
major changes should also be accompanied by a ping on Slack or a note on the
Velero mailing list as appropriate. Author(s) of proposal, Pull Requests,
issues, etc. will give a time period of no less than five (5) working days for
comment and remain cognizant of popular observed world holidays.
Other maintainers may chime in and request additional time for review, but
should remain cognizant of blocking progress and abstain from delaying
progress unless absolutely needed. The expectation is that blocking progress
is accompanied by a guarantee to review and respond to the relevant action(s)
(proposals, PRs, issues, etc.) in short order.
Lazy Consensus is practiced for all projects in the `Velero` org, including
the main project repository and the additional repositories.
Lazy consensus does _not_ apply to the process of:
* Removal of maintainers from Velero
## Deprecation Policy
### Deprecation Process
Any contributor may introduce a request to deprecate a feature or an option of a feature by opening a feature request issue in the vmware-tanzu/velero GitHub project. The issue should describe why the feature is no longer needed or has become detrimental to Velero, as well as whether and how it has been superseded. The submitter should give as much detail as possible.
Once the issue is filed, a one-month discussion period begins. Discussions take place within the issue itself as well as in the community meetings. The person who opens the issue, or a maintainer, should add the date and time marking the end of the discussion period in a comment on the issue as soon as possible after it is opened. A decision on the issue needs to be made within this one-month period.
The feature will be deprecated by a supermajority vote of 50% plus one of the project maintainers at the time of the vote tallying, which is 72 hours after the end of the community meeting that is the end of the comment period. (Maintainers are permitted to vote in advance of the deadline, but should hold their votes until as close as possible to hear all possible discussion.) Votes will be tallied in comments on the issue.
Non-maintainers may add non-binding votes in comments to the issue as well; these are opinions to be taken into consideration by maintainers, but they do not count as votes.
If the vote passes, the deprecation window takes effect in the subsequent release, and the removal follows the schedule.
### Schedule
If depreciation proposal passes by supermajority votes, the feature is deprecated in the next minor release and the feature can be removed completely after two minor version or equivalent major version e.g., if feature gets deprecated in Nth minor version, then feature can be removed after N+2 minor version or its equivalent if the major version number changes.
### Deprecation Window
The deprecation window is the period from the release in which the deprecation takes effect through the release in which the feature is removed. During this period, only critical security vulnerabilities and catastrophic bugs should be fixed.
**Note:** If a backup relies on a deprecated feature, then backups made with the last Velero release before this feature is removed must still be restorable in version `n+2`. For instance, something like restic feature support, that might mean that restic is removed from the list of supported uploader types in version `n` but the underlying implementation required to restore from a restic backup won't be removed until release `n+2`.
## Updating Governance
All substantive changes in Governance require a supermajority agreement by all maintainers.
Makefile
+54 -34
View File
@@ -155,20 +155,40 @@ GOARCH = $(word 2, $(platform_temp))
GOPROXY ?= https://proxy.golang.org
GOBIN=$$(pwd)/.go/bin
# Keep these build-image tool versions in sync with go.mod so the CLI/library
# pair doesn't drift (see https://github.com/velero-io/velero/issues/10023).
PROTOC_GEN_GO_VERSION := $(shell go list -m -f '{{.Version}}' google.golang.org/protobuf)
GOIMPORTS_VERSION := $(shell go list -m -f '{{.Version}}' golang.org/x/tools)
# ==============================================================================
# ================================ COMMANDS ====================================
# ==============================================================================
# ==================================
# Help
# ==================================
# To document a new target, add "## <description>" at the end of the target line.
# Example: new-target: ## Description of the new target
.PHONY: help
help: ## Display this help message
@awk 'BEGIN {FS = ":.*##"; printf "\nUsage:\n make \033[36m<target>\033[0m\n\nTargets:\n"} /^[a-zA-Z0-9_%-]+:.*?##/ { printf " \033[36m%-20s\033[0m %s\n", $$1, $$2 }' $(MAKEFILE_LIST)
# If you want to build all binaries, see the 'all-build' rule.
# If you want to build all containers, see the 'all-containers' rule.
all:
all: ## Build the default velero binary
@$(MAKE) build
build-%:
build-%: ## Build specific binary
@$(MAKE) --no-print-directory ARCH=$* build
all-build: $(addprefix build-, $(CLI_PLATFORMS))
all-build: $(addprefix build-, $(CLI_PLATFORMS)) ## Build for all CLI platforms
all-containers:
all-containers: ## Build all containers
@$(MAKE) --no-print-directory container
local: build-dirs
local: build-dirs ## Build locally
# Add DEBUG=1 to enable debug locally
GOOS=$(GOOS) \
GOARCH=$(GOARCH) \
@@ -182,7 +202,7 @@ local: build-dirs
OUTPUT_DIR=$$(pwd)/_output/bin/$(GOOS)/$(GOARCH) \
./hack/build.sh
build: _output/bin/$(GOOS)/$(GOARCH)/$(BIN)
build: _output/bin/$(GOOS)/$(GOARCH)/$(BIN) ## Build the velero binary (use build-<os>-<arch> for specific targets)
_output/bin/$(GOOS)/$(GOARCH)/$(BIN): build-dirs
@echo "building: $@"
@@ -202,7 +222,7 @@ _output/bin/$(GOOS)/$(GOARCH)/$(BIN): build-dirs
TTY := $(shell tty -s && echo "-t")
# Example: make shell CMD="date > datefile"
shell: build-dirs build-env
shell: build-dirs build-env ## Run a shell in the build container
@# bind-mount the Velero root dir in at /github.com/vmware-tanzu/velero
@# because the Kubernetes code-generator tools require the project to
@# exist in a directory hierarchy ending like this (but *NOT* necessarily
@@ -225,7 +245,7 @@ shell: build-dirs build-env
$(BUILDER_IMAGE) \
/bin/sh $(CMD)
container:
container: ## Build the docker container (use container-<os>-<arch> for specific targets)
ifneq ($(CONTAINER_TOOL),docker)
$(error $(DOCKER_ONLY_ERROR))
endif
@@ -307,7 +327,7 @@ endif
@echo "built container: $(IMAGE):$(VERSION)-windows-$(BUILDX_OSVERSION)-$(BUILDX_ARCH)"
push-manifest:
push-manifest: ## Push multi-arch manifest
ifneq ($(CONTAINER_TOOL),docker)
$(error $(DOCKER_ONLY_ERROR))
endif
@@ -330,36 +350,36 @@ endif
@docker manifest inspect --insecure=$(INSECURE_REGISTRY) $(IMAGE_TAG)
SKIP_TESTS ?=
test: build-dirs
test: build-dirs ## Run unit tests
ifneq ($(SKIP_TESTS), 1)
@$(MAKE) shell CMD="-c 'hack/test.sh $(WHAT)'"
endif
test-local: build-dirs
test-local: build-dirs ## Run unit tests locally
ifneq ($(SKIP_TESTS), 1)
hack/test.sh $(WHAT)
endif
verify:
verify: ## Run all verify scripts
ifneq ($(SKIP_TESTS), 1)
@$(MAKE) shell CMD="-c 'hack/verify-all.sh'"
endif
lint:
lint: ## Run linter
ifneq ($(SKIP_TESTS), 1)
@$(MAKE) shell CMD="-c 'hack/lint.sh'"
endif
local-lint:
local-lint: ## Run linter locally
ifneq ($(SKIP_TESTS), 1)
@hack/lint.sh
endif
update:
update: ## Run all update scripts
@$(MAKE) shell CMD="-c 'hack/update-all.sh'"
# update-crd is for development purpose only, it is faster than update, so is a shortcut when you want to generate CRD changes only
update-crd:
update-crd: ## Update generated CRD code
@$(MAKE) shell CMD="-c 'hack/update-3generated-crd-code.sh'"
build-dirs:
@@ -387,7 +407,7 @@ else
$(CONTAINER_TOOL) pull -q $(BUILDER_IMAGE) || $(MAKE) build-image
endif
build-image:
build-image: ## Build the builder image
@# When we build a new image we just untag the old one.
@# This makes sure we don't leave the orphaned image behind.
$(eval old_id=$(shell $(CONTAINER_TOOL) image inspect --format '{{ .ID }}' ${BUILDER_IMAGE} 2>/dev/null))
@@ -395,16 +415,16 @@ ifeq ($(BUILDX_ENABLED), true)
ifneq ($(CONTAINER_TOOL),docker)
$(error $(DOCKER_ONLY_ERROR))
endif
@cd hack/build-image && $(CONTAINER_TOOL) buildx build --build-arg=GOPROXY=$(GOPROXY) --output=type=docker --pull -t $(BUILDER_IMAGE) -f $(BUILDER_IMAGE_DOCKERFILE_REALPATH) .
@cd hack/build-image && $(CONTAINER_TOOL) buildx build --build-arg=GOPROXY=$(GOPROXY) --build-arg=PROTOC_GEN_GO_VERSION=$(PROTOC_GEN_GO_VERSION) --build-arg=GOIMPORTS_VERSION=$(GOIMPORTS_VERSION) --output=type=docker --pull -t $(BUILDER_IMAGE) -f $(BUILDER_IMAGE_DOCKERFILE_REALPATH) .
else
@cd hack/build-image && $(CONTAINER_TOOL) build --build-arg=GOPROXY=$(GOPROXY) --pull -t $(BUILDER_IMAGE) -f $(BUILDER_IMAGE_DOCKERFILE_REALPATH) .
@cd hack/build-image && $(CONTAINER_TOOL) build --build-arg=GOPROXY=$(GOPROXY) --build-arg=PROTOC_GEN_GO_VERSION=$(PROTOC_GEN_GO_VERSION) --build-arg=GOIMPORTS_VERSION=$(GOIMPORTS_VERSION) --pull -t $(BUILDER_IMAGE) -f $(BUILDER_IMAGE_DOCKERFILE_REALPATH) .
endif
$(eval new_id=$(shell $(CONTAINER_TOOL) image inspect --format '{{ .ID }}' ${BUILDER_IMAGE} 2>/dev/null))
@if [ "$(old_id)" != "" ] && [ "$(old_id)" != "$(new_id)" ]; then \
$(CONTAINER_TOOL) rmi -f $$id || true; \
fi
push-build-image:
push-build-image: ## Push the builder image
ifneq ($(CONTAINER_TOOL),docker)
$(error $(DOCKER_ONLY_ERROR))
endif
@@ -418,10 +438,10 @@ else
docker push $(BUILDER_IMAGE)
endif
build-image-hugo:
build-image-hugo: ## Build the hugo image for docs
cd site && $(CONTAINER_TOOL) build --pull -t $(HUGO_IMAGE) .
clean:
clean: ## Clean up build artifacts and modcache
# if we have a cached image then use it to run go clean --modcache
# this test checks if we there is an image id in the BUILDER_IMAGE_CACHED variable.
ifneq ($(strip $(BUILDER_IMAGE_CACHED)),)
@@ -433,21 +453,21 @@ endif
.PHONY: modules
modules:
modules: ## Tidy go modules
go mod tidy
.PHONY: verify-modules
verify-modules: modules
verify-modules: modules ## Verify go modules are up to date
@if !(git diff --quiet HEAD -- go.sum go.mod); then \
echo "go module files are out of date, please commit the changes to go.mod and go.sum"; exit 1; \
fi
ci: verify-modules verify all test
ci: verify-modules verify all test ## Run CI checks
changelog:
changelog: ## Generate changelog
hack/release-tools/changelog.sh
# release builds a GitHub release using goreleaser within the build container.
@@ -465,7 +485,7 @@ changelog:
# RELEASE_NOTES_FILE=changelogs/CHANGELOG-1.2.md \
# PUBLISH=true \
# make release
release:
release: ## Build a GitHub release using goreleaser
$(MAKE) shell CMD="-c '\
GITHUB_TOKEN=$(GITHUB_TOKEN) \
RELEASE_NOTES_FILE=$(RELEASE_NOTES_FILE) \
@@ -473,7 +493,7 @@ release:
REGISTRY=$(REGISTRY) \
./hack/release-tools/goreleaser.sh'"
serve-docs: build-image-hugo
serve-docs: build-image-hugo ## Serve the documentation site locally
$(CONTAINER_TOOL) run \
--rm \
-v "$$(pwd)/site:/project" \
@@ -482,18 +502,18 @@ serve-docs: build-image-hugo
server --bind=0.0.0.0 --enableGitInfo=false
# gen-docs generates a new versioned docs directory under site/content/docs.
# Please read the documentation in the script for instructions on how to use it.
gen-docs:
gen-docs: ## Generate a new versioned docs directory
@hack/release-tools/gen-docs.sh
.PHONY: test-e2e
test-e2e: local
test-e2e: local ## Run end-to-end tests
$(MAKE) -e VERSION=$(VERSION) -C test/ run-e2e
.PHONY: test-perf
test-perf: local
test-perf: local ## Run performance tests
$(MAKE) -e VERSION=$(VERSION) -C test/ run-perf
go-generate:
go-generate: ## Run go generate
go generate ./pkg/...
# requires an authenticated gh cli
@@ -505,11 +525,11 @@ go-generate:
new-changelog: GH_LOGIN ?= $(shell gh pr view --json author --jq .author.login 2> /dev/null)
new-changelog: GH_PR_NUMBER ?= $(shell gh pr view --json number --jq .number 2> /dev/null)
new-changelog: CHANGELOG_BODY ?= '$(shell gh pr view --json title --jq .title)'
new-changelog:
new-changelog: ## Create a new changelog file for a PR
@if [ "$(GH_LOGIN)" = "" ]; then \
echo "branch does not have PR or cli not logged in, try 'gh auth login' or 'gh pr create'"; \
exit 1; \
fi
@mkdir -p ./changelogs/unreleased/ && \
echo $(CHANGELOG_BODY) > ./changelogs/unreleased/$(GH_PR_NUMBER)-$(GH_LOGIN) && \
echo \"$(CHANGELOG_BODY)\" added to "./changelogs/unreleased/$(GH_PR_NUMBER)-$(GH_LOGIN)"
echo \"$(CHANGELOG_BODY)\" added to "./changelogs/unreleased/$(GH_PR_NUMBER)-$(GH_LOGIN)"
SECURITY.md
-128
View File
@@ -1,128 +0,0 @@
# Security Release Process
Velero is an open source tool with a growing community devoted to safe backup and restore, disaster recovery, and data migration of Kubernetes resources and persistent volumes. The community has adopted this security disclosure and response policy to ensure we responsibly handle critical issues.
## Supported Versions
The Velero project maintains the following [governance document](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md), [release document](https://github.com/vmware-tanzu/velero/blob/f42c63af1b9af445e38f78a7256b1c48ef79c10e/site/docs/main/release-instructions.md), and [support document](https://velero.io/docs/main/support-process/). Please refer to these for release and related details. Only the most recent version of Velero is supported. Each [release](https://github.com/vmware-tanzu/velero/releases) includes information about upgrading to the latest version.
## Reporting a Vulnerability - Private Disclosure Process
Security is of the highest importance and all security vulnerabilities or suspected security vulnerabilities should be reported to Velero privately, to minimize attacks against current users of Velero before they are fixed. Vulnerabilities will be investigated and patched on the next patch (or minor) release as soon as possible. This information could be kept entirely internal to the project.
If you know of a publicly disclosed security vulnerability for Velero, please **IMMEDIATELY** contact the Security Team (velero-security.pdl@broadcom.com).
**IMPORTANT: Do not file public issues on GitHub for security vulnerabilities**
To report a vulnerability or a security-related issue, please contact the email address with the details of the vulnerability. The email will be fielded by the Security Team and then shared with the Velero maintainers who have committer and release permissions. Emails will be addressed within 3 business days, including a detailed plan to investigate the issue and any potential workarounds to perform in the meantime. Do not report non-security-impacting bugs through this channel. Use [GitHub issues](https://github.com/vmware-tanzu/velero/issues/new/choose) instead.
## Proposed Email Content
Provide a descriptive subject line and in the body of the email include the following information:
* Basic identity information, such as your name and your affiliation or company.
* Detailed steps to reproduce the vulnerability (POC scripts, screenshots, and logs are all helpful to us).
* Description of the effects of the vulnerability on Velero and the related hardware and software configurations, so that the Security Team can reproduce it.
* How the vulnerability affects Velero usage and an estimation of the attack surface, if there is one.
* List other projects or dependencies that were used in conjunction with Velero to produce the vulnerability.
## When to report a vulnerability
* When you think Velero has a potential security vulnerability.
* When you suspect a potential vulnerability but you are unsure that it impacts Velero.
* When you know of or suspect a potential vulnerability on another project that is used by Velero.
## Patch, Release, and Disclosure
The Security Team will respond to vulnerability reports as follows:
1. The Security Team will investigate the vulnerability and determine its effects and criticality.
2. If the issue is not deemed to be a vulnerability, the Security Team will follow up with a detailed reason for rejection.
3. The Security Team will initiate a conversation with the reporter within 3 business days.
4. If a vulnerability is acknowledged and the timeline for a fix is determined, the Security Team will work on a plan to communicate with the appropriate community, including identifying mitigating steps that affected users can take to protect themselves until the fix is rolled out.
5. The Security Team will also create a [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0). The Security Team makes the final call on the calculated CVSS; it is better to move quickly than making the CVSS perfect. Issues may also be reported to [Mitre](https://cve.mitre.org/) using this [scoring calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator). The CVE will initially be set to private.
6. The Security Team will work on fixing the vulnerability and perform internal testing before preparing to roll out the fix.
7. The Security Team will provide early disclosure of the vulnerability by emailing the [Velero Distributors](https://groups.google.com/u/1/g/projectvelero-distributors) mailing list. Distributors can initially plan for the vulnerability patch ahead of the fix, and later can test the fix and provide feedback to the Velero team. See the section **Early Disclosure to Velero Distributors List** for details about how to join this mailing list.
8. A public disclosure date is negotiated by the SecurityTeam, the bug submitter, and the distributors list. We prefer to fully disclose the bug as soon as possible once a user mitigation or patch is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for distributor coordination. The timeframe for disclosure is from immediate (especially if it’s already publicly known) to a few weeks. For a critical vulnerability with a straightforward mitigation, we expect the report date for the public disclosure date to be on the order of 14 business days. The Security Team holds the final say when setting a public disclosure date.
9. Once the fix is confirmed, the Security Team will patch the vulnerability in the next patch or minor release, and backport a patch release into all earlier supported releases. Upon release of the patched version of Velero, we will follow the **Public Disclosure Process**.
## Public Disclosure Process
The Security Team publishes a [public advisory](https://github.com/vmware-tanzu/velero/security/advisories) to the Velero community via GitHub. In most cases, additional communication via Slack, Twitter, mailing lists, blog and other channels will assist in educating Velero users and rolling out the patched release to affected users.
The Security Team will also publish any mitigating steps users can take until the fix can be applied to their Velero instances. Velero distributors will handle creating and publishing their own security advisories.
## Mailing lists
* Use velero-security.pdl@broadcom.com to report security concerns to the Security Team, who uses the list to privately discuss security issues and fixes prior to disclosure.
* Join the [Velero Distributors](https://groups.google.com/u/1/g/projectvelero-distributors) mailing list for early private information and vulnerability disclosure. Early disclosure may include mitigating steps and additional information on security patch releases. See below for information on how Velero distributors or vendors can apply to join this list.
## Early Disclosure to Velero Distributors List
The private list is intended to be used primarily to provide actionable information to multiple distributor projects at once. This list is not intended to inform individuals about security issues.
## Membership Criteria
To be eligible to join the [Velero Distributors](https://groups.google.com/u/1/g/projectvelero-distributors) mailing list, you should:
1. Be an active distributor of Velero.
2. Have a user base that is not limited to your own organization.
3. Have a publicly verifiable track record up to the present day of fixing security issues.
4. Not be a downstream or rebuild of another distributor.
5. Be a participant and active contributor in the Velero community.
6. Accept the Embargo Policy that is outlined below.
7. Have someone who is already on the list vouch for the person requesting membership on behalf of your distribution.
**The terms and conditions of the Embargo Policy apply to all members of this mailing list. A request for membership represents your acceptance to the terms and conditions of the Embargo Policy.**
## Embargo Policy
The information that members receive on the Velero Distributors mailing list must not be made public, shared, or even hinted at anywhere beyond those who need to know within your specific team, unless you receive explicit approval to do so from the Security Team. This remains true until the public disclosure date/time agreed upon by the list. Members of the list and others cannot use the information for any reason other than to get the issue fixed for your respective distribution's users.
Before you share any information from the list with members of your team who are required to fix the issue, these team members must agree to the same terms, and only be provided with information on a need-to-know basis.
In the unfortunate event that you share information beyond what is permitted by this policy, you must urgently inform the Security Team (velero-security.pdl@broadcom.com) of exactly what information was leaked and to whom. If you continue to leak information and break the policy outlined here, you will be permanently removed from the list.
## Requesting to Join
Send new membership requests to projectvelero-distributors@googlegroups.com. In the body of your request please specify how you qualify for membership and fulfill each criterion listed in the Membership Criteria section above.
## Confidentiality, integrity and availability
We consider vulnerabilities leading to the compromise of data confidentiality, elevation of privilege, or integrity to be our highest priority concerns. Availability, in particular in areas relating to DoS and resource exhaustion, is also a serious security concern. The Security Team takes all vulnerabilities, potential vulnerabilities, and suspected vulnerabilities seriously and will investigate them in an urgent and expeditious manner.
Note that we do not currently consider the default settings for Velero to be secure-by-default. It is necessary for operators to explicitly configure settings, role based access control, and other resource related features in Velero to provide a hardened Velero environment. We will not act on any security disclosure that relates to a lack of safe defaults. Over time, we will work towards improved safe-by-default configuration, taking into account backwards compatibility.
SUPPORT.md
-7
View File
@@ -1,7 +0,0 @@
# Velero Support
Thanks for trying out Velero! We welcome all feedback, find all the ways to connect with us on our Community page:
- [Velero Community](https://velero.io/community/)
You can find details on the Velero maintainers' support process [here](https://velero.io/docs/main/support-process/).
changelogs/unreleased/10000-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Fix stale backupLastSuccessfulTimestamp metric after schedule deletion
changelogs/unreleased/10004-chlins
+1
View File
@@ -0,0 +1 @@
Support selecting the data mover type (velero-fs or velero-block) through the volume policy snapshot action's dataMover parameter
changelogs/unreleased/10005-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Fix issue #9973, fail earlier when PVR pod is not ready
changelogs/unreleased/10007-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Fix issue #9997, cancel ongoing PVB on timeout and wait for all PVBs to terminal state
changelogs/unreleased/10009-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Add CRD short names for all Velero custom resources
changelogs/unreleased/10013-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Add block dev restore operations for block data mover
changelogs/unreleased/10016-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Fix issue #9938, add use guide for restore fine-grained filters via resource policy
changelogs/unreleased/10033-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Fix issue #10032, prioritize exact namespace match in restore
changelogs/unreleased/10035-HajimohammadiNet
+1
View File
@@ -0,0 +1 @@
Trim whitespace around plugin image entries during install.
changelogs/unreleased/10045-lubronzhan
+1
View File
@@ -0,0 +1 @@
Fix issue #5836, respect schedule.spec.template.metadata.annotations to override annotations copied from the Schedule to Backup objects, matching the existing behavior for labels
changelogs/unreleased/10047-kaovilai
+1
View File
@@ -0,0 +1 @@
Fix restore-wait init container ignoring pod-level securityContext, falling back to hardcoded runAsUser 1000 instead of the workload's own uid/gid, causing fs-backup restores to deadlock at Init:0/1 on owner-restricted volumes
changelogs/unreleased/10056-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
RIA must include additional items design
changelogs/unreleased/10064-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Add set based label selectors for fine-grained filters
changelogs/unreleased/10067-blackpiglet
+1
View File
@@ -0,0 +1 @@
Backup workflow for block data mover.
changelogs/unreleased/10070-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Add snapshotClass parameter to volume policy snapshot action
changelogs/unreleased/10071-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Fix issue #9828, add implementation for block uploader restore
changelogs/unreleased/10082-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Add restore.velero.io/must-include-additional-items so RestoreItemActions can opt in to bypassing global restore filters for AdditionalItems (mirrors the backup-side must-include annotation; no default behavior change for existing restores/plugins)
changelogs/unreleased/10087-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
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)
changelogs/unreleased/10091-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Refactor block uploader thread module for better thread safety and code reading
changelogs/unreleased/10093-chlins
+1
View File
@@ -0,0 +1 @@
Replace rebase action with GitHub CLI
changelogs/unreleased/10098-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Implement server default restore resource modifier
changelogs/unreleased/10102-chlins
+1
View File
@@ -0,0 +1 @@
Verify extracted item paths stay inside the backup directory
changelogs/unreleased/10106-blackpiglet
+1
View File
@@ -0,0 +1 @@
Fix some issues for CBT features: logs, CRD change, GetDataMover.
changelogs/unreleased/10125-chlins
+1
View File
@@ -0,0 +1 @@
Cancel hook exec stream on timeout and bound hook timeouts
changelogs/unreleased/10126-blackpiglet
+1
View File
@@ -0,0 +1 @@
Use "" as parentSnapshot for DU when BackupType is incremental.
changelogs/unreleased/10138-Jay2006sawant
+1
View File
@@ -0,0 +1 @@
Fix block uploader restore validation and BatchForget error handling
changelogs/unreleased/10150-chlins
+1
View File
@@ -0,0 +1 @@
Drop node-agent host path mounts from data mover pods
changelogs/unreleased/10158-Pragati5-DEBUG
+1
View File
@@ -0,0 +1 @@
Add GitHub Action to automate backport/cherry-pick onto release branches
changelogs/unreleased/10159-Pragati5-DEBUG
+1
View File
@@ -0,0 +1 @@
Fix excluded namespace objects leaking into backups when using cross-namespace listing
changelogs/unreleased/10200-Ralthos
+1
View File
@@ -0,0 +1 @@
Add printer columns for Backup and Restore CRDs so kubectl shows status, errors, warnings and timing
changelogs/unreleased/10211-Ralthos
+1
View File
@@ -0,0 +1 @@
Add printer columns for VolumeSnapshotLocation so kubectl shows provider and phase
changelogs/unreleased/10218-opbot-xd
+1
View File
@@ -0,0 +1 @@
Add missing test assertions for PVCBackupSummary in podvolume backupper
changelogs/unreleased/10225-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Add prefetch mechanism to object reader so as to improve the restore throughput of block data mover
changelogs/unreleased/10227-ywk253100
+1
View File
@@ -0,0 +1 @@
Add "SnapshotClass" to DataUploadResult
changelogs/unreleased/10231-Ralthos
+1
View File
@@ -0,0 +1 @@
Add a troubleshooting entry for artifact downloads failing when the BackupStorageLocation s3Url is only resolvable inside the cluster
changelogs/unreleased/10234-Ralthos
+1
View File
@@ -0,0 +1 @@
Make velero restore logs return errors instead of calling os.Exit directly, matching velero backup logs, and enable the two previously skipped tests
changelogs/unreleased/9697-Joeavaikath
+1
View File
@@ -0,0 +1 @@
Fail backup validation when built-in data mover is requested but no node-agent pods are running
changelogs/unreleased/9720-Joeavaikath
+1
View File
@@ -0,0 +1 @@
Add dynamic resource autocompletion to Velero CLI
changelogs/unreleased/9863-blackpiglet
+1
View File
@@ -0,0 +1 @@
Support change-id and volume-id in backup workflow.
changelogs/unreleased/9921-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Design: Server default restore resource modifier
changelogs/unreleased/9943-lubronzhan
+1
View File
@@ -0,0 +1 @@
Extract pkg/apis into its own Go module with a local replace directive in the root go.mod
changelogs/unreleased/9944-lubronzhan
+1
View File
@@ -0,0 +1 @@
Fix flaky TestWaitExecHandleHooks test for 2-container hook ordering by synchronizing pod state changes with hook execution using channels
changelogs/unreleased/9945-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Add snapshot operations for block uploader
changelogs/unreleased/9946-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Fix issue #9936, restore filters via resource policy implementation
changelogs/unreleased/9954-blackpiglet
+1
View File
@@ -0,0 +1 @@
Add BackupType in backup.spec
changelogs/unreleased/9955-sseago
+1
View File
@@ -0,0 +1 @@
Optimize VSC handle readiness polling for VSS backups
changelogs/unreleased/9966-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Fix issue #9937, add CLI support for restore filters via resource policy
changelogs/unreleased/9967-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Fix issue #9820, user guide for backup fine-grained filters via resource policy
changelogs/unreleased/9968-ywk253100
+1
View File
@@ -0,0 +1 @@
Use forward slash as the path separator to make sure it works on both Linux and Windows nodes
changelogs/unreleased/9974-blackpiglet
+1
View File
@@ -0,0 +1 @@
Disable fips140 enforcement because Kopia doesn't support it.
changelogs/unreleased/9978-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Add image volume type support to volume policies
changelogs/unreleased/9979-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Add the backup implementation for block data mover
changelogs/unreleased/9982-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Validate user-provided labels and annotations in maintenance job
changelogs/unreleased/9987-Shashank1306s
+1
View File
@@ -0,0 +1 @@
Fix ResourceDeletionStatusTracker key mismatch so restore into a terminating namespace waits once per namespace instead of once per resource
changelogs/unreleased/9989-adam-jian-zhang
+1
View File
@@ -0,0 +1 @@
Fix globalExcludes lookup, it should be lookup against lower case
changelogs/unreleased/9993-chlins
+1
View File
@@ -0,0 +1 @@
Surface DeleteItemAction plugin errors from InvokeDeleteActions so backup deletion fails and retries instead of silently orphaning data mover snapshots and other private artifacts
changelogs/unreleased/9994-Lyndon-Li
+1
View File
@@ -0,0 +1 @@
Add block device operations for block uploader backup
changelogs/unreleased/9995-shubham-pampattiwar
+1
View File
@@ -0,0 +1 @@
Fix PodVolumeBackup metadata loss on fs-backup timeout, which caused all fs-backup volumes to become unrestorable
changelogs/unreleased/RS-MIRRORS_GITHUB_VELERO-22
+1
View File
@@ -0,0 +1 @@
Verify downloaded build tools against architecture-specific SHA-256 checksums before installation.
config/crd/v1/bases/velero.io_backuprepositories.yaml
+2
View File
@@ -11,6 +11,8 @@ spec:
kind: BackupRepository
listKind: BackupRepositoryList
plural: backuprepositories
shortNames:
- repo
singular: backuprepository
scope: Namespaced
versions:
config/crd/v1/bases/velero.io_backups.yaml
+37 -2
View File
@@ -11,10 +11,32 @@ spec:
kind: Backup
listKind: BackupList
plural: backups
shortNames:
- bak
singular: backup
scope: Namespaced
versions:
- name: v1
- additionalPrinterColumns:
- description: Backup status such as New/InProgress
jsonPath: .status.phase
name: Status
type: string
- description: Total number of errors logged during the backup
jsonPath: .status.errors
name: Errors
type: integer
- description: Total number of warnings logged during the backup
jsonPath: .status.warnings
name: Warnings
type: integer
- description: The time the backup was started
jsonPath: .status.startTimestamp
name: Started
type: date
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1
schema:
openAPIV3Schema:
description: |-
@@ -41,6 +63,13 @@ spec:
spec:
description: BackupSpec defines the specification for a Velero backup.
properties:
backupType:
description: BackupType specifies how volume data is backed up, with
possible values including Full and Incremental.
enum:
- Full
- Incremental
type: string
csiSnapshotTimeout:
description: |-
CSISnapshotTimeout specifies the time used to wait for CSI VolumeSnapshot status turns to
@@ -50,7 +79,7 @@ spec:
datamover:
description: |-
DataMover specifies the data mover to be used by the backup.
If DataMover is "" or "velero", the built-in data mover will be used.
If DataMover is "" or "velero", the default built-in data mover will be used.
type: string
defaultVolumesToFsBackup:
description: |-
@@ -384,6 +413,11 @@ spec:
x-kubernetes-map-type: atomic
metadata:
properties:
annotations:
additionalProperties:
type: string
nullable: true
type: object
labels:
additionalProperties:
type: string
@@ -674,3 +708,4 @@ spec:
type: object
served: true
storage: true
subresources: {}
config/crd/v1/bases/velero.io_deletebackuprequests.yaml
+2
View File
@@ -11,6 +11,8 @@ spec:
kind: DeleteBackupRequest
listKind: DeleteBackupRequestList
plural: deletebackuprequests
shortNames:
- dbr
singular: deletebackuprequest
scope: Namespaced
versions:
config/crd/v1/bases/velero.io_downloadrequests.yaml
+2
View File
@@ -11,6 +11,8 @@ spec:
kind: DownloadRequest
listKind: DownloadRequestList
plural: downloadrequests
shortNames:
- dreq
singular: downloadrequest
scope: Namespaced
versions:
config/crd/v1/bases/velero.io_podvolumebackups.yaml
+2
View File
@@ -11,6 +11,8 @@ spec:
kind: PodVolumeBackup
listKind: PodVolumeBackupList
plural: podvolumebackups
shortNames:
- pvb
singular: podvolumebackup
scope: Namespaced
versions:
config/crd/v1/bases/velero.io_podvolumerestores.yaml
+2
View File
@@ -11,6 +11,8 @@ spec:
kind: PodVolumeRestore
listKind: PodVolumeRestoreList
plural: podvolumerestores
shortNames:
- pvr
singular: podvolumerestore
scope: Namespaced
versions:
config/crd/v1/bases/velero.io_restores.yaml
+32 -1
View File
@@ -11,10 +11,32 @@ spec:
kind: Restore
listKind: RestoreList
plural: restores
shortNames:
- rst
singular: restore
scope: Namespaced
versions:
- name: v1
- additionalPrinterColumns:
- description: The name of the backup this restore is from
jsonPath: .spec.backupName
name: Backup
type: string
- description: Restore status such as New/InProgress
jsonPath: .status.phase
name: Status
type: string
- description: Total number of errors logged during the restore
jsonPath: .status.errors
name: Errors
type: integer
- description: Total number of warnings logged during the restore
jsonPath: .status.warnings
name: Warnings
type: integer
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1
schema:
openAPIV3Schema:
description: |-
@@ -465,6 +487,14 @@ spec:
from. If specified, and BackupName is empty, Velero will restore
from the most recent successful backup created from this schedule.
type: string
skipDefaultResourceModifier:
description: |-
SkipDefaultResourceModifier controls whether the server-configured default
resource modifier is applied to this restore.
When true, the default modifier is skipped even if configured on the server.
Has no effect when a per-restore ResourceModifier is specified.
nullable: true
type: boolean
uploaderConfig:
description: UploaderConfig specifies the configuration for the restore.
nullable: true
@@ -587,3 +617,4 @@ spec:
type: object
served: true
storage: true
subresources: {}
config/crd/v1/bases/velero.io_schedules.yaml
+15 -1
View File
@@ -11,6 +11,8 @@ spec:
kind: Schedule
listKind: ScheduleList
plural: schedules
shortNames:
- sched
singular: schedule
scope: Namespaced
versions:
@@ -80,6 +82,13 @@ spec:
Template is the definition of the Backup to be run
on the provided schedule
properties:
backupType:
description: BackupType specifies how volume data is backed up,
with possible values including Full and Incremental.
enum:
- Full
- Incremental
type: string
csiSnapshotTimeout:
description: |-
CSISnapshotTimeout specifies the time used to wait for CSI VolumeSnapshot status turns to
@@ -89,7 +98,7 @@ spec:
datamover:
description: |-
DataMover specifies the data mover to be used by the backup.
If DataMover is "" or "velero", the built-in data mover will be used.
If DataMover is "" or "velero", the default built-in data mover will be used.
type: string
defaultVolumesToFsBackup:
description: |-
@@ -425,6 +434,11 @@ spec:
x-kubernetes-map-type: atomic
metadata:
properties:
annotations:
additionalProperties:
type: string
nullable: true
type: object
labels:
additionalProperties:
type: string
config/crd/v1/bases/velero.io_volumesnapshotlocations.yaml
+14 -1
View File
@@ -16,7 +16,19 @@ spec:
singular: volumesnapshotlocation
scope: Namespaced
versions:
- name: v1
- additionalPrinterColumns:
- description: Provider is the provider of the volume storage
jsonPath: .spec.provider
name: Provider
type: string
- description: Volume Snapshot Location status such as Available/Unavailable
jsonPath: .status.phase
name: Phase
type: string
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1
schema:
openAPIV3Schema:
description: VolumeSnapshotLocation is a location where Velero stores volume
@@ -93,3 +105,4 @@ spec:
type: object
served: true
storage: true
subresources: {}
config/crd/v1/crds/crds.go
+9 -9
View File
File diff suppressed because one or more lines are too long
config/crd/v2alpha1/bases/velero.io_datadownloads.yaml
+3 -1
View File
@@ -11,6 +11,8 @@ spec:
kind: DataDownload
listKind: DataDownloadList
plural: datadownloads
shortNames:
- dd
singular: datadownload
scope: Namespaced
versions:
@@ -90,7 +92,7 @@ spec:
datamover:
description: |-
DataMover specifies the data mover to be used by the backup.
If DataMover is "" or "velero", the built-in data mover will be used.
If DataMover is "" or "velero", the built-in fs data mover will be used.
type: string
nodeOS:
description: NodeOS is OS of the node where the DataDownload is processed.
config/crd/v2alpha1/bases/velero.io_datauploads.yaml
+10 -1
View File
@@ -11,6 +11,8 @@ spec:
kind: DataUpload
listKind: DataUploadList
plural: datauploads
shortNames:
- du
singular: dataupload
scope: Namespaced
versions:
@@ -122,13 +124,20 @@ spec:
datamover:
description: |-
DataMover specifies the data mover to be used by the backup.
If DataMover is "" or "velero", the built-in data mover will be used.
If DataMover is "" or "velero", the built-in fs data mover will be used.
type: string
operationTimeout:
description: |-
OperationTimeout specifies the time used to wait internal operations,
before returning error as timeout.
type: string
parentSnapshot:
description: |-
ParentSnapshot specifies the parent snapshot that current backup is based on.
If its value is "" or "auto", the data mover finds the recent backup of the same volume as parent.
If its value is "none", the data mover will do a full backup
If its value is a specific snapshotID, the data mover finds the specific snapshot as parent.
type: string
snapshotType:
description: SnapshotType is the type of the snapshot to be backed
up.

Some files were not shown because too many files have changed in this diff Show More