Which issue(s) this PR fixes

Fixes: #46

What this PR solves

Adds default endpoint Liveness and Readiness probes to the Python Invoker and Java Invoker. The final state of the PR will involve new Invoker, Buildpack, and Builder releases.

Details for release notes

Add Liveness and Readiness Probes via default endpoint to Python and Java Invokers

Describe testing done for PR

WIP

Test by using the dev builder which includes these changes: us.gcr.io/daisy-284300/kn-fn/functions-builder:0.0.10

Special notes for your reviewer

Currently only available via the default endpoints.

Which issue(s) this PR fixes

Fixes: #29

What this PR solves

Adds tests for our templates

Signed-off-by: Fabian Lopez [email protected]

Which issue(s) this PR fixes

Partially fixes: #30

What this PR solves

Makes templates usable by kn func create

Details for release notes

Create via kn-func can now make use the java and python templates from this repo:
kn func create -r https://github.com/vmware-tanzu/function-buildpacks-for-knative.git -l java -t (cloudevents-maven|cloudevents-gradle|http-maven|http-gradle)
kn func create -r https://github.com/vmware-tanzu/function-buildpacks-for-knative.git -l python -t (cloudevents|http)

Describe testing done for PR

Created a fork for this repo and by making the same changes in this PR to the manifest.yaml I was able to create functions by pointing to my fork with the -r flag

Special notes for your reviewer

As mentioned in the linked issue, there still is the problem of building the generated functions with our buildpacks

Which issue(s) this PR fixes

Fixes: # PDY-809

What this PR solves

Add copyright notice to all files

Details for release notes

Added Makefile targets to easily add the copyright and license notice at the top of files.  
Trigger a check upon PR creation. 

Describe testing done for PR

Manual test of the new github actions.

Special notes for your reviewer

Introduces a common go module from which to share code that is common among buildpacks

• Moves python/java.FuncYaml (and tests) to common config.FuncYaml
• Moves python.CommandRunner to common command.Runner

TODO:

• [x] Change target branch back to main after #137 is merged

Bug Report

The Java builder/buildpack does not pick up func.yaml, resulting in the logic for func.yaml never executing: https://github.com/vmware-tanzu/function-buildpacks-for-knative/blob/0962a3c438e2acefc05960df4db5c646d0d5b124/buildpacks/java/java/build.go#L50

Expected Behavior

func.yaml is copied over to the Java layers and can be accessed and read

Steps to Reproduce the Bug

1. Create a Java image that contains a func.yaml populated with envs and/or options at time of deployment.
2. docker run -it --rm --entrypoint bash <image-name> into the image
3. Check the directories and cd /workspace for the existence of func.yaml

Feature Request

The Python buildpack expects two environment variables MODULE_NAME and FUNCTION_NAME.

Proposed configuration values: BP_FUNCTION: The name of the function to look for. Default: func.main

Alternatively we can instead do: BP_FUNCTION_MODULE BP_FUNCTION_NAME

Which issue(s) this PR fixes

Fixes: #7 and PDY-527

What this PR solves

Add smoke tests for CloudEvents

Details for release notes

Added smoke testing for CloudEvents layers

Describe testing done for PR

Special notes for your reviewer

Which issue(s) this PR fixes

Fixes: Both Python and Java txt-to-pdf samples, docs, and video demos.

Which issue(s) this PR fixes

Fixes: #15

What this PR solves

Revises smoke-tests to work as expected for HTTP, Cloudevents on Java, Python

Details for release notes

Fixes issue with smoke tests for CloudEvents

Feature Request

Right now, we rely on the environment variable PYTHON_HANDLER to be set with a default value of handler.handler. Source

This can create some applications not meant for functions to be picked by the buildpack. We might want to align with the guide of a template described in Template Guide. the template guide describes that all templates will have a `func.yml file.

This file is created by the func cli tool. It is not needed to be in the templates we use to create functions, but it should be in the mechanism of the buildpacks detection.

Describe alternatives you've considered

From the different ways to understand if the current folder/repo is a function type of the buildpacks we built, I think this is the easiest way so far and it will be aligned with the spec of a template folder for the CLI spec guide.

Additional context

This will probably require changes in our sample projects as well

Signed-off-by: Bryan Tong [email protected]

Note: These samples require external applications (Cloud Native Runtimes, Tanzu Application Platform) Contingent on CNR updating their support for TriggerMesh. Was delayed to their 1.4 release.

Feature Request

Since a Java class can have multiple function implementations, we won't be able to automatically determine the default function to use with /. I propose that if there is a func.yaml present and it has a name field, that we use it as the default if it wasn't specified.

Feature Request

Update the Python invoker to handle http status codes. The way to do it currently is to return a Flask.Response object which makes us a leaky abstraction. We want to perhaps update the response we expect from the function to be (status_code, body) or the likes. We need to also consider the situation where we may want to have attributes returned in the case of CloudEvents or whether we want to respond with a specific header.

Feature Request

A way to specify the location of a function within a directory. This is relevant to a monorepo consisting of multiple functions, possibly with multiple directories that could contain your function(s).

This could be something like BP_FUNCTION_SEARCH_PATH or BP_FUNCTION_PATH. We can discuss on what name is appropriate in the comments.

Describe alternatives you've considered

New repo per function and everything is top-level. Applications may have multiple moving parts that are closely related.

⚠️ Still in an early discovery phase

Bug Report

Running a function that expects cloudevents where after processing returns only the body will cause it to throw an exception.

Expected Behavior

No errors + proper attributes are returned.

Steps to Reproduce the Bug

1. Define a function:

   from typing import Any
   
   def main(data: Any, attributes: dict):
       # Your function implementation goes here
       return data
   

2. Run this function with the Python invoker.
3. Send a CE via curl to function.