bounty将在6天后过期。回答此问题可获得+100声望奖励。CodeMan03希望引起更多人关注此问题。

我有一个gitlab repo，可以构建一个Net 6应用程序。我的服务器上有Plesk（interserver），我有点困惑如何将构建发送到plesk甚至我的服务器。这是我的yml文件
我究竟如何将实际的应用程序发送到服务器上的文件夹中，该文件夹位于此位置：dev.myworkatcornerstone.com

# To contribute improvements to CI/CD templates, please follow the Development guide at:
# https://docs.gitlab.com/ee/development/cicd/templates.html
# This specific template is located at:
# https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/dotNET-Core.yml

# This is a simple example illustrating how to build and test .NET Core project
# with GitLab Continuous Integration / Continuous Delivery.
#
# ### Specify the Docker image
#
# Instead of installing .NET Core SDK manually, a docker image is used
# with already pre-installed .NET Core SDK.
#
# The 'latest' tag targets the latest available version of .NET Core SDK image.
# If preferred, you can explicitly specify version of .NET Core (e.g. using '2.2-sdk' tag).
#
# See other available tags for .NET Core: https://hub.docker.com/r/microsoft/dotnet
# Learn more about Docker tags: https://docs.docker.com/glossary/?term=tag
# and the Docker itself: https://opensource.com/resources/what-docker
image: mcr.microsoft.com/dotnet/sdk:6.0

stages:
    - build
    - test
    - deploy

# ### Define variables
#
variables:
  # 1) Name of directory where restore and build objects are stored.
  OBJECTS_DIRECTORY: 'obj'
  # 2) Name of directory used for keeping restored dependencies.
  NUGET_PACKAGES_DIRECTORY: '.nuget'
  # 3) A relative path to the source code from project repository root.
  # NOTE: Please edit this path so it matches the structure of your project!
  SOURCE_CODE_PATH: '/builds/DavidML3/cornerstone_staff_api' 
  PUBLISHDIR: $SOURCE_CODE_PATH/bin/Release/net6.0/publish
  isPullRequest: $[eq(variables['Build.Reason'], 'PullRequest')]
  isDevelopment: $[eq(variables['Build.SourceBranch'], 'refs/heads/develop')]
  USERNAME_DEV: 'WebAdmin'
  PASSWORD_DEV:  'password'
  DEPLOYSERVER_DEV: 'ipaddress'
  FTP_DESTINATION: 'dev.myworkatcornerstone.com/App_Data/'

  

# ### Define global cache rule
#
# Before building the project, all dependencies (e.g. third-party NuGet packages)
# must be restored. Jobs on GitLab.com's Shared Runners are executed on autoscaled machines.
#
# Each machine is used only once (for security reasons) and after that is removed.
# This means that, before every job, a dependency restore must be performed
# because restored dependencies are removed along with machines. Fortunately,
# GitLab provides cache mechanism with the aim of keeping restored dependencies
# for other jobs.
#
# This example shows how to configure cache to pass over restored
# dependencies for re-use.
#
# With global cache rule, cached dependencies will be downloaded before every job
# and then unpacked to the paths as specified below.
cache:
  # Per-stage and per-branch caching.
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG"
  paths:
    # Specify three paths that should be cached:
    #
    # 1) Main JSON file holding information about package dependency tree, packages versions,
    # frameworks etc. It also holds information where to the dependencies were restored.
    - '$SOURCE_CODE_PATH/$OBJECTS_DIRECTORY/project.assets.json'
    # 2) Other NuGet and MSBuild related files. Also needed.
    - '$SOURCE_CODE_PATH/$OBJECTS_DIRECTORY/*.csproj.nuget.*'
    # 3) Path to the directory where restored dependencies are kept.
    - '$NUGET_PACKAGES_DIRECTORY'
  #
  # 'pull-push' policy means that latest cache will be downloaded (if it exists)
  # before executing the job, and a newer version will be uploaded afterwards.
  # Such a setting saves time when there are no changes in referenced third-party
  # packages.
  #
  # For example, if you run a pipeline with changes in your code,
  # but with no changes within third-party packages which your project is using,
  # then project restore will happen quickly as all required dependencies
  # will already be there — unzipped from cache.

  # 'pull-push' policy is the default cache policy, you do not have to specify it explicitly.
  policy: pull-push

build:
  stage: build
  # ### Build all projects discovered from solution file.
  #
  # Note: this will fail if you have any projects in your solution that are not
  # .NET Core-based projects (e.g. WCF service), which is based on .NET Framework,
  # not .NET Core. In this scenario, you will need to build every .NET Core-based
  # project by explicitly specifying a relative path to the directory
  # where it is located (e.g. 'dotnet build ./src/ConsoleApp').
  # Only one project path can be passed as a parameter to 'dotnet build' command.
  script:
    - 'dotnet build'

test:
    stage: test
    script: 
        - "dotnet test"

deploy:
  stage: deploy  
  only:
    - Development
  environment:
    Development
  artifacts:
        paths:
            - $SOURCE_CODE_PATH/bin/release/net6.0/publish
        expire_in: 1 week    
  script: 
    - pwd ls -la     
    - cd $SOURCE_CODE_PATH  
    - dotnet publish -c release
    - echo "*****Install lftp*****"
    - apt-get update -qq && apt-get install -y -qq zip lftp
    - cd $PUBLISHDIR
    - echo "*****Upload file to ftp*****"    
    - pwd ls -la find /build.
    #- lftp -e "set ftp:ssl-allow no; open -u $USERNAME_DEV,$PASSWORD_DEV $DEPLOYSERVER_DEV;mirror -R ./  ./$FTP_DESTINATION;"