When configuration the build definition, I have the option of copying the build output to the server:
We are using the VSO Host Build Controller and Azure's Continuous Integration build template to release to our development environment after every check-in.
Is there any reason why we need to have this value set? How could it ever be useful?
The Copy build output to the server will put the output of the build as a zip file attached the build that can be downloaded later.
In a situation where you don't care about the build output because you have it setup to continuously deploy to Azure (or some other build based deployment) you would not use this option.
If you however needed to download the output, for example a Windows Store App that you need to publish to the Store manually, then you could use this to get the application.
In VSO you most likely don't have a Drop Server (unless you have invested in Azure heavily) so you have 2 choices:
Put them in source control. Only in TFVC, not Git. Also fills up your Repo with Large Files.
Attach them to the build as a Zip.
The second scenario is exactly where you would use this.
Related
Im trying to test different things on Azure, and i have tried to setup a static webapp.
The github repo consists of nothing really.
These files are pretty much empty. Whenever i push something to the repo, the build triggers, but fails with the error Oryx built the app folder but was unable to determine the location of the app artifacts. Please specify the app artifact location through the Github workflow file.
Im uncertain of what it means with artifacts. This tiny webapp doesnt have any real build or anything
In the azure-static-web-apps-xxxxxx-xxxx-xxxxxxx.yml file the app_artifact_location is " "
Not really sure which artifacts its looking for, or what they are really.
You may want to investigate this Quickstart: Building your first static web app.
To add to this app_artifact_location is the location of the build output directory relative to the app_location. For example, if your application source code is located at /app, and the build script outputs files to the /app/build folder, then set build as the app_artifact_location value.
In step Build and Deploy builds and deploys to your Azure Static Web Apps instance. Under the with section, you can customize these values for your deployment.
Reference: https://learn.microsoft.com/en-gb/azure/static-web-apps/github-actions-workflow
Based on https://learn.microsoft.com/en-us/azure/static-web-apps/overview
Python-based frontends are not supported. Clients are served statically and are browser-based apps. The build system (0ryx) likely unable to determine the framework and is generating the error message you are seeing.
The default web page that is expected is index.html. It looks like you may have misspelled it = index.hmtl
We have a new project in which we are trying to make use of the built in continuous integration in Kentico for tracking changes to templates, page types, transformations etc.
We have managed to get this working locally between two instances of a Kentico database, making changes in one, syncing the changes through CI and then restoring them up to the second database using the Continuous integration application that sits in the bin folder in the Kentico site.
The issue we are having is when it comes to deploying our changes to our dev and live environments.
Our sites are hosted as Azure App services and we deploy to them using VSTS (Azure DevOps) build and release workflows however, as these tasks run in an agent, any powershell script we try to run to trigger the CI application fails because it is not running in the site / server context.
My question is, has anyone managed to successfully run Kentico CI in the context of an Azure app service? Alternatively, how can I trigger a powershell script on the site following a deployment?
Yes, I've got this running in Azure DevOps within the release pipeline itself. It's something that we're currently rolling out as a business where I work.
The key steps to getting this working for me were as follows:
I don't want to deploy the ContinuousIntegration.exe or the repository folders, so I need to create a second artefact set from source control (this is only possible at the moment with Azure Repos and GitHub to my knowledge).
Unzip your deployment package and copy the CMS folder to a working directory, this is where you're going to run CI. I did this because I need the built assemblies available.
From the repo artefact in step 1, copy the ContinuousIntegration.exe and CI repository folders into the correct place in your unzipped working folder.
Ensure that the connection string actually works for the DB in your unzipped folder, if necessary, you may want to change your VS build options in regards to how the web.config is handled.
From here, you should be able to run CI in the new working folder against your target database.
In my instance, as I don't have CI running on the target site it means that everything is restored every time.
I'm in to process of writing this up in more detail, so I'll share here when I've done that.
Edit:
- I finally wrote this up in more detail: https://www.ridgeway.com/blog/web-development/using-kentico-12-mvc-with-azure-devops
We do, but no CI. VSTS + GIT. We store virtual objects in the file system and using git for version control. We have our own custom library that does import export of the Kentico objects (the ones are not controlled by Git).Essentially we have a json file "publishing manifest" where we specify what objects need to be exported (i.e. moved between environments).
There is a step from Microsoft 'Powershell on Target Machines', you guess you can look into that.
P.S. Take a look also at Three Ways to Manage Data in Kentico Using PowerShell
Deploy your CI files to the Azure App Service, and then use a Azure Job to run "ContinuousIntegration.exe"
If you place a file called KenticoCI.bat in the directory \App_Data\jobs\triggered\ContinuousIntegration - this will automatically create a web job that you can can trigger:
KenticoCI.bat
cd D:\home\site\wwwroot
ren App_Offline.bak App_Offline.htm
rem # run Kentico CI Integraton
cd D:\home\site\wwwroot\bin
ContinuousIntegration.exe -r
rem # Removes the 'App_Offline.htm' file to bring the site back online
cd D:\home\site\wwwroot
ren App_Offline.htm App_Offline.bak
I'm very confused about how one of the build task currently works.
I have been using Grunt locally in VS-Code to minify a JS file. All seems to be working well. In Azure DevOps, as a Build Task, I am using the same package.json the minification takes place but on the agent VM:
D:\a\1\s\Build\Hello.js
Looking in my repo, this file does not exist. I am assuming that I need to copy the file and upload to my own repo. Does anyone know how I do this?
A build usually creates a build ** artifact** that gets copied to a drop location. You will use the build artifacts inside your release definitions to deploy the binaries / minified or optimized code to an environment.
You probably don't want/need to upload any file back to your repo.
See: What is Azure pipelines
I am trying to create automated build to publish a folder with files onto Azure web-site. And I cannot accomplish this.
I am NOT publishing a solution (.sln), but rather a folder with files. I am using VS2013 and Visual Studio Online.
I have experience with TFS web publishing, so I published solutions many times.
So, what I did so far:
Created an MSBuild build.xml file that just copies files from the folder to the output.
Created a build definition based on AzureContinuousDeployment.11.xaml
Specified build.xml in my build definition, Process tab, in "Solution to build" parameter:
If I build my project, it is correctly built, files are copied to the output, etc (I can verify it by opening drop location, all files are there).
Then, I:
Created a web-site in Azure, linked it to my TFS subscription.
Downloaded a publish profile (.PublishSettings from a web-site).
Created a Web publish profile (.pubxml) in Visual Studio based on .PublishSettings file).
Specified Web Deploy Publish Profile and Deployment Settings Name:
But now I am getting an error during build:
Exception Message: Please specify a Visual Studio Solution (.sln) to build. (type BuildFromSolutionException)
So it asks me for a Visual Studio solution, but earlier it worked perfectly with MSBuild file (after step 3).
I tried to rename my .xml to .sln (probably it is not what I should have done), and build now says "There was no Windows Azure project (.ccproj) detected in the solution. Continuous delivery to an Azure Cloud Service requires an Azure project. (type CCProjNotFoundException)"
If I don't specify "Deployment Settings Name", build completes without errors, but again no publishing to Azure.
So, the question is, how to publish a custom MSBuild build, without a solution, onto Azure? Is TFS continuous Azure publishing for Solutions only? I expect it to be agile, like I published folders from Local Git to Web-site without any hassle.
What should I do?
There are a few confused ideas in your question. Fits, there is no relationship between and automated build and Git. You are using Team Foundation Build to run the workflow of deployment. It is the workflow that is not working for you. In effect the build and deployment script. In fact the script you are using works with both Git and TFVC so that is not the issue.
That specific script is designed specifically for building an azure project that is then continuously delivers to Azure and you likley can't use it as you are. You can however create another script and use that. I would suggest you try instead to use the Default build script and use a powershell script within the build to collect the files and then push them to Azure.
If you want to go a little more advanced you could create a copy of the default and make one that does not require MSBuild at all.
I am trying to build and Deploy our solution to Azure using TeamCity.
When I Build the azure solution (Web.Azure.ccproj) using TC, it always generates wrong file like Web.Azure.ccproj.cspkg in Release\app.publish folder. I am not understaing why it is generating a file like ccproj.cspkg. Rather it should have just generated Web.Azure.cspkg.
Note: when I try directly in command prompt (msbuild Web.Azure.ccproj /t:Publish) am able to see proper files generated.
Any reason why this is happening?
Thanks in Advance
I don't know why the generated files are different. However, if you are looking to deploy to Azure Cloud Services from TeamCity, maybe this link will help.
The linked post has a powershell script that will deploy the solution and you can include that as a build step in TeamCity. The script deals with having different Live and UAT environments etc, which you may not need.
For what it's worth, we're building the entire solution with a Visual Studio (.sln) runner and it builds the Azure projects fine.
Some of our parameters:
Targets: Rebuild
Configuration: Dev (Could be Stage or Release per our environments)
Command line parameters: /p:TargetProfile=Dev /P:Configuration=Dev
The last set of parameters are where I originally got stuck. We have profiles for Azure projects and configurations for the entire solution. We need both to get the right packages created.