We currently have a GitHub Actions workflow for the Java SDK. However, we don't have one set up for Azure Functions yet. We should add this to ensure any changes we make don't break Azure Functions scenarios.
Here are my suggestions for this work item:
Create a new Durable Functions Java sample app with some HTTP triggers that run some orchestrations. Ideally these will be used for our documentation samples as well as automated testing. Importantly, it should reference the locally built version of the Java SDK and annotations.
Create a Dockerfile that containerizes the sample app.
Create a new integration test project under azurefunctions that runs the sample app's orchestration via its HTTP triggers.
Add a new job to the existing build-validation.yml workflow to build this docker image and run these tests as part of the CI.
Here's an example workflow definition that demonstrates how we can setu up and run a containerized Function app as part of a CI job. The actual setup logic is implemented as a PowerShell script so that it can be run locally. It does a few important things for us:
It builds the docker container, which references the local build
It pings the function app container to ensure that it could start up successfully.
The script then runs a simple orchestration test. However, instead of doing this from the script, I suggest we use a /gradlew test command to execute tests as a separate step in the GitHub action workflow job. That will make it easier to analyze the results.
As a final step, we should probably dump the container logs so that we can debug any issues that arise more easily. Alternatively, we could configure the function app to publish logs to Application Insights, which might make it easier to query for issues compared to digging through text logs.
We currently have a GitHub Actions workflow for the Java SDK. However, we don't have one set up for Azure Functions yet. We should add this to ensure any changes we make don't break Azure Functions scenarios.
Here are my suggestions for this work item:
Dockerfilethat containerizes the sample app.Here's an example workflow definition that demonstrates how we can setu up and run a containerized Function app as part of a CI job. The actual setup logic is implemented as a PowerShell script so that it can be run locally. It does a few important things for us:
The script then runs a simple orchestration test. However, instead of doing this from the script, I suggest we use a
/gradlew testcommand to execute tests as a separate step in the GitHub action workflow job. That will make it easier to analyze the results.As a final step, we should probably dump the container logs so that we can debug any issues that arise more easily. Alternatively, we could configure the function app to publish logs to Application Insights, which might make it easier to query for issues compared to digging through text logs.