ROX-23812: Add the acs-determine-image-tag task for ACS build pipelines #1282
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,23 @@ | ||
| # acs-determine-image-tag task | ||
|
|
||
| ## Description | ||
|
|
||
| The `acs-determine-image-tag` Task will determine the tag for the output image using the StackRox convention from 'make tag' output. | ||
|
|
||
| ## Params | ||
|
|
||
| | name | description | | ||
| |-----------------|-------------------------------------------------------------------------------------| | ||
| | IMAGE_TAG_STYLE | Image Tag style to be used, valid options are 'main' or 'operator'. | | ||
| | SOURCE_ARTIFACT | The Trusted Artifact URI pointing to the artifact with the application source code. | | ||
| | TAG_SUFFIX | Suffix to add to the make tag output. | | ||
|
|
||
| ## Results | ||
|
|
||
| | name | description | | ||
| |-------------------|-------------------------------| | ||
| | IMAGE_TAG | Image Tag determined by custom logic. | | ||
|
|
||
| ## Additional links | ||
|
|
||
| - [stackrox/stackrox](https://github.com/stackrox/stackrox) | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,62 @@ | ||
| --- | ||
| apiVersion: tekton.dev/v1 | ||
| kind: Task | ||
| metadata: | ||
| name: acs-determine-image-tag | ||
| labels: | ||
| app.kubernetes.io/version: "0.1" | ||
| spec: | ||
| description: The acs-determine-image-tag Task will determine the tag for the | ||
| output image using the StackRox convention from 'make tag' output. | ||
| params: | ||
| - name: TAG_SUFFIX | ||
| description: Suffix to append to generated image tag. | ||
| type: string | ||
| - name: SOURCE_ARTIFACT | ||
| description: The Trusted Artifact URI pointing to the artifact with | ||
| the application source code. This should be the result of the git-clone task, | ||
| results from other tasks might fail as dirty. | ||
| type: string | ||
| - name: IMAGE_TAG_STYLE | ||
| description: Image Tag style to be used, valid options are 'main' or 'operator'. | ||
| type: string | ||
| default: main | ||
| results: | ||
| - name: IMAGE_TAG | ||
| description: Image Tag determined by custom logic. | ||
| volumes: | ||
| - name: workdir | ||
| emptyDir: {} | ||
| stepTemplate: | ||
| volumeMounts: | ||
| - mountPath: /var/workdir | ||
| name: workdir | ||
| steps: | ||
| - name: use-trusted-artifact | ||
| image: quay.io/redhat-appstudio/build-trusted-artifacts:latest@sha256:4e39fb97f4444c2946944482df47b39c5bbc195c54c6560b0647635f553ab23d | ||
| args: | ||
| - use | ||
| - $(params.SOURCE_ARTIFACT)=/var/workdir/source | ||
| - name: determine-image-tag | ||
| image: quay.io/konflux-ci/appstudio-utils:ab6b0b8e40e440158e7288c73aff1cf83a2cc8a9@sha256:24179f0efd06c65d16868c2d7eb82573cce8e43533de6cea14fec3b7446e0b14 | ||
| workingDir: /var/workdir/source | ||
| script: | | ||
| #!/usr/bin/env bash | ||
| set -euo pipefail | ||
|
|
||
| .konflux/scripts/fail-build-if-git-is-dirty.sh | ||
| image_tag="" | ||
| image_tag_style="$(params.IMAGE_TAG_STYLE)" | ||
| case "$image_tag_style" in | ||
|
There was a problem hiding this comment. Please swap image tag style for directory where to run make: stackrox/stackrox#12350 |
||
| main) | ||
| image_tag="$(make --quiet --no-print-directory tag)$(params.TAG_SUFFIX)" | ||
| ;; | ||
| operator) | ||
| image_tag="$(make -C operator --quiet --no-print-directory tag)$(params.TAG_SUFFIX)" | ||
| ;; | ||
| *) | ||
| echo >&2 "Invalid IMAGE_TAG_STYLE '$image_tag_style'" | ||
| exit 1 | ||
| ;; | ||
| esac | ||
| echo -n "$image_tag" | tee "$(results.IMAGE_TAG.path)" | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Obviously, it would be good to find out a convention suggested by the Konflux team about the way to store tenant-specific trusted tasks so that they don't show up in the list of shared tasks and don't confuse other tenants. Here, additionally, the task starts with
acs-just as well as the existingacs-deploy-check,acs-image-checkandacs-image-scan. The thing is thatacs-determine-image-tagin this PR is tenant-specific one which we need in order to have our ACS builds compliant, the other three are shared tasks that any tenant can use to leverage ACS features in their pipeline. The fact that they all will sit in the same directory with the sameacs-prefix could be confusing.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, we don't want these in build-definitions at all. It should now be possible to put custom, "untrusted" tasks in your pipeline and pass EC checks as long as those tasks do not modify the source code on the way to the build task.
That requires using a Trusted Artifacts-based pipeline. Example pipeline here: https://github.com/konflux-ci/olm-operator-konflux-sample/blob/main/.tekton/single-arch-build-pipeline.yaml
@konflux-ci/mota could probably provide more info.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This task does not modify the source code. It gets the source code on the input and outputs an image tag that we put on the resulting images.
We already use oci-ta tasks and not using workspaces to pass the source code around.
We, however, have some other tasks that download blobs that are included in the source code and then included in the resulting containers.
What would be the plan? Should we skip this task but open PRs for the others that download blobs?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it's generically re-usable, that may be reasonable. But the blobs downloaded by such a task would likely bypass source containers and SBOMs, wouldn't they?
The prefetch task should eventually gain the ability to download arbitrary blobs (while also allowing one to reference the source code for those blobs): https://issues.redhat.com/browse/KONFLUX-2390
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Until then, you might as well make your build non-hermetic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
During ACS CPaaS onboarding, we had a session or two about these blobs. I could find this doc but I think there should be more records and I can dig it out if needed.
Basically, we concluded that since these blobs carry data and no code, we can skip them from source containers.
In present Konflux time, the arrangements might be different and it seems Curlito could fit us.
Thanks, I subscribed to it and linked to ACS Enablement ticket (KONFLUX-258).