Change trigger requirement phases

[Rahul-Kumar-prog]

Fixes #7896

Proposed Changes

• previously we do not verify that the trigger is not ready until the PingSource exists.
• we Change trigger phases setup to requirement and add a new setup for DependencyDoesNotExist

Pre-review Checklist

• [ ] At least 80% unit test coverage
• [ ] E2E tests for any new behavior
• [ ] Docs PR for any user-facing impact
• [ ] Spec PR for any new API feature
• [ ] Conformance test for any change to the spec

Release Note

Docs

[knative-prow[bot]]

Hi @Rahul-Kumar-prog. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[Rahul-Kumar-prog]

Hey @pierDipi @Cali0707, please have a look.

[Cali0707]

@Rahul-Kumar-prog it looks like trigger.Get is undefined, which is why the code fails to compile...

What are you trying to do on that line? Maybe we can point you to something that will work there

[Rahul-Kumar-prog]

@Cali0707 I am trying to retrieve data or resource associated with the triggerName. if I get the tigger state then I make decision based on that and at the end if its not able to ready then print error with dependency does not exist.

if you have any other approach please let me know.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 69.51%. Comparing base (2a11bb8) to head (f31ed9c).

:exclamation: Current head f31ed9c differs from pull request most recent head d5104e6

Please upload reports for the commit d5104e6 to get more accurate results.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7946   +/-   ##
=======================================
  Coverage   69.51%   69.51%           
=======================================
  Files         344      344           
  Lines       15999    15999           
=======================================
  Hits        11122    11122           
  Misses       4190     4190           
  Partials      687      687           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Rahul-Kumar-prog]

@Rahul-Kumar-prog the issue mentions TriggerDependencyAnnotation [1] but here we're modifying TriggerWithTLSSubscriber and TriggerWithTLSSubscriberTrustBundle

[1]

https://github.com/knative/eventing/blob/c104df5f482c62a9dc4e3624b7e2891797f25c84/test/rekt/features/trigger/feature.go#L44

I see that in TriggerDependencyAnnotation does not have any setup phase Trigger.IsReady(...). there is one but that is alrady in Requirement phase so I thought that I have to change all Trigger.IsReady(...) setup phase to requirement phase. tell what should I have to do now ?

there is broker.IsReady there in TriggerDependencyAnnotation.

[knative-prow[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

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

[Rahul-Kumar-prog]

@Cali0707 can guide me how to test or reproduce this issue ?

[github-actions[bot]]

This Pull Request is stale because it has been open for 90 days with no activity. It will automatically close after 30 more days of inactivity. Reopen with /reopen. Mark as fresh by adding the comment /remove-lifecycle stale.