Azure / azure-functions-openapi-extension

This extension provides an Azure Functions app with Open API capability for better discoverability to consuming parties

Home Page:https://www.nuget.org/packages/Microsoft.Azure.WebJobs.Extensions.OpenApi/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Empty swagger when using v0.9.0 with solution that includes a test project

buntagonalprism opened this issue · comments

Documentation / Feature Proposal
The fix in #217 to detect the root project has definitely resolved some of the issues with the generated swagger document being empty.

However immediately after upgrading to v0.9.0-preview, using .NET 5 isolated functions, our swagger was empty when our function app was built and deployed from Azure Pipelines. The root cause turned out to be that the fix in #217 was treating our test project as the root project. I suppose this is technically correct since the test project referenced all our other projects.

We were able to work around the issue by updating the build task in our Azure Pipelines yaml file to skip building test projects, so there was no .deps.json produced to be incorrectly detected as the root project.

  - task: DotNetCoreCLI@2
    displayName: Build project
    inputs:
      projects: |
        **/*.csproj
        !**/*Test.csproj   

I thought I'd raise this issue in case anyone else was still having problems with empty swagger, and to propose either of the following solutions to help prevent others encountering the same problem:

  • A documentation update to explicitly state that test projects should not be built for swagger generation to work
  • A feature that the root project detection should ignore test projects

@buntagonalprism Thanks for the tip! I will take a further look. Based on your research and suggestion, I would update the document for now so that others can avoid the similar situations.

Facing the same issue here, using 3.1 Functions and 0.9.0

Looking over #217, it would be a little slower but I'd suggest to load the discovered runtimes and scan for an assembly attribute e.g. OpenApiRootAttribute, to allow developers to override the automatic discovery behaviour.

We were able to work around the issue by updating the build task in our Azure Pipelines yaml file to skip building test projects, so there was no .deps.json produced to be incorrectly detected as the root project.

  - task: DotNetCoreCLI@2
    displayName: Build project
    inputs:
      projects: |
        **/*.csproj
        !**/*Test.csproj   

@buntagonalprism thanks for the work around for this issue. I was wondering how you run your tests in your pipeline if you are not building the test project?

@Alan-Hinton apologies for not replying sooner, I was on holidays at the time of your message.

There is no need to build the test project, the test runner will do what it needs to in order to run the tests.

In our current pipeline rather than using the exclude rule !**\*Tests.csproj we're instead only specifying the function app source project as the input to build command; this still has the same affect of not building the test project and working around the empty swagger issue.

Extract from our YAML pipeline:

  - task: DotNetCoreCLI@2
    displayName: Build project
    inputs:
      command: 'build'
      projects: |
        SRC_PROJECT_NAME/SRC_PROJECT_NAME.csproj
      arguments: --output build_output --configuration Release

  - task: DotNetCoreCLI@2
    displayName: Run tests
    inputs:
      command: 'test'
      projects: '**/*Tests.csproj'
      publishTestResults: true
      arguments: '--collect:"XPlat Code Coverage"'

please note the initial pattern specified in this issue point to **/*Test.csproj instead of **/*Tests.csproj

Just in case you copy and paste like I did :)

The current situation feels problematic.
What about scenarios where you have to build and deploy tests, have anyone found other workarounds?

I agree with @jasiozet, at this point in time we are still not able to deploy our tests with our code. This remains an issue..

Please fix this. Not able to access the swagger UI in 2023 because of this issue.