I have azure functions soution which are tageted to .net 4.6.1 framework.
I deployed soutions using CI pipeline. Have options like Nuget Restore, Build Soution, Archive files and Publish Artifact: drop.
Archive File config:
Publish Artifact: drop -
Below is the configuration i did in Release Pipeline.
Nothing is getting updated from Release Pipeline in fuction app.
In Function App shwoing No Results for Functions. If i publish manually all functions are getting updated correctly in Azure Function App.
Image from Kudu:
b folder is empty.
bin folder contains this data
Getting "2022-08-16T06:11:24.4977098Z : Deployment successful." message in Kudu.
Related
I am creating a new Azure Pipeline to deploy .NET Core API app to an App Service in Azure. I am using connection type=publish profile in the pipeline, which is asking for a .pubxml file.
I have already committed the .pubxml file in my Azure repository.
But while giving the path for getting this .pubxml file, I am suspecting that I can't get .pubxml file through build artifacts. Is there any way to get the .pubxml file from azure repos to release pipeline?
I tried with $(Build.SourcesDirectory)\${{ parameters.Location }}\Properties\PublishProfiles\fcmapapi_Dev%20-%20Web%20Deploy.pubxml but no luck.
Any suggestions?
Step 1: Add Azure Repos / Build artifact with an alias to your release pipeline.
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#artifact-sources
https://learn.microsoft.com/en-us/azure/devops/pipelines/release/artifacts?view=azure-devops#artifact-sources---tfvc-git-and-github
Add "Build" resources as an artifact:
Add "Azure Repository" as an artifact:
Once, you have added both, the classic release pipeline will look like this:
Step 2: Use the three dots to browse the files / packages.
This is a question on how to use a static value for VSTest unit tests run on Azure DevOps Pipeline.
When I develop a unit test that depends on my Web API, I put URL of the Web API hosted on my local dev machine in appsettings.json and this works great. However, when the unit test is run on Azure pipeline, of course it cannot access the Web API hosted on my machine and it fails. I can change the appsettings.json file to point to Web API on Azure but I wish there is a way to always point to the WebAPI on Azure when the unit test is run on the pipeline, overriding the setting in appsettings.json. Is there such a way?
For the Azure pipeline Release, I know I can set variables for app services with Azure App Service Settings task (https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/azure-app-service-settings?view=azure-devops). Not sure similar functionality is available for VSTests.
You can use File Transform task to substitute the variables in appsettings.json file with pipeline variables. See here for more information
So you can add a File Transform task before the build task. Then define a variable(eg. TestData.Url) in your pipeline variables.
See below yaml example.
- task: FileTransform#1
displayName: 'File Transform: '
inputs:
folderPath: '$(system.defaultworkingdirectory)'
enableXmlTransform: false
fileType: json
targetFiles: '**/appsettings.json'
There are other tasks can do the same work. You can check out task Set Json Property, and task Magic Chunks
You can also put the URL of the Web API in the TestRunParameters section of runsettings file or Properties section of testsettings file. And modify your test code to get the URL from testsettings/runsettings files. Then you can use overrideTestrunParameters attribute of Vstest Task to override the URL. See Vstest task document for more information.
You need to have two appsettings files. One for dev (you local test) and the other for production (AzureDevops pipeline).
Like this if you need to make some changes to test locally you change only the dev one.
Recently I am trying to use:
func azure functionapp publish WebAppName --publish-local-settings -i
to publish local.settings.json to a web app (actually an Azure function) but I get this error message:
Unable to find project root. Expecting to find one of host.json in project root.
I have logged in to Azure with az login but it looks like I need to get into the folder where I have deployed the Azure function where all those json files are.
A little background, we are using Octopus Deploy to deploy to an Azure function. After the deployment, we want to add a step so that the local.setting.json will be used to populate app settings.
So how do we change the current folder to be in the Azure function root where all those json files are?
Thanks a lot in advance!
You need to go to your local function project folder to run the command, for example, my function project is under MyFunctionProj folder.
Execute the command
func azure functionapp publish tonyfunc --publish-local-settings -i --publish-settings-only
By the way, if you just want to update the settings, you need add --publish-settings-only parameter.
Reference:
Core Tools development
We have a collection of Azure Function Apps in c# net core. Each App contains a small number of Azure Functions. All Function Apps reside in a single git repository.
We would like some of our environments to deploy automatically from source (e.g. bitBucket or gitHub).
How do we configure the project so that Azure knows which project in source relates to which created Function App?
I have searched around this problem for a number of days and have not seen any results that sit outside of "it just works" so can only assume that we are missing something fundamental.
I'd recommend using Azure DevOps (formerly VSTS) to deploy to Azure, you use YAML to define a build pipeline which can publish an artifact from each of your function apps. The artifacts then get picked up by a release pipeline and can be deployed to Azure.
The basic building blocks of this are, firstly some YAML like this in your build pipeline for each project:
...
steps:
# a script task that let's you use any CLI available on the DevOps build agent, also uses a variable for the build config
- script: dotnet build MyFirstProjectWithinSolution\MyFirstProject.csproj --configuration $(buildConfiguration)
displayName: 'dotnet build MyFirstProject'
# other steps removed, e.g. run and publish tests
- script: dotnet publish MyFirstProjectWithinSolution\MyFirstProject.csproj --configuration $(buildConfiguration) --output MyFirstArtifact
displayName: 'dotnet publish MyFirstProject'
# a DevOps named task called CopyFiles (which is version 2 = #2), DevOps supplies lots of standard tasks you can make use of
- task: CopyFiles#2
inputs:
contents: 'MyFirstProjectWithinSolution\MyFirstArtifact\**'
targetFolder: '$(Build.ArtifactStagingDirectory)'
# now publish the artifact which makes it available to the release pipeline, doing so into a sub folder allows multiple artifacts to be dealt with
- task: PublishBuildArtifacts#1
displayName: 'publish MyFirstArtifact artifact'
inputs:
pathtoPublish: '$(Build.ArtifactStagingDirectory)\MyFirstProjectWithinSolution\MyFirstArtifact'
artifactName: MyFirstArtifact
# now repeat the above for every project you need to deploy, each in their own artifact sub-folder
Next you create a release, which in its simplest form picks up the artifacts and does one or more deployment, here's a simple one which deploys two function app projects:
Within a deployment stage (right hand side above), you can define your release process, again in its simplest form you can just deploy straight to production or to a slot, although until function slots are out of preview you could also spin up another function app and deploy and test there.
This screenshot shows a simple deployment which uses a standard Azure Function App deployment from Azure DevOps:
Within your deployment stage you can define which artifact is deployed and after running your build pipeline for the first time you'll get to see all the available artifacts that it created.
All or parts of the above can be automated from pushing a branch (or other triggers such as on a schedule). Notifications and "gates" can be added as well if you want manual intervention before release or between release stages.
There are also other ways to cut this up, eg with multiple build pipelines, it’s basically completely flexible but the above are the elements you can use to deploy one or more function apps at a time.
We are using VS 2017 on a single solution with multiple projects and we right mouse click and deploy 3 C# Azure Function to two different Azure Function apps with slots.
How do you set up the VSTS build definition to accomplish this on every check in?
We are using the DLLs and setting up the function.json this way. I don’t know if we need to deploy differently based on this type of configuration.
"scriptFile": "..\\bin\\target.dll",
"entryPoint": "target.Application.Run"
I was able to create a VSTS deployment through the following steps
Solutions structure
Build Configuration Steps
Sync from master branch
Added Nuget Restore using default options
Added MSBuild Step with the followign optons
Project : vstsSolution.sln (Selected using '...')
MSBuild Version: Latest
MSBuild Architechture: MSBuild x86
Clean: Checked
Create Log File: Checked
Added App Service Deploy for Function App1
Azure Subscription: Target Subscription
App Service Name: Target Function App
Deploy to slot: If you check this it allows you to select the actual slot you want to deploy to
Package or folder: FunctionApp1\bin\Debug\net461
Added App Service Deploy for Function App1
Package or folder: FunctionApp2\bin\Debug\net461
Make sure you selected "Hosted VS2017" Agent Queue for this build.
All Build Steps
Triggers: Enable Continuous Integration. So that both function app deploy every time you check-in.
Continuous Integration