tektoncd
Consider renaming `IMAGE_URL`/`IMAGE_DIGEST` type hints to `ARTIFACT_NAME`/`ARTIFACT_DIGEST`
When generating provenance from a TaskRun Chains looks for *IMAGE_URL and *IMAGE_DIGEST results types to figure out what artifact was actually built. This is what goes into the subject section of the provenance. Right now, we assume OCI images were built and only have support for them.
I was thinking that we could rename these results to something more generic, like *ARTIFACT_NAME and *ARTIFACT_DIGEST so that other types of subjects could be included in provenance. We can still infer if something is an OCI image, but now we can also support generic files that may have been built in the TaskRun along with digests for them. This could be useful if something other than an image is being built and published from a TaskRun.
The only thing I'm not sure about is if we should also be signing these ARTIFACTs if they aren't OCI images. If a TaskRun builds and publishes a binary somewhere, should Chains be responsible for signing it somehow if it's being included in provenance?
This makes sense.
Have you considered where the signature would be pushed, in case of binaries?
So if binaries are stored in one of our supported storage backends, (gcs or docdb) then we would need some way of referencing their location in the Task (maybe gcs://mybucket/myfile or firestore://something for docdb. Then, Chains could find the file, sign it and store the signature in the same spot. We could also add this to the config as a new artifact type to configure where signature are stored, so we'd add:
-
artifacts.file.storage -
artifacts.file.signer
I could see this being useful for something like signing entire release yamls for Tekton/Chains releases, which are stored in GCS.
Makes sense.
Another comment on this:
Do you think we could make the names IMAGE_URL/IMAGE_DIGEST , ARTIFACT_NAME/ARTIFACT_DIGEST configurable for an instance of Tekton Chains installation ?
Do you think we could make the names IMAGE_URL/IMAGE_DIGEST , ARTIFACT_NAME/ARTIFACT_DIGEST configurable for an instance of Tekton Chains installation ?
Yah it's definitely possible, but I'd prefer not to do that so that Tasks could be used across installations and just work.
Drive by comment: via TEP-0075 we'll hopefully be adding support for richer result types (in this case objects with keys and values) so i wonder if it would be worth making this naming change now, or making it when we can update chains to use these richer types (or maybe chains would always support both?)
If there isn't an immediate need for this, I'm happy to wait for richer result types!
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopenwith a justification. Mark the issue as fresh with/remove-lifecycle rottenwith a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozenwith a justification./close
Send feedback to tektoncd/plumbing.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.