Added func subscribe support to raw deployer

[24aysh]

Changes

🎁 Add new feature - Event subscriptions now work with --deployer raw

Summary

This PR implements Knative Trigger creation for the raw Kubernetes deployer

What Changed

Modified File: pkg/k8s/deployer.go

/kind enhancement

Fixes #3272

Release Note

Event subscriptions now work with raw Kubernetes deployer (`--deployer raw`). 

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: 24aysh
Once this PR has been reviewed and has the lgtm label, please assign jrangelramos 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

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: 24aysh / name: ayush (0e28e17, 4b87f9e, 660161a)

[knative-prow]

Welcome @24aysh! It looks like this is your first PR to knative/func 🎉

[knative-prow]

Hi @24aysh. Thanks for your PR.

I'm waiting for a github.com 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.

Details

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.

[intojhanurag]

/ok-to-test

[matejvasek]

It would be neat to have some tests for this.

[24aysh]

It would be neat to have some tests for this.

sure i'll add them

[codecov]

Codecov Report

❌ Patch coverage is 62.60870% with 43 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.57%. Comparing base (4f9f7b8) to head (0e28e17).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/k8s/deployer.go	62.60%	34 Missing and 9 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3335      +/-   ##
==========================================
+ Coverage   55.47%   55.57%   +0.09%     
==========================================
  Files         173      173              
  Lines       20112    20225     +113     
==========================================
+ Hits        11158    11240      +82     
- Misses       7833     7857      +24     
- Partials     1121     1128       +7     

Flag	Coverage Δ
e2e	40.89% <74.72%> (+1.29%)	⬆️
e2e go	35.16% <0.00%> (-0.22%)	⬇️
e2e node	30.97% <0.00%> (-0.20%)	⬇️
e2e python	34.67% <0.00%> (-0.24%)	⬇️
e2e quarkus	31.12% <0.00%> (-0.20%)	⬇️
e2e rust	30.52% <0.00%> (-0.20%)	⬇️
e2e springboot	28.94% <0.00%> (-0.23%)	⬇️
e2e typescript	31.09% <0.00%> (-0.20%)	⬇️
integration	18.61% <15.38%> (-0.02%)	⬇️
unit macos-14	44.51% <13.18%> (-0.18%)	⬇️
unit macos-latest	44.51% <13.18%> (-0.18%)	⬇️
unit ubuntu-24.04-arm	44.64% <13.91%> (-0.18%)	⬇️
unit ubuntu-latest	45.39% <13.18%> (-0.18%)	⬇️
unit windows-latest	44.53% <13.18%> (-0.18%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[matejvasek]

It would be neat to have some tests for this.

sure i'll add them

btw I think @Kunal1522 works on subscription tests here #3324 maybe you can re-use that.

[24aysh]

It would be neat to have some tests for this.

sure i'll add them

btw I think @Kunal1522 works on subscription tests here #3324 maybe you can re-use that.

cool, i'll take a look, i will do that within 1-2 days, right now i'm busy with my college stuff

[24aysh]

/test unit-tests

[24aysh]

cc @matejvasek

[24aysh]

Thanks for the submission.

Let me see if I can summarize what's outstanding:

1. Address the subscription sync question (create/update/delete to match desired state)
2. Fix linter errors (pre-allocate slices)

Nice to have:

1. Enable integration tests for raw deployer
2. Clean up empty unit tests
3. Reuse clientset config

The core seems solid and follows our existing style; thank you. The gap in functionality is the sync logic for trigger lifecycle management.

Essentially "what happens when subscriptions change". Perhaps we could use a managed-by annotation?

const (
    managedByAnnotation = "func.knative.dev/managed-by"
    managedByValue      = "func-raw-deployer"
)

On deploy:

1. Create or update all triggers defined in func.yaml (with the annotation)
2. List existing triggers for this function that have func.knative.dev/managed-by=func-raw-deployer
3. Delete any from that list that aren't in the current func.yaml subscriptions

This way:

• Triggers created out-of-band (manually, via GitOps, etc.) are never touched
• Stale triggers from previous deploys get cleaned up
• It's idempotent and safe for repeated deploys

The Knative deployer does something similar. You could add the annotation in your ObjectMeta:

ObjectMeta: metav1.ObjectMeta{
    Name: triggerName,
    Annotations: map[string]string{
        "func.knative.dev/managed-by": "func-raw-deployer",
    },
    OwnerReferences: []metav1.OwnerReference{...},
},

Thoughts? Looking good so far!

looks cool, i will implement this, also i did implementation to reruse clientset config in recent commit

[24aysh]

ready for review @gauron99 @lkingland

[24aysh]

/retest

[gauron99]

is there a function name annotation as well here? because if there are 100 functions on cluster, they would all have this managedBy Annotation IIUC? We would be checking multiple functions here and they could have the same trigger name? OR (more probable) we would delete triggers from different functions?

[24aysh]

yeah that's a flaw here, i need to update it