Files
velero/.github/workflows/push-builder.yml
T
Shubham Pampattiwar 3191e38ac3 Set least-privilege GITHUB_TOKEN permissions in workflows
Add an explicit top-level permissions block to the GitHub Actions
workflows that were relying on the default token permissions. Each
workflow now defaults to contents: read, with additional scopes granted
only where a job needs them:

* nightly-trivy-scan keeps security-events: write at the job level to
  upload SARIF results, plus contents: read for checkout.
* stale-issues gets issues: write and pull-requests: write for the
  actions/stale action to label and close stale items.

Setting least-privilege permissions reduces the blast radius if a
workflow or one of its dependencies is compromised, and satisfies the
CLOMonitor token_permissions check.

Signed-off-by: Shubham Pampattiwar <spampatt@redhat.com>
2026-09-03 10:14:23 -07:00

39 lines
1.3 KiB
YAML

name: build-image
on:
push:
branches: [ main ]
paths:
- 'hack/build-image/Dockerfile'
permissions:
contents: read
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- 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
# contains the changes.
# As we use the Dockerfile's commit ID as the tag of the build-image, fetching only 1 commit causes the merge
# commit ID to be the tag.
# While when running make commands locally, as the local git repository usually contains all commits, the Dockerfile's
# commit ID is the second one. This is mismatch with the images in Dockerhub
fetch-depth: 2
- name: Build
run: make build-image
# Only try to publish the container image from the root repo; forks don't have permission to do so and will always get failures.
- name: Publish container image
if: github.repository == 'velero-io/velero'
run: |
docker login -u ${{ secrets.DOCKER_USER }} -p ${{ secrets.DOCKER_PASSWORD }}
make push-build-image