FIX: Allow builds to reconcile even if the secret doesn't have build.shipwright.io/referenced.secret=true annotation

[kaizakin]

Changes

• updated the controller to reconcile builds even if the secret is created without the build.shipwright.io/referenced.secret=true annotation
• added depreciation comments on the API definition
• removed redundant tests and updated tests to use SecretWithoutAnnotation
• removed Build secret annotation section from the docs since that is not needed anymore.

Edit:

• since the flagReconcile was declared outside the loop and is never reset to false, once a build is referenced by the secret causing all subsequent builds to be falsely queued. updated that as well.

tested it in my local kind cluster

⇛ k apply -f build.yaml
build.shipwright.io/kaniko-golang-build created
⇛ k get builds
NAME                   REGISTERED   REASON                        BUILDSTRATEGYKIND      BUILDSTRATEGYNAME   CREATIONTIME
kaniko-golang-build   False        SpecSourceSecretRefNotFound   ClusterBuildStrategy   kaniko              4s

⇛ k apply -f git-basic-secret.yaml
secret/git-basic-secret created
⇛ k get builds
NAME                   REGISTERED   REASON      BUILDSTRATEGYKIND      BUILDSTRATEGYNAME   CREATIONTIME
kaniko-golang-build   True         Succeeded   ClusterBuildStrategy   kaniko              39s

once the secret is created build automatically reconciles and unregistered build now registers successfully.

Related Issue

Fixes #1725

Type of PR

/kind cleanup
/kind documentation

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Kind label has been set
• Release notes block has been filled in, or marked NONE

Release Notes

Allow builds to reconcile even if the secret doesn't have `build.shipwright.io/referenced.secret=true` annotation

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign heavywombat for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[IrvingMg]

I haven’t looked at the code in detail yet, but from the description it seems that this PR not only fixes the bug, but also makes the annotation no longer useful.

I’m not sure if this should be considered an API change, but it feels a bit aggressive since it changes behavior while fixing the bug.

Maybe it would be better to first focus only on the bug fix, and handle the annotation change separately. What do you think?

That said, I don’t have a strong opinion, so it would be good to get feedback from others.