The tasks here are designed to be consumed via remote task includes in a single root level tasks.yaml in the downstream repo. Includes should follow the standard remote include pattern documented by UDS CLI:

includes:
  - deploy: https://raw.githubusercontent.com/defenseunicorns/uds-common/$TAG/tasks/deploy.yaml

Pinning to a specific tag of a task (rather than main) with renovate watching for updates is strongly recommended since tasks do rely on dependencies like command syntax for zarf and uds as well as the published versions of uds-core.

• UDS CLI: 0.41.0
• UDS Core: 1.16.0
• K3D: 5.9.0

Set NEXT_MODE=true once on the outer uds run invocation to use UDS CLI Next bundle commands for bundle create/deploy/remove/publish/pull tasks:

uds run test-install --set NEXT_MODE=true

For the reusable GitHub workflows, pass it through the existing options input:

with:
  options: --set NEXT_MODE=true

There are multiple task files available in this repository with different objectives and required variables.

To include a primary-product CPE, pass a complete CPE 2.3 application binding with a wildcard version to create:package, for example:

uds run create:package --with 'cpe=cpe:2.3:a:f5:nginx:*:*:*:*:*:*:*:*'

The package definition must declare one imageArchives image named zarf.internal/sbom/<metadata.name>:dev for the active flavor (or shared across flavors). The shim reads that flavor's version from releaser.yaml beside the package definition, removes only the trailing -uds.NUMBER, and rewrites the archive tag to match the product version used in the CPE and PURL. No separate Renovate rule is needed for the shim tag. Missing or duplicate flavor versions are rejected. The nginx release task supplies its CPE automatically; development packages still skip SBOM scanning.

Run bash tests/sbom.sh to create packages and verify the product identity in their extracted SBOMs. Like tests/renovate.sh, this uses temporary workspaces and runs in the Common-Specific Checks PR workflow, as an independent SBOM job.

This task file defines a set of linting commands to ensure code quality and compliance. It includes tasks to install linting tool dependencies, perform checks on YAML files and OSCAL configurations, validate shell scripts with shellcheck, and verify or add the SPDX license identifier in source files. Both the license and fix-license tasks parse a .license_config.yaml file in the project root directory, but will default to the Defense Unicorns dual-license if the file is not present.

license: AGPL-3.0-or-later OR LicenseRef-Defense-Unicorns-Commercial
copyright: Defense Unicorns
ignore: [] # an array of paths to ignore

The zarf-tools task checks inline cmd entries in Zarf component actions for likely tool calls. It is a basic check, so it may miss some calls or flag text that does not run as a command. It does not inspect UDS task files.

The renovate task is opt-in and defaults to renovate.json. It requires Node.js 24.11+ (24.x) and npm; Renovate is downloaded automatically.

uds run lint:renovate
uds run lint:renovate --with file=config/renovate.json5

The zizmor task audits GitHub workflows and composite actions. It is opt-in: lint:all, lint:deps, and the standard callable lint workflow do not invoke or install zizmor.

Install zizmor locally, then run:

uds run lint:zizmor

Optional inputs control which inputs are collected and how/which findings are reported:

uds run lint:zizmor \
  --with collect=default \
  --with persona=pedantic \
  --with min-severity=medium \
  --with min-confidence=high

Omitted persona, severity, and confidence inputs leave zizmor defaults unchanged.

The task always audits the current directory (.), runs offline, and fails on blocking findings or collected files with workflow schema errors.

A downstream task can invoke it with task: lint:zizmor through an existing include of tasks/lint.yaml.

Like renovate, the values-generate and values-check tasks are opt-in and are not included in lint:all. Package repositories can use them through their existing remote include of tasks/lint.yaml; no local lint wrapper is needed. Update that include to a release containing these tasks before enabling the check.

uds run lint:values-generate
uds run lint:values-check

Both tasks accept path (default .) and flavor (default upstream):

uds run lint:values-generate --with path=packages/irsa --with flavor=registry1
uds run lint:values-check --with path=packages/irsa --with flavor=registry1
# For a package without flavors:
uds run lint:values-check --with flavor=""

The schema path is read from values.schema in the selected package's zarf.yaml, relative to the package directory. The schema file must already exist with a valid JSON Schema declaration, as required by Zarf's schema generator. Missing configuration, missing schema files, and generation failures fail the task rather than silently skipping it.

values-check regenerates with --delete-not-found into a temporary file and compares the result with the existing schema. It runs locally as well as in CI, prints the full diff on drift, and leaves the schema unchanged. It does not require a Git checkout or a clean working tree. values-generate replaces the schema only after successful generation. Both tasks clean up temporary files.

To enable the check in the existing reusable GitHub lint workflow:

jobs:
  lint:
    uses: defenseunicorns/uds-common/.github/workflows/callable-lint.yaml@<release>
    with:
      values-check: true
      values-path: .
      values-flavor: upstream
    secrets: inherit

The workflow defaults to values-check: false, preserving existing consumers' lint behavior. The optional check runs after the existing lint step. Pin both the workflow and task include to the same release containing these capabilities.

Use the same UDS CLI version locally and in CI: the tasks use its embedded Zarf through ./zarf, and generator versions can differ in type inference and output formatting. The reusable lint workflow currently installs UDS CLI v0.39.0. Use values-generate to produce the checked-in schema in the same stdout format used by values-check, then review and commit the result. A flavor-specific schema should be generated and checked using the same flavor.

The shell task accepts a space-separated exclusion input for directories that should be skipped by shellcheck:

- task: lint:shell
  with:
    exclusion: ".husky vendor"