Deploying a Linux VM in azure with custom script extension. It runs bunch of script in sequence till end, which I can see in the custom log. Even though script execution is finished deployment is in progress. Other deployment is getting delayed because of this. Any solution.
Related
I'm having a hard time figuring out the root cause why the build pipeline needs to be run at least two times getting the output I'm expecting.
We've a powershell script that I've developed which basically retrieves translations and checks the xml files if an update is needed. Now if I run this script locally on my machine or locally on the VM where the build agent is hosted it's running fine and it updates all translations but not when run via the build pipeline
For example having 50 translations to update:
run locally will update all 50 translations
run locally on the vm will update all 50 translations
running the script via azure build pipeline only 25 translations will be updated (and need a re-run)
I'm stuck as I can't debug the powershell script when executed by the build pipeline.
Has anyone an idea why the output of the powershell differs if run via an azure build pipeline vs. running it locally and locally on the vm? Any inputs are appreciated and don't hesitate to ask for further information if I'm missing something.
Thanks in advance!
This question feels so simple that I'm confused why I can't find an answer!
We have an Azure web app, typically running on 2 to 5 instances.
At the moment we manually run a quite intensive PHP script a few times a day on a local computer to generate a folder of files. (The resulting folder isn't huge - typically about 10MB in size and a few hundred files in total.) We then sync them via Github and they deploy to the website. Easy.
That process is fine, but we want to move the PHP script to Azure so we can remove the dependency on running it locally and instead run it as a chron job.
How can we reliably sync the outputted folder from our script into our web app?
One option is to use a triggered WebJob with a cron schedule. Your WebJob can contain just your PHP script. Or if it needs a special command line to run, include a run.cmd batch file with the full PHP command line.
In your PHP script, do whatever you need to gather the right set of files, and then just copy them to %home%\site\wwwroot\json-data.
For this to work, everything you need to do within your PHP script needs to be runnable within the App Service sandbox. You should first try this directly from Kudu Console before moving it to a WebJob, to make sure everything can run.
Set your web app deployment source to Local Git. After that push your code to WebApp by Git Push . I am not sure about PHP build process but when you push your code to AzureWeb app via LocalGit method it builds and restores all dependencies and deploy it . For custom build script you can refer https://github.com/projectkudu/kudu/wiki/Custom-Deployment-Script.
https://medium.com/#trstringer/custom-build-logic-post-git-push-with-azure-app-service-and-kudu-for-a-node-js-web-app-1b2719598916
I have a console application that has been converted to a Webjob.
There are a lot of functionalities in the webjob that is required to be run once a every night(midnight).
However, there is also a specific need that the same Webjob should be continuously running to do some jobs and be able to queue the requests from multiple users.
As the most of the processes are the same I don't see the point of creating another console application as type "Continuous".
As we have a continuous delivery in azure( when there is a new commit to git the online visual studio builds and release the web app and webjobs automatically).
How can I manage to tell build or release process to create 2 webjobs from the same console application which one of those is scheduled(Triggered) and the other is "Continuous"?
While I was writing up the question, stackoverflow similar questions highlighted me this question : Azure webjob; Scheduled execution as well triggers by queue
It looks like it would be possible to use TimerTrigger in a continuous type to handle both cases.
I will try to see if that works. Please give your suggestions for this work case.
You should have a single WebJob that is continuous. You can have as many functions that are decorated with TimerTrigger or message triggers as needed to respond to events or execute on a schedule. You are definitely on the right track.
I have a custom deployment script (*.sh script) defined for my azure deployment.
Just today, I have found that I am unable to publish. I updated my bitbucket repository and after a while I get an error similar to the following:
Command 'starter.cmd deploy_pvl_cont ...' was aborted due to no output nor CPU activity for 180 seconds. You can increase the SCM_COMMAND_IDLE_TIMEOUT app setting (or WEBJOBS_IDLE_TIMEOUT if this is a WebJob) if needed.\r\nstarter.cmd deploy_pvl_content.sh
I have tried a number of things to try to diagnose the problem.
Increase SCM_COMMAND_IDLE_TIMEOUT to 300
Run the script locally (Works)
Set up a new fresh deployment slot and try publishing same commit (Same error)
Tried publishing the previously successful commit (Same error)
Look for useful error messages in a diagnostic log dump (Coldn't find anything more useful)
Tried running the deployment script from the Kudu Console (No output returned, like it didn't actually run)
Tried reverting git to a previous version as suggested by #david-ebbo
Tried simplifying my script to a single echo command with the same results
Not sure what I can do to debug this further. Ideally I would like to get the output of the shell script on the azure host but don't know how to get it. Any ideas?
Updated answer
This is a regression caused by the move to git 2.8.x in Azure. The issue is tracked by https://github.com/projectkudu/kudu/issues/2041.
Here is a very simple workaround (and you don't need to bring in the old git tools): instead of setting your COMMAND to deploy_pvl_content.sh, set it to bash deploy_pvl_content.sh
We'll address the issue, but this workaround will get you going.
Original answer (only leaving for context)
You could be running into some flavor of this issue, which is caused by the upgrade to git 2.8.1 that we just did.
While we're trying to get to the bottom of it, please try this workaround to see if that helps:
Go to Kudu Console
Create a d:\home\bin folder
Copy the old Windows git 1.8.x folder in there. You can get the content from here. If you drag and drop the zip into Kudu console, there is a special unzip drop area that will expand it.
Try your deployment again
We have an azure webjob that was deployed as on demand. Is there a way to change this to run on a schedule without redeploying?
Not a lot of info out there on this.
I tried creating a new schedule collection like this and adding a job to run the existing webjob, but that didn't seem to work either.
I prefer to do this in the GUI portal, but if its not possible, I'll do it in powershell (if it is possible like that).
(Also, if it can only be changed by redeploying, I need to know that and it effectively answers the question)
To easily add a schedule to your triggered (on demand) webjob add a file called settings.job at the root of your webjob with this content:
{"schedule": "the schedule as a cron expression"}
Find out more about this here
Note: it'll only work properly for Standard or Premium sites and requires you to set the site as always on.
In the end the link in the original post I referenced worked. The thing that was missing for me was the understanding that creating a trigger job in scheduler will not affect the run status (on-demand or scheduled) of the web job itself. In my case it stayed "on-demand", but the schedule was in fact running it.
This should point you in the direction on how to do this via PowerShell. It looks possible to add already existing WebJobs to a scheduler.
Create a Scheduled Azure WebJob with PowerShell