17

Today we experienced the following message in Azure Portal

WebJob cannot be added from portal if deployment form source control is configured.

Error Azure Portal

We assume that this is a new feature hence the spelling is incorrect: 'deployment form source control' should be 'deployment from source control'.

I have no clue where to set a setting that solved this.

It has to be somewhere in DevOps we assume.

Daniel
  • 9,491
  • 12
  • 50
  • 66

8 Answers8

15

We solved it by not disconnecting a pipeline.

We solved it by implementing a seperate WebJob Build/Release Pipeline.

Here are the steps that worked for us:

In Azure Portal

  • Create a virtual application in your app service enter image description here

In DevOps

  • In your build pipeline enter image description here Important Notice: add the following Argument: --output $(build.artifactstagingdirectory) to the build step.

  • In your release pipeline enter image description here

This deploys the WebJob to the correct directory. In our case: $(System.DefaultWorkingDirectory)/_ms-reporting-webjob-dev-CI/drop

Having a look at the Kudo Console in our App Service the file location for our WebJob is: enter image description here

Daniel
  • 9,491
  • 12
  • 50
  • 66
12

Kudu Console

The workaround that worked for me was uploading the webjob directly via the Kudu Console.

Open the Kudu Console by selecting "Advanced Tool" --> "Go" in Your App Service on the Azure Portal.

Once on the Kudu portal open a "Debug Console" --> "CMD"

Go to the directory for your webjobs: "d:\home\site\wwwroot\app_data\jobs\continuous\{job name}" (https://github.com/projectkudu/kudu/wiki/WebJobs)

Then drag and drop the .zip file you prepared to upload your webjob (https://github.com/projectkudu/kudu/wiki/Kudu-console)

The job will now be listed on the Azure Portal and be started.

studere
  • 156
  • 8
3

I used the following physical path in the Virtual Application and it solved it for us

site\wwwroot\App_Data\jobs\triggered\jobname

tchrikch
  • 2,428
  • 1
  • 23
  • 43
P K
  • 31
  • 1
0

We had the same issue and noticed there was an old deployment pipeline connected to our web job in the Deployment Center blade. Disconnecting this solved the problem for us and we were able to manually deploy.

Robert William Hardy
  • 1
  • 1
0

I used Kudu console to upload the webjobs

You can go to the path D:\home\site\wwwroot\App_Data\jobs\ and then upload the webjob folder here and then this shows up in your Webjobs portal as well

Pratap Kumar S
  • 61
  • 1
  • 2
  • To update the cron expression to schedule the webjob, please use/add Settings.job file in the respective webjob folder and then add the cron expression as below { "schedule": "0 0/30 * * * *" } Above schedule runs for every 30 minutes – Pratap Kumar S Sep 19 '19 at 09:04
0

Don't go for the new CICD pipeline creation of this issue. Don't use chrome/safer while disconnecting the deployment center. Please use the latest IE or Microsoft Edge. it will allow the disconnect of the deployment center. I am able to do that in Microsoft Edge.

adhi vijayakumar
  • 1
  • 1
0

We had the same issue, and there was default configuration in deployment center for my web application, but we are not deploying the code from reposiotry, so we disabled that option. We are deploying web application from visual studio. enter image description here

Currently the image showing disabled repository options in deployment center of the web application.

Kona Suresh
  • 1,836
  • 1
  • 15
  • 25
0

Probably because You set CI/CD for your web app deployment.

If you set your deployment with Azure Devops pipelines, and you are doing the yaml file approach, then maybe this is what you are looking for.

firstly you need to set the branch that you want to be triggred when a new commit has been pushed to it.

trigger:
  branches:
    include:
    - refs/heads/staging

variables:
  BuildConfiguration: 'Release'

pr: none # Disable pull request triggers.

To make our pipeline a little bit organized, We will work with stages, let's create our Build stage, here I am building a .Net app, you can replace the build task with the build you want.

stages:
- stage: 'Build'
  jobs:
  - job: 'Build'
    pool:
      vmImage: 'windows-latest'  #The agent that will be used to start this stage

    steps:
    - task: DotNetCoreCLI@2
      displayName: 'dotnet build'
      inputs:
        command: build
        projects: 'MySuperApp/BackgroundService.csproj'
        arguments: '--configuration $(BuildConfiguration)'

then I will run dotnet publish, that publishes the application and its dependencies to a folder for deployment to a hosting system.

and here comes the important part, when you create a webjob from azure portal, its files are stored under specific folder.

for Continuous webjobs, it will be stored under \site\wwwroot\app_data\Jobs\Continuous

and for Triggered webjobs it will be under \site\wwwroot\app_data\Jobs\Triggered

    - task: DotNetCoreCLI@2
      displayName: 'dotnet publish'
      inputs:
        command: 'publish'
        arguments: '--configuration $(BuildConfiguration) --output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'
        projects: 'MySuperApp/BackgroundService.csproj'
        publishWebProjects: false
        zipAfterPublish: false
        modifyOutputPath: false

for me I need to deploy a continuous webjob, as you can see in the arguments within inputs:

--output $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS'

the dotnet publish will put the generated files under $(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS

then I will zip the content of $(Build.ArtifactStagingDirectory)/publish_output/ which is App_Data/jobs/continuous/MySuperAppBGS

    - task: ArchiveFiles@2
      displayName: 'Zip Published Files'
      inputs:
        rootFolderOrFile: '$(Build.ArtifactStagingDirectory)/publish_output'
        includeRootFolder: false
        archiveType: 'zip'
        archiveFile: '$(Build.ArtifactStagingDirectory)/MySuperAppAPIBackgroundService.zip'
        replaceExistingArchive: true

and publish the content of $(Build.ArtifactStagingDirectory) to drop artifact, which our zip file exist MySuperAppAPIBackgroundService.zip, in order to use it, in the next stage

    - task: PublishBuildArtifacts@1
      displayName: 'Publish Build artifacts'
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'drop'
        publishLocation: 'Container'

Here is the second stage, that will deploy our zip file to the web app service, then it will be unzipped leaving App_Data/jobs/continuous/MySuperAppBGS/* under \site\wwwroot\


- stage: 'Deploy'
  jobs:
  - deployment: 'Deploy'
    environment: 'MySuperAppAPI_BackGround_Staging_env' #just an env variable, that will be used later if you want, give it whatever name you like
    strategy:
      runOnce:
        deploy:
          steps:
          - task: AzureWebApp@1
            displayName: 'Deploy MySuperAppAPIBackgroundService.zip to MySuperAppAPI-Staging-BackgroundService'
            inputs:
              azureSubscription: 'Your Azure service connection'
              appType: 'webApp'
              appName: 'MySuperAppAPI-Staging-BackgroundService'
              package: '$(Pipeline.Workspace)/drop/MySuperAppAPIBackgroundService.zip'
              deploymentMethod: 'zipDeploy'

Note: in the second stage, I didn't call DownloadBuildArtifacts@0 task, because I used deploy: within - deployment: job that auto inject the Download artifact task, and to access the published Artifact from the previous stage, you use $(Pipeline.Workspace) following by the artifact name you provided, in my case it is $(Pipeline.Workspace)/drop

Hope I was clear, for any clarification don't hesitate to ask me.

Holy semicolon
  • 868
  • 1
  • 11
  • 27