Handle building unsigned containers

[tnevrlka]

• source-container-build fails fatally if the containers are unsigned
• Users should still be able to build even if they are unsigned (EC checks will still fail though)

[chmeliik]

source-container-build fails fatally if the containers are unsigned
Users should still be able to build even if they are unsigned

Was the intention of the story to skip unsigned base images, or to use them even if they're unsigned?

(EC checks will still fail though)

Will they? I'm not sure if there's an EC check for base image sources being included

[chmeliik]

source-container-build fails fatally if the containers are unsigned
Users should still be able to build even if they are unsigned

Was the intention of the story to skip unsigned base images, or to use them even if they're unsigned?

(EC checks will still fail though)

Will they? I'm not sure if there's an EC check for base image sources being included

I checked how we currently set the base_image_source_included property. If the script doesn't find a source container for the base image at all, it will be false, otherwise true. With this, we would be adding a case of "the source container was there, but we failed to pull it (possibly due to temporary problems)" -> false.

I also checked https://github.com/enterprise-contract/ec-policies/ and https://github.com/release-engineering/rhtap-ec-policy for occurrences of base_image_source_included and didn't find any rules.

This introduces two problems

• Until an EC check exists, this would make it possible to release builds with missing base image sources even when the source container for the base image does exist
• There wouldn't really be a sane way to implement said EC check, because the base_image_source_included=false could mean both "base image sources don't exist" and "the build just failed to pull them"

Thinking about this more, maybe we could do something different than ignore the skopeo copy failure. Maybe we want to handle this in the Tekton task. If the python script fails, don't fail the whole task but do something similar to the scan tasks - succeed and return a TEST_OUTPUT Tekton result to indicate the failure. Then, EC would block releases because
a) TEST_OUTPUT indicates failure
b) the task probably failed to build the source container, and I believe EC does verify the existence of it

[chmeliik]

But TBH, I also wouldn't mind leaving things as they are and letting the source-build task fail on failure 😄 (using TEST_OUTPUT here feels like abusing it)

IMO we should ask Ralph what his expectations were about the "graceful failure"

[ralphbean]

The original idea in Konflux ADR 14. Let Pipelines Proceed was that we want users to get functionally testable builds out of their pipeline as frequently as possible, even in the face of other failures so that scanning or linting issues don't prevent them from at least making progress in validating the functional state of their product. They might be blocked from releasing, but at least they won't be blocked from testing or messing around with their artifact in a dev environment.

How do you see that idea apply or not apply here?

[chmeliik]

The original idea in Konflux ADR 14. Let Pipelines Proceed was that we want users to get functionally testable builds out of their pipeline as frequently as possible, even in the face of other failures so that scanning or linting issues don't prevent them from at least making progress in validating the functional state of their product. They might be blocked from releasing, but at least they won't be blocked from testing or messing around with their artifact in a dev environment.

How do you see that idea apply or not apply here?

Unlike scanning and linting, source-container build failures will usually be intermittent. It doesn't seem right in general to let those proceed, since the solution will be a retry. And if we let the pipeline proceed, then the feedback loop won't be just to keep retrying the build but will also involve waiting for the release pipeline to succeed/fail.

[chmeliik]

Unlike scanning and linting, source-container build failures will usually be intermittent. It doesn't seem right in general to let those proceed, since the solution will be a retry. And if we let the pipeline proceed, then the feedback loop won't be just to keep retrying the build but will also involve waiting for the release pipeline to succeed/fail.

But maybe we can re-consider if we want to fail the source builds because of missing signatures. During the build step, buildah pulled the base images without complaining, so perhaps the source-build step shouldn't care about the missing signatures either.

[mmorhun]

I think we can have a task parameter that would control if the task should fail or not on missing signature. I'd keep fail as the default behaviour, but if a user wants to proceed with the build and skip the source image build problem for now, they still can.

[tnevrlka]

Hi @ralphbean, what do you think about the proposed solutions?

[tnevrlka]

@chmeliik Would you be okay with the task parameter?

[chmeliik]

@chmeliik Would you be okay with the task parameter?

Sounds okay. Just to clarify what it would do: IMO when set to ignore missing signatures, the source build task should download the parent image even if it's unsigned