ADR 45: Guidelines for developing tasks #216
Conversation
arewm
requested review from
ralphbean,
davidmogar,
johnbieren,
mmorhun,
dirgim,
chmeliik and
a team
Presenting broad guidelines for where to contribute different types of tasks as well as patterns that should be generally followed in the tasks in the locations. On the 2024-11-05 Konflux community architecture call, we discussed whether there were any guidelines for where to contribute tasks to. The result of that call was that we need to create an ADR outlining the recommendations so that we can also enable more targeted conversation. The recording for the call can be found on YouTube: https://www.youtube.com/watch?v=uJbNdceDrTg Signed-off-by: arewm <[email protected]>
arewm
force-pushed
the
guidelines-for-developing-tasks
branch
from
32d2170
to
9dacecc
Compare
| * Whenever possible, a task that just changes the format of an artifact (for example creating a tar from a container image) | ||
| should be performed in the same pipeline that produced the artifact. These modified artifacts should be attached using | ||
| the referrer's API and the blob digest reported via results to enable verification that the artifacts were produced | ||
| from a trusted task. |
There was a problem hiding this comment.
Why? Converting to a different format can be done during release or even post-release without loss of trust
There was a problem hiding this comment.
It enables users to verify that the format change is done properly before those artifacts are released.
I am not sure what you mean by post-release here. These are modifications that are needed before releases can progress.
There was a problem hiding this comment.
It enables users to verify that the format change is done properly before those artifacts are released.
Maybe I'd need a better example than the one in this doc. When I skopeo copy docker://registry.access.redhat.com/ubi9/ubi-micro:9.4 oci:/tmp/ubi, I don't need to verify anything.
There was a problem hiding this comment.
If you have an integration test scenario that does not use the ubi-migro image in registry but instead uses a tarball, you would need that tarball to verify the artifact.
The need to verify isn't always required by a human but by some process. It should be possible to have all artifacts-to-be-released verified as is. If testing/verifying, a user or process shouldn't have to replicate the modifications done during a release pipeline within integration pipelines.
There was a problem hiding this comment.
The need to verify isn't always required by a human but by some process. It should be possible to have all artifacts-to-be-released verified as is. If testing/verifying, a user or process shouldn't have to replicate the modifications done during a release pipeline within integration pipelines.
Agreed, but still think that the example is really bad. The use case is purely hypothetical, nobody is ever going to create an integration test that requires an image to be in the weird format before testing the image. And in this example the release pipeline doesn't do any modifications. If we're calling skopeo copy a modification, then the release pipeline always modifies images on release
|
|
||
| ## Decision | ||
|
|
||
| * If any process is required to modify artifacts themselves, it should be done in [build pipelines]. This will ensure |
There was a problem hiding this comment.
I'm not aware any use cases that modify the artifacts from the build pipeline. Perhaps a footnote/appendix with examples of such modifications could be useful. Some OLM use cases I'm not aware of?
This could be even broader/stricter, e.g. "any production of the artifact must be performed on the build pipelines with the intent that the produced artifact is shipped as-is".
There was a problem hiding this comment.
konflux-ci/release-service-catalog#656 modifies the sbom, which is an artifact from the build pipeline
|
|
||
| * If any process is required to modify artifacts themselves, it should be done in [build pipelines]. This will ensure | ||
| that Konflux users can appropriately test and verify these artifacts before triggering releases with them. | ||
| * Any tasks which need to be included in the artifacts' provenance (enabling verification with EC policies) must be |
| artifacts to target locations, and updating metadata associated with the artifacts. | ||
| * Reusable tasks or pipelines that are intended to be used in IntegrationTestScenarios should be contributed to | ||
| [pipeline samples]. | ||
|
|
There was a problem hiding this comment.
Do we want to add a bullet point to where/how Tasks are contributed to the build (or even release) pipelines here?
| ## Consequences | ||
|
|
||
| * All artifacts produced in Konflux should have provenance attestations. These attestations will include information | ||
| about which tests have run. |
There was a problem hiding this comment.
The word "test" could be a bit ambiguous, perhaps
| about which tests have run. | |
| about which artifact or source checks have run. |
|
|
||
| * All artifacts produced in Konflux should have provenance attestations. These attestations will include information | ||
| about which tests have run. | ||
| * Whenever possible, the provenance attestations should be made available with the released artifacts. It may be |
There was a problem hiding this comment.
Not sure how this relates to the topic of developing tasks.
| necessary to update this metadata during the release process (for example, signing provenance with a different key | ||
| or updating the provenance to indicate that a build was hermetic). If it is not possible to publish the provenance | ||
| as-is, a summary attestation can be used instead. | ||
| * It should be possible to test any artifact that is going to be released. |
There was a problem hiding this comment.
Perhaps not related to the topic of developing tasks?
| not been any clear guidance about where contributions should be added or the types of functionality that are typical | ||
| for the stages of software development. | ||
|
|
||
| ## Decision |
Presenting broad guidelines for where to contribute different types of tasks as well as patterns that should be generally followed in the tasks in the locations.
On the 2024-11-05 Konflux community architecture call, we discussed whether there were any guidelines for where to contribute tasks to. The result of that call was that we need to create an ADR outlining the recommendations so that we can also enable more targeted conversation.
The recording for the call can be found on YouTube: https://www.youtube.com/watch?v=uJbNdceDrTg