In Azure DevOps I have a build pipeline which creates an archive of a project containing two Azure Functions. I then have a release pipeline which deploys this zip archive to the Function App.
The release pipeline was built using the DevOps template for deploying a Function App.
The release runs without any errors and does deploy the dropped artifact. However, if I then look at the Function App in the portal I see the message
Your app is currently in read only mode because you have source control integration enabled.
I wasn't too concerned about this because I don't intend to modify the code in the portal - my assumption is that the read-only state means that I can't modify the function in the portal, right?
And then I also noticed this...
Why is one of the functions Disabled, and how can I deploy so that it is enabled?
Please enable your function and try again. Deployment should not disable your function, so maybe it was disabled in other way. I tried and it works like this.
It seems the warning is not related to the function status. You can use the Enable and Disable buttons on the function's Overview page. These buttons work by changing the value of the AzureWebJobs.<FUNCTION_NAME>.Disabled app setting. This function-specific setting is created the first time it's disabled.
Check documentation here:
https://learn.microsoft.com/en-us/azure/azure-functions/disable-function#use-the-portal
Regarding the warning, if the function is 'deployed' to Azure, what will be deployed is the compiled file. So this is why it is readonly.
Changes to the code should be done before compiling them into corresponding 'cannot be edited' files, which requires special attention.
But for the modification of the declarative part and the configuration part of the function, this is possible.
Detailed information, you can refer to the following case:
Azure Functions App is Read Only after publishing
Related
There are tons of resources online on how to replace JSON configuration files in a release pipeline like this one. I configured this. It works. However, we have multiple integration tests which reach the database too. These tests are run during build time. I haven't seen any option yet to replace config values in the build pipeline. Does it exist? Or do I really have to use this custom task (see screenshot below)?
There is an out-of-the-box task since recently by Microsoft. It's called File Transform. It's currently in preview but it works really well! Haven't had any issues whatsoever with it and it works the same as you would configure it in the release pipeline. Would recommend this any day!
Below you can see my configuration.
There is no out-of-the-box task only to replace tokens/values in files (also in the release pipline the task is Azure App Service Deploy and not only for replace json configuration).
You need to use an external extension from here or write a PowerShell script for that.
I'm deploying an azure function app from package (using this guide - https://learn.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package) - this deploys correctly. Yet I can't seem to get an update deployed. Even after I upload a new package, changes are not picked up by azure function app. I tried stopping/starting the app to no avail.
How can I force it to pick up changes?
I ran into this issue with a newly deployed function using function v3, so this still seems to be an issue.
Short answer:
Remove the .zip in D:\home\data\SitePackages and then redeploy and your changes will get picked up.
Long answer
My setup is using ZIP deployment and WEBSITE_RUN_FROM_PACKAGE = 1.
It helps to know what happens when you use ZIP deployment:
The zip file is not written to wwwroot of your site, but instead to D:\home\data\SitePackages (source: https://learn.microsoft.com/en-us/azure/azure-functions/run-functions-from-deployment-package)
Then the contents of the zip file is mounted to D:\home\site\wwwroot and run from there.
For some reason, the .zip in D:\home\data\SitePackages was not being replaced, it was still the old version. To fix that, I used the Console of the App Service to delete the file before redeploying.
Navigate to your App Service function and open the Console (under Development tools section)
Run cd D:\home\data\SitePackages and then ls to see the files in the folder.
Run a rm command to remove both the zip and text file.
Redeploy your function, and you will see that changes are picked up.
We had a very weird problem using Azure Function App Deploy from Azure DevOps.
This worked perfectly until we one day made some code changes to the Azure Function that worked locally but not on our dev server. We started looking at the .zip file and the release pipeline but everything looked good here. We could also see that nothing had changed in our azure-pipelines.yml or release pipeline:
Git command: git log -p azure-pipelines.yml
For releases we used the Azure Functions task by Microsoft Corporation.
Looking at the release logs everything seemed good as well:
We then logged in to Kudu (Advanced Tools) and used powershell to look at the files deployed.
https://<your-function>.scm.azurewebsites.net/DebugConsole/?shell=powershell
Running the command dir D:\home\site\wwwroot we could see that the files had not been updated and when we looked at dir D:\home\data\SitePackages we could not see a new .zip file either.
Confirmed wrong .zip by running the command Get-Content D:\home\data\SitePackages\packagename.txt to see which .zip is being used.
Then wen't back to Azure DevOps and tried to create a new release but the files still did not update. Then I tried to clone the Azure Function App Deploy step that had previously worked and disabled the other one. Tried a new release and now everything worked.
I think this must be a Microsoft bug since we did not really change any values at all. Hope this can help someone else and that Microsoft fixes this.
If you replace old package using new one with the same package name(to leverage the same sas url), make sure the old one is overwritten. And you have to click the refresh button next to Function app to sync triggers along with the changes.
Update
I recommend using the publish command(func azure functionapp publish <functionAppName>) provided by Azure Function Core Tools(Cli). V2 Cli benefits from Run from package as well and automates the whole process for us(zip the folder, upload, create app setting, sync triggers).
The command get publishing info(username, password for deployment) first, then
Archives function project.
Uploads zip file(name is in the format of UTCTime-GUID.zip) to function-releases container in Storage account specified by AzureWebJobsStorage app setting.
Create an app setting WEBSITE_RUN_FROM_ZIP(original name of WEBSITE_RUN_FROM_PACKAGE, both work) with SAS Url.
Sync triggers to pick up changes.
After all efforts, the only thing I really determined was that you need to restart - and then wait. About 15-20 minutes after restart the changes were automagically there.
If you try to deploy with new JAR/ZIP to function-app , the changes will be reflected within 1-2 mins
* Make sure that you are using correct value for WEBSITE_RUN_FROM_PACKAGE
* Download the content from console and check whether its same or not
I had the same problem, after changing the deployment to use WEBSITE_RUN_FROM_PACKAGE. I think the problem is that it is using the cached deployment tool, so it's using the previous deployment script, not a new one when you change how you want it to deploy.
If you look at the deploy log in azure devops there is a link to the deploy log in the kudu interface:
I found this answer which explains how to fix it.
I'm using an Azure DevOps Pipeline to release an ASP.NET MVC system to an Azure Web App.
I've configured the build not to apply the XML transforms, so I can apply them later, during the release step, and the same build artefact can be released to multiple environments.
The build works fine, and I end up with an artefact containing an untransformed web.config, and the environment-specific transform files.
The Azure App Service Deploy task has a check-box called XML Transformation, which displays the following help text:
The config transforms will be run for *.Release.config and
*.<EnvironmentName>.config on the *.config file. Config transforms will be run prior to the Variable Substitution. XML transformations
are supported only for Windows platform.
At the moment I'm trying to set up a release into a test environment, but the Web.Release.config is being applied, rather than the Web.Test.config. I've searched everywhere I can find for a place to define the environment to make the release use the test config, but I can't find anywhere.
There's a similar question on GitHub which shows the following screenshot:
Unfortunately mine doesn't look like that:
Am I trying to do the right thing? If so, where do I set the environment?
You need to make sure your stage name is just 'Test' and not 'Deploy EMS to Test', reference here.
This article shows one step closer to an efficient and effective continuous integration workflow for an Azure function. (Thanks to Donna M from Microsoft).
https://blogs.msdn.microsoft.com/appserviceteam/2017/03/16/publishing-a-net-class-library-as-a-function-app/
Rather than re-create our azure functions as web applications, we would like to know exactly what needs to be included in a repository for Kudu or the Azure Function Runtime to automatically perform Nuget Restore and then build the project. Ideally, we could just add whatever is needed to our projects to satisfy the build system.
Previously we had a deploy.cmd script in our repositories according to the Azure Web App convention to orchestrate the restore and build ourselves. It worked in January because Azure Functions are built on web apps, however that has stopped working recently and we found that the folder structure has been rearranged a bit (probably due to the fixes they implemented for locking of .dll files). We understand that deploy.cmd was never officially supported, so we'd just like to know how to modify our existing projects to work in the current version of Azure Functions.
Here's a really good answer on all things nuget & functions deployment:
How can I use NuGet packages in my Azure Functions?
Nuget restore and project build should happen automatically for .csx function apps.
All you need is to follow the folder structure conventions. Here's an example:
Function1/
function.json
run.csx
other.csx
project.json
Function2/
function.json
run.csx
project.json
Shared/
shared.csx
host.json
To make sure that Shared folder code is watched for changes, add Shared to watchDirectories in host.json.
I have created an Azure Web Site and connected it to Visual Studio Online, and this automatically set up a continuous deployment build (as per this page).
Initially this worked for a solution with one project, but now I have added a Web API project as a back end. This is named such that it is the first of the two projects alphabetically, and so now it is the only project that gets built and deployed whenever files are checked in. Which leads to my question:
How can I modify the default continuous deployment build to deploy both applications?
I'm sure it must be a fairly simple change to either the build template or parameters, or the publish profiles that are being used by the build. The only problem is I don't know: A) how to change those settings in the default TfvcContinuousDeploymentTemplate.12.xaml build template, and B) how to modify the publish profiles that are used in the continuous deployment build.
I have already, from within Visual Studio, manually published the two projects and got them to deploy to the right locations by following the instructions in this answer. I right-clicked on each project, clicked publish, then selected the "Microsoft Azure Web Apps" publish target which (after filling in all the settings) added the publish profiles to my projects and allowed me to manually deploy them how I wanted.
Unfortunately there seems to be no way to re-upload those publish profiles so that they can be used in the CD build. I've checked them into source control, I just need to know how I can get the CD build to make use of them. How can I do this?
After reading through the first link in my question again, I noticed that you can edit the build definition (or template) to point to the publish profile that you want to use:
Path to Deployment Settings: The path to your .pubxml file for a web app, relative to the root folder of the repo. Ignored for cloud services.
Unfortunately, this both doesn't work and only allows you to specify one publish profile file. Presumably, even if specifying this argument worked, the build would still only deploy the first app in alphabetical order.
This lead me to this question and answer though, which suggests that the Azure/TFVC continuous deployment works simply by using the ordinary Web Deploy arguments to MSBuild. Looking at the diagnostic logs of my build in Visual Studio Online proved this to be the case; here are the relevant arguments:
C:\Program Files (x86)\MSBuild\14.0\bin\amd64\msbuild.exe /p:DeployOnBuild=true /p:CreatePackageOnPublish=true /p:DeployIisAppPath=mysitename
So, as per that question, to use a specific publish profile you can just set the additional necessary MSBuild arguments in the build definition:
Each project needs to have a publish profile called "publishprofilename.pubxml", in this case, checked into source control. I found that the user name (which is your site name with a dollar sign in front of it) is not needed, but unfortunately the password string is required. If you don't include it you get an error like this in the build:
Web deployment task failed. (Connected to the remote computer
("[mysitename].scm.azurewebsites.net") using the Web Management Service,
but could not authorize.
No other arguments were required for me, but it doesn't seem ideal that the password has to be included. The default deployment setup, without using publish profiles, must be authorising with that password somehow, but I don't know how.
So after making this change I navigated to [mysitename].azurewebsites.net, and it appeared that still only the Web API project was being deployed. However, by going to console for the site and entering dir D:\home\site\wwwroot I can see that both projects are actually being deployed. It's just that both projects are being deployed to the root of the site, at D:\home\site\wwwroot. The DeployIisAppPath settings are different in each publish profile, but these values are being ignored. This is because the /p:DeployIisAppPath=mysitename argument to MSBuild (mentioned above) overrides any PropertyGroup settings in publish profile *.pubxml files, as described in this blog post.
What I have found is that the continuous deployment process for Azure/TFVC works by having an InitializeContinuousDeployment build activity in the TfvcContinuousDeploymentTemplate.12.xaml build template, immediately before the RunMSBuild activity. This takes the MSbuild arguments you specify in the build definition, and appends to them the ones needed to deploy to Azure. Unfortunately, this is mostly hard-coded, and that means it always specifies a single deployment path for all web projects in the solution. You can't deploy each web app to a different location using publish profiles alone.
So one workaround option is to add something like a BeforeBuild MSBuild target to each project, to override the command line value of DeployIisAppPath. The problem with this is that the path specified in the publish profile, and seen in the publish wizard, will no longer be the path actually being used for deployment.
So the solution I went with is marginally better; it is what we would describe in New Zealand as "huckery".
Basically I added an InvokeMethod build activity between the InitializeContinuousDeployment and RunMSBuild activities. The arguments for this activity are as follows:
DisplayName:
Configure build for using publish profiles (removes DeployIisAppPath MSBuild parameter)
GenericTypeArguments:
System.String
MethodName:
SetValue
TargetObject:
AdvancedBuildSettings
Parameters:
Direction: Type: Value
In String "MSBuildArguments"
In String String.Join(" ", AdvancedBuildSettings.GetValue(Of String)("MSBuildArguments", String.Empty).Split(New String() {" "}, StringSplitOptions.RemoveEmptyEntries).Where(Function(s) Not s.StartsWith("/p:DeployIisAppPath=")))
What this does is removes the DeployIisAppPath argument from the MSBuild command line arguments list completely, so that it doesn't override this same property in the publish profiles. Instead of the messing around with splitting and joining the string, it would be slightly nicer if you could just append /p:DeployIisAppPath="" to the command line, but this just sets the property to an empty string and you get an error:
"ConcatFullServiceUrlWithSiteName" task was not given a value for the
required parameter "SiteAppName"
So like I said, pretty huckery, but it's a solution that allows you to have continuous deployment of multiple web projects to Azure with a minimal amount of changes to the default setup.
You can override the deployment engine in Kudu by using the Azure CLI Tools. Running the azure site deploymentscript command and passing in the parameters for one of your projects -s <solutionFile> --aspWAP <projectFilePath>.
This will create a .deployment file and a deploy.cmd (or deploy.sh if you pass the -t bash parameter) modifying the deploy.cmd to add build/deploy steps for the second project.
More information is on deployment hooks is available in the project kudu wiki.
EDIT
You can use App Setting COMMAND to add a deployment script to your site.