azure 如果配置了部署表单源代码管理,则无法从门户添加WebJob

zaq34kh6  于 2022-11-17  发布在  其他
关注(0)|答案(8)|浏览(149)

今天,我们在Azure Portal中看到了以下消息
如果配置了部署窗体源代码管理,则无法从门户添加WebJob

我们假设这是一个 * 新 * 功能,因此拼写不正确:'部署 * 表单 * 原始档控制'应该是'部署 * 表单 * 原始档控制'。
我不知道在哪里设置一个设置来解决这个问题。
我们假设它一定在DevOps中的某个地方。

hiz5n14c

hiz5n14c1#

我们解决这个问题的方法是不切断管道
我们通过实现一个单独的WebJob构建/发布管道解决了这个问题。
以下是对我们有效的步骤:
"在蔚蓝之门“

  • 在应用服务x1c 0d1x中创建虚拟应用
    在开发运维中
  • 在您的建置管缐

    **重要注意事项:**加入下列参数:--output $(build.artifactstagingdirectory)到构建步骤。
  • 在您的发布管道

这会将WebJob部署到正确的目录。$(System.DefaultWorkingDirectory)/_ms-reporting-webjob-dev-CI/drop
查看应用服务中的Kudo控制台,WebJob的文件位置为:

wxclj1h5

wxclj1h52#

Kudu控制台
对我有效的变通办法是直接通过Kudu控制台上传Webjob。
在Azure门户上的应用服务中选择“高级工具”--〉“转到”,打开Kudu控制台。
进入Kudu门户后,打开“调试控制台”--〉“CMD”
转到Web作业的目录:“d:\home\site\wwwroot\应用程序数据\作业\连续{作业名称}”(https://github.com/projectkudu/kudu/wiki/WebJobs
然后拖放您准备上传Web作业的.zip文件(https://github.com/projectkudu/kudu/wiki/Kudu-console
作业现在将在Azure门户上列出并启动。

wlsrxk51

wlsrxk513#

我在虚拟应用程序中使用了以下物理路径,它为我们解决了这个问题
站点\wwwroot\应用程序数据\作业\已触发\作业名称

sbdsn5lh

sbdsn5lh4#

我们遇到了同样的问题,并注意到有一个旧的部署管道连接到部署中心刀片中的Web作业。断开此连接为我们解决了问题,我们能够手动部署。

brccelvz

brccelvz5#

我使用Kudu控制台上传了Webjob
您可以转到路径D:\home\site\wwwroot\App_Data\jobs\,然后在此处上传Webjob文件夹,该文件夹也会显示在您的Webjob门户中

m1m5dgzv

m1m5dgzv6#

不要去为这个问题创建新的CICD管道。在断开部署中心的连接时不要使用chrome/safer。请使用最新的IE或Microsoft Edge。它将允许断开部署中心的连接。我可以在Microsoft Edge中这样做。

0aydgbwb

0aydgbwb7#

我们遇到了同样的问题,在部署中心有我的Web应用程序的默认配置,但我们没有从存储库部署代码,因此我们禁用了该选项。我们正在从visual studio部署Web应用程序。

当前图像显示Web应用程序部署中心中禁用的存储库选项。

oalqel3c

oalqel3c8#

可能是因为您为Web应用程序部署设置了CI/CD。
如果您使用Azure Devops管道设置您的部署,并且您正在使用yaml文件方法,那么这可能就是您正在寻找的。
首先你需要设置一个分支,当一个新的提交被推送到它的时候,你想触发这个分支。

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

variables:
  BuildConfiguration: 'Release'

pr: none # Disable pull request triggers.

为了使我们的管道更有条理,我们将使用stages,让我们创建Build stage,这里我正在构建一个.Net应用,您可以将构建任务替换为您想要的构建。

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)'

然后运行dotnetpublish,将应用程序及其依赖项发布到一个文件夹,以便部署到宿主系统。
这里是重要的部分,当你从Azure Portal创建一个Web作业时,它的文件被存储在特定的文件夹下。
对于连续Web作业,它将存储在\site\wwwroot\app_data\Jobs\Continuous
对于触发的Web作业,它将位于\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

对我来说,我需要部署一个连续的Web作业,正如您在inputs:中看到的那样

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

dotnet发布将把生成的文件放在$(Build.ArtifactStagingDirectory)/publish_output/App_Data/jobs/continuous/MySuperAppBGS
然后压缩$(Build.ArtifactStagingDirectory)/publish_output/的内容,即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

并将$(Build.ArtifactStagingDirectory)的内容发布到drop工件,其中我们的zip文件存在MySuperAppAPIBackgroundService.zip,以便在下一阶段使用它

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

这是第二个阶段,将我们的zip文件部署到web应用程序服务,然后解压缩,将App_Data/jobs/continuous/MySuperAppBGS/*保留在\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'

注意:在第二阶段,我没有调用DownloadBuildArtifacts@0任务,因为我在自动注入Download工件任务的- deployment:作业中使用了deploy:,并且要访问前一阶段发布的工件,您需要使用$(Pipeline.Workspace),后跟您提供的工件名称,在我的示例中是$(Pipeline.Workspace)/drop
希望我说清楚,对于任何澄清不要犹豫,来问我。

相关问题