TEP-0192: Tekton Artifacts API - #1298
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@waveywaves this is the new updated TEP 🙏🏼 |
| |---------------------------------------------------------------------------------------|--------------------------------------------| | ||
| | `$(step.artifacts.path)` with JSON | `$(outputs.<name>.uri)` for references | | ||
| | `$(artifacts.path)` with JSON | `$(outputs.<name>.path)` for content | | ||
| | No `spec.artifacts` declaration | `spec.artifacts.outputs` declaration | |
There was a problem hiding this comment.
| | No `spec.artifacts` declaration | `spec.artifacts.outputs` declaration | | |
| | No `spec.artifacts` declaration | `spec.artifacts.outputs`, `spec.artifacts.inputs` declaration | |
| - name: test-results | ||
| description: JUnit test results | ||
| type: content |
There was a problem hiding this comment.
Do we need to mention type ?? asking because its default and if we don't mention content will be considered right
There was a problem hiding this comment.
yeah this is more to be explicit in the example, but content would be the default.
| 6. `subject: true` for SLSA attestation subject identification. | ||
| 7. `Provider` interface for pluggable storage backends. | ||
| 8. Init container injection for downloading content artifacts. | ||
| 9. Digest verification on upload and download. |
There was a problem hiding this comment.
is this also should be done by init container ??
There was a problem hiding this comment.
yes, it would be done by the same init container, most likely the entrypoint.
| external storage overhead. The entrypoint decides based on a configurable | ||
| size threshold (default 1KB). |
There was a problem hiding this comment.
as this status controlled by Tekton apart from default value what are the other configurable sizes ??
There was a problem hiding this comment.
hmm not sure I understand the question
|
|
||
| **Must Have:** | ||
|
|
||
| 1. Tasks declare `spec.artifacts.inputs` and `spec.artifacts.outputs`. |
There was a problem hiding this comment.
for the Tasks like git-clone which is already in use for many pipelines so if user want to use artifact way in their Pipeline instead of pvc what will be the path forward ??
There was a problem hiding this comment.
good question, naively I thought we would publish a new version / variant of the git-clone task..
But maybe we could have something where artifact could be optionally used ? (seems complex though)
| - E2E tests: full Pipeline with content and reference artifacts, storage | ||
| backend integration, digest verification. | ||
| - Backward compatibility: ensure `spec.results` continues working. | ||
| - Migration: verify removal of `$(step.artifacts.path)`. |
There was a problem hiding this comment.
Can we also include performance benchmark
There was a problem hiding this comment.
good point, we probably should.
f64e6e2 to
705d776
Compare
Declarative spec.artifacts.inputs/outputs on TaskSpec with two artifact types: - type: reference — step already pushed content, Tekton records uri+digest - type: content — step writes data, Tekton handles upload/download/verify Replaces TEP-0147 Phase 1 alpha API (step.artifacts.path manual JSON). subject: true replaces buildOutput/IMAGE_URL type hinting for SLSA. Provider interface for pluggable storage backends. Pipeline-level artifact bindings with implicit DAG edges. Eliminates PVC Workspaces for common inter-task data patterns.
705d776 to
2e7cd6f
Compare
|
|
||
| When a Task has content artifact inputs (from Pipeline bindings or | ||
| PipelineRun inputs), the controller transparently fetches and verifies | ||
| the content before any user Steps execute. The fetch image is built and |
There was a problem hiding this comment.
The fetch image is built and
are we adding new image called fetch??
Summary
This TEP introduces a declarative Artifact API for Tekton Tasks and Pipelines, replacing the manual provenance-JSON model from TEP-0147 Phase 1 (alpha, behind
enable-artifactsfeature flag).Tasks declare
spec.artifacts.inputsandspec.artifacts.outputswith two types:type: content— the step writes data to a path; Tekton uploads, downloads, and verifies it transparently across Tasks.type: reference— the step already pushed content elsewhere (e.g.,buildah push); it writes a URI and digest so Tekton can record and propagate the reference.Pipelines bind artifacts between Tasks with
from:syntax, creating implicit DAG edges. The controller transparently fetches and verifies content artifacts before user steps execute.Key Design Decisions
$(step.artifacts.path)manual JSON) — clean replacement, not coexistence. Feature is alpha behind flag, breaking change acceptable per API compatibility policy.subject: truereplacesbuildOutput: true— maps directly to SLSA attestation subject, eliminates Chains'IMAGE_URL/IMAGE_DIGESTtype-hinting convention.Relationship to Existing TEPs
vdemeester/tekton-experiments/kind tep