Azure Function App - Functions Not Visible After GitHub CI/CD Deployment

Question

Function Discovery

Why are functions discovered correctly after manual deployment but not after GitHub Actions deployment?

Is there a known issue with .NET 10 Azure Functions and GitHub Actions deployment?

Are there additional requirements for metadata generation when deploying .NET 10 isolated Functions through CI/CD?

How can we verify whether Azure is receiving a valid Function package during OneDeploy deployment?

Is there a way to validate the uploaded package from Kudu when WEBSITE_RUN_FROM_PACKAGE is enabled?

Can Azure runtime logs indicate why functions are not being indexed after deployment?

Which logs should be reviewed to diagnose function indexing failures?

GitHub Actions Deployment

Is GitHub Actions using OneDeploy deploying a package differently than manual deployment from Visual Studio?

Are there any recommended deployment settings for:

Azure/functions-action@v1

when targeting .NET 10 isolated worker Functions?

Should Zip Deploy or Run From Package be configured differently for .NET 10 Function Apps?

Is there a recommended build configuration to ensure function metadata generation during GitHub Actions builds?

Requested Support

Please help identify:

Why functions are successfully discovered after manual deployment but are not discovered after GitHub Actions deployment, even though the deployment completes successfully and WEBSITE_RUN_FROM_PACKAGE is enabled.

Additionally, please provide guidance on validating the deployment package and runtime indexing process for .NET 10 isolated Azure Functions deployed via GitHub Actions.

Function Discovery

Why are functions discovered correctly after manual deployment but not after GitHub Actions deployment?

Is there a known issue with .NET 10 Azure Functions and GitHub Actions deployment?

Are there additional requirements for metadata generation when deploying .NET 10 isolated Functions through CI/CD?

How can we verify whether Azure is receiving a valid Function package during OneDeploy deployment?

Is there a way to validate the uploaded package from Kudu when WEBSITE_RUN_FROM_PACKAGE is enabled?

Can Azure runtime logs indicate why functions are not being indexed after deployment?

Which logs should be reviewed to diagnose function indexing failures?

GitHub Actions Deployment

Is GitHub Actions using OneDeploy deploying a package differently than manual deployment from Visual Studio?

Are there any recommended deployment settings for:

Azure/functions-action@v1

when targeting .NET 10 isolated worker Functions?

Should Zip Deploy or Run From Package be configured differently for .NET 10 Function Apps?

Is there a recommended build configuration to ensure function metadata generation during GitHub Actions builds?

Requested Support

Please help identify:

Why functions are successfully discovered after manual deployment but are not discovered after GitHub Actions deployment, even though the deployment completes successfully and WEBSITE_RUN_FROM_PACKAGE is enabled.

Additionally, please provide guidance on validating the deployment package and runtime indexing process for .NET 10 isolated Azure Functions deployed via GitHub Actions.

Answer 1

Hi @Sherry L. Robinson ,

Thanks for reaching out to Microsoft Q&A.

1. Verify you’re using the correct GitHub continuous deployment model

Azure Functions “continuous deployment” is supported via the Deployment Center integration, which triggers build, packaging, and deployment when a commit is pushed.

In the portal:

• Go to your Function App → Deployment Center
• Confirm Source = GitHub
• Confirm the provider is GitHub Actions (if needed, use Change provider → GitHub Actions)
• Confirm the GitHub repo/branch mapping and that the account has write access

If the repo/branch wiring is slightly off, you can end up with a successful deployment of a package that doesn’t contain what you expect (even if the pipeline says “success”).

2. Confirm your CI/CD workflow uses the expected repo layout / packaging expectations

Azure Functions notes that for continuous deployment to succeed, the project directory structure must be compatible with the folder structure Azure Functions expects. Also, the unit of deployment is the function app, and all functions in the app are deployed “at the same time and in the same package.”

So, if a CI build produces a different output folder structure than your manual process (for example, metadata/artifacts not ending up in the final package), the app may deploy a package that doesn’t contain the function definitions Azure expects to index.

3. Treat Deployment Center continuous deployment as “code-only” source of truth

Once you enable continuous deployment, the Azure portal function code becomes effectively read-only and Azure expects the “source of truth” to be your repo.

This matters because “manual deployment” may overwrite code differently than the CI/CD pipeline especially if CI/CD generates a package from different build steps or different configuration.

4. Validate credential/config differences that commonly cause “host behavior” problems

GitHub Actions needs the publish profile (or other configured auth) and that you must ensure the credentials and workflow file are present/working correctly.

Confirm if required settings are present/consistent:

• Function App → Application settings (especially for bindings/any required dependencies)

Ensure:

• the GitHub workflow is generated and present in github/workflows/
• deployment credentials are correctly added as a GitHub secret named:
  • AZURE_FUNCTIONAPP_PUBLISH_PROFILE
• the generated workflow matches the function app runtime/config (“Review the generated workflow template and ensure it matches your function app’s runtime and configuration.”)

Hope this helps!

---

If the resolution was helpful, kindly take a moment to click on and click on Yes for was this answer helpful. And, if you have any further query do let us know.