When deploying to an Azure functions app using the devops task AzureFunctionApp#1, there is an option to supply a runtimeStack. When I choose JavaScript it automatically inserts the runtimeStack as shown below
- task: AzureFunctionApp#1
runtimeStack: 'DOCKER|microsoft/azure-functions-node8:2.0'
My linux functions app is running node 12/runtime 3.0 and the deployment is zip. This is inserted as node8 and runtime 2.0. Is this correct? It doesn't match the version I am using but the Azure editor highlights it as an error if I change it to anything else.
Answering my own question here, but looks like this is a bug in the azure tasks UI and will be fixed soon
https://github.com/microsoft/azure-pipelines-tasks/commit/ae348864ae539a2c84c49b1e6bd499ce92b90356
Related
Added a new VSTS extension to vsts marketplace https://marketplace.visualstudio.com/items?itemName=ManishSingh.soapuiazure&ssr=false#overview
I am able to install this extension on organization but not able to see this in task list to add in pipeline.
Got some way to fixed this on internet like uninstall and reinstall - Didn't worked
Disabled and enable - didn't worked.
The extension uses the deprecated PowerShell v1 execution handler for Azure Pipelines and needs to be upgraded to the Powershell3 execution handler. The v1 handler is from the era of the v1 agent that shipped in 2015 and was replaced by a complete rewrite in the summer of 2016.
##[warning]Task 'SoapUI on Azure' (2.0.6) is using deprecated task execution handler. The task should use the supported task-lib: https://aka.ms/tasklib
For me the task fails to show up in the YAML task helper, but it does show up in the classic UI based pipelines and releases.
You may be able to just make it work when using the Get YAML helper in the classic UI:
steps:
- task: ManishSingh.soapuiazure.5ad1e1bc-7ee6-49c8-b12f-7b7606c5b0e4.SoapUI on Azure#2
displayName: 'SoapUI project.xml'
Then simplify that to:
steps:
- task: SoapUI on Azure#2
displayName: 'SoapUI project.xml'
^^^^
Tested this and it works.
But it looks like this extension could use some love. I already see a few things wrong with it:
Using deprecated task handler
always downloads SOAPUI from blob storage (useful for Hosted agents, but not for persistent agents)
Manifest issues
space in Task Name (task.json)
guid in Task ID (in vss-extension.json)
Some of these are likely unfixable, cause the marketplace makes it very hard to change identifiers once the task is published publicly.
Test to install the same extension and it will show the task: Soap UI on Azure in the task list.
For example:
You can add the task to Agent Job or Deployment Job.
On the other hand, if you are not able to find the task after installing it, you can try to open a Browser InPrivate Window and use the same steps to search the task in Azure Pipeline.
Basically I am looking for a way to deploy azure fabrics where services are updated based on nothing but the version number.
I am working on deploying a service fabric application via azure devops. I have written a script that does a diff and updates the version numbers on ApplicationManifest.xml and ServiceManifest.xml. This script has been tested and it updates the versions correctly for the services that have been changed.
Now, when I try to deploy, I get the following error message:
##[error]The content in CodePackage Name:Code and Version:1.0.111 in Service Manifest 'MyMicroServicePkg' has changed, but the version
number is the same.
This error message keeps showing for one service after another until I have updated the version on every single package. Basically it is forcing me to update every single package.
Here is the publish profile I am using:
<?xml version="1.0" encoding="utf-8"?>
<PublishProfile xmlns="http://schemas.microsoft.com/2015/05/fabrictools">
<ClusterConnectionParameters .... />
<ApplicationParameterFile Path="..\ApplicationParameters\PublishProfName.xml" />
<CopyPackageParameters CompressPackage="true" />
<UpgradeDeployment Mode="Monitored" Enabled="true">
<Parameters FailureAction="Rollback" Force="True" />
</UpgradeDeployment>
</PublishProfile>
Here is the devops task on yaml:
- task: ServiceFabricDeploy#1
inputs:
publishProfilePath: $(publishProfilePath)
applicationPackagePath: $(applicationPackagePath)
serviceConnectionName: ${{ parameters.connection }}
overrideApplicationParameter: true
upgradeMode: Monitored
FailureAction: Rollback
# 30 mins timeout
UpgradeTimeoutSec: 3600
I have looked up this issue online. Generally people talk about how to make sure all services with code changes have versions updated. In my case, I am positive the versions are updated for the changed services.
How do I configure the deployment such that it does not do any code comparison and updates only the services that have an updated version?
The gist of the answer here, based on my experience, is that Service Fabric only deploys the entire application as a single versioned collection of each of the internal packages, but leaves specifics of service deployment accessible to you for customization. So even if you haven't made changes to a single service within that application, ultimately it's still going to be bundled up in the application deployed to the cluster and you're still going to have to make a decision about whether to deploy the service or not (or use the provided Deplooy-FabricInstaller.ps1 script to handle such deployments).
My suggestion (based off my own pipeline) is that if you really trust that your script is detecting changed versions properly and you really want to avoid upgrades for services you haven't made changes to (presumably to cut down on deployment time) is to shift around your approach and instead don't fight the application deployment and instead optimize service installation.
Build the solution as you normally would, and utilize the ServiceFabricUpdateManifests#2 task to let it replace all the versions of each service automatically.
At this point, I generally diverge from the standard pipeline.
I've got a script that removes the DefaultServices from ApplicationManifest.xml to remove automatic service deployments
I run a separate script that checks to see if the application already exists or not (to inform whether it's a fresh deployment or an upgrade)
Based on it being an install/upgrade I take a different deployment task route and capture information about the existing services in the cluster
Once the application has been fully deployed, I wrote a custom script that's similar to the included Deploy-FabricApplication.ps1 script that iterates through each of the services and itself installs, upgrades or removes them based on their state in the new deployment utilizing ServiceTemplates to populate configuration values.
Because I control the whole of the actual service install process then, I can infer based on data I collect and pass through the build pipeline what should and shouldn't actually be deployed independent of application deployment.
You might find the customization process a bit easier going this route compared to the approach you're taking.
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
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.
How to setup the properly the continuous integration when we have 1 solution (BuildDeploy.sln) and 2 cloud services (DataHora.ccproj and Maiuscula.ccproj):
When I try to run the default continuous deploy script created for visual studio online of maiuscula the cloud service is replaced by DataHora cloud service.
Seems that he gets only the datahora ccproj, because he is the first cloud project service of the solution.
To test my theory I create a custom entry in my configuration manager tha only builds maiusculo and change the Build Definition to get only Any CPU|X_Maiusculo
When I run the default build defition for maiusculo that was created by visual studio continuous integration I receive the following error:
Built $/ContinousDeployment/BuildDeploy/BuildDeploy.sln for target(s) DataHoraCloudService:Publish.
C:\a\src\BuildDeploy\BuildDeploy.sln.metaproj: The target "DataHoraCloudService:Publish" does not exist in the project.
So my question was: How to setup my continous integration script to build and deploy only one project of my solution?
If you have more than one deployable code project in the solution then the default that's will not work. It was created as a quick deploy for good with some solutions.
If you instead switch to the default template and create a PowerShell that does your deployment of both services you can call It from the post-test location. This is a better way anyway as It is possible to debug outside of a build.