Gitlab CI / CD с использованием FTP для .NET Core - PullRequest
Новая
       14

Gitlab CI / CD с использованием FTP для .NET Core

0 голосов
/ 11 июня 2019

Я пытаюсь автоматически собрать, протестировать и развернуть мое приложение .NET Core, и пока оно собирает и тестирует, но не развертывает.Трубопровод Gitlab показывает, что работа прошла успешно, но на самом деле это не сработало.Это мой Dockerfile: 

FROM microsoft/dotnet:2.2-sdk AS build-env
WORKDIR /source

RUN curl -sL https://deb.nodesource.com/setup_11.x |  bash - \
    && apt-get install -y nodejs


COPY ./src/*.csproj .
RUN dotnet restore

COPY ./src/ ./

RUN dotnet publish "./Spa.csproj" --output "./dist" --configuration Release --no-restore

FROM microsoft/dotnet:2.2-aspnetcore-runtime
WORKDIR /app
COPY --from=build-env /source/dist .

RUN apt-get update \
    && apt-get install -y php-cli

COPY deployment.ini /app
EXPOSE 80
ENTRYPOINT ["dotnet", "Spa.dll"]

, и вот как выглядит мой файл .gitlab-ci.yml: 

# ### Define variables
#
variables:
 OBJECTS_DIRECTORY: 'obj'    
 NUGET_PACKAGES_DIRECTORY: '.nuget'
 SOURCE_CODE_PATH: 'src/'             

# ### Define stage list
stages:
 - build
 - test
 - deploy

cache:
 # Per-stage and per-branch caching.
  key: "$CI_JOB_STAGE-$CI_COMMIT_REF_SLUG" 
  paths:
    - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/project.assets.json'
    - '$SOURCE_CODE_PATH$OBJECTS_DIRECTORY/*.csproj.nuget.*'
    - '$NUGET_PACKAGES_DIRECTORY'
    - '**/node_modules/'

build:
  image: docker:stable
  stage: build
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  script:
    - docker build -t registry.gitlab.com/chinloyal/spa .
    - docker push  registry.gitlab.com/chinloyal/spa

tests:
  image: microsoft/dotnet:2.2-sdk
  stage: test
  before_script:
    - curl -sL https://deb.nodesource.com/setup_11.x |  bash -
    - apt-get install -y nodejs
  script:
    - dotnet test --no-restore Tests/

deploy:
  image: docker:stable
  services:
    - docker:dind
  stage: deploy
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker pull registry.gitlab.com/chinloyal/spa
    - docker run --name spa -p 80:80 -d registry.gitlab.com/chinloyal/spa
  script:
    - docker exec -d spa curl -S "https://gitlab.com/chinloyal/ftp-deploy-tool/raw/master/deployment.phar" --output deployment.phar
    - docker exec -d spa bash -c "echo remote = $FTP_HOST >> deployment.ini"
    - docker exec -d spa bash -c "echo user = $FTP_USER >> deployment.ini"
    - docker exec -d spa bash -c "echo password = $FTP_PASSWORD >> deployment.ini"
    - docker exec -d spa php deployment.phar deployment.ini
  environment:
    name: production
  only:
    - master

Эта строка docker exec -d spa php deployment.phar deployment.ini является той, которая должназагрузить файлы из контейнера докера.Но я верю в это, потому что Gitlab заканчивает процесс сразу после этой линии.Тогда процесс внутри контейнера просто заканчивается.

Я пытался использовать образ реестра (registry.gitlab.com/chinloyal/spa) в качестве образа для развертывания, но каждый раз, когда я пытаюсь его использовать, он просто запускает проектна Gitlab до истечения времени ожидания или до его отмены.

Между прочим, у меня есть только ftp-доступ к серверу, потому что это общий сервер.Используемый для развертывания ftp-инструмент здесь .Я пробовал это раньше, поэтому я знаю, что это работает.

1 Ответ

0 голосов
/ 11 июня 2019

Я понял, все команды docker exec использовали флаг -d, поэтому я удалил флаг -d, чтобы gitlab отображал вывод файлов, загружаемых и загружаемых. поэтому я изменяю это docker exec -d spa curl -S "https://gitlab.com/chinloyal/ftp-deploy-tool/raw/master/deployment.phar" --output deployment.phar на docker exec spa curl -S "https://gitlab.com/chinloyal/ftp-deploy-tool/raw/master/deployment.phar" --output deployment.phar

Я также изменил docker exec -d spa php deployment.phar deployment.ini на docker exec spa php deployment.phar deployment.ini.

Итак, перед тем, как они начали работать в автономном режиме, из-за того, что gitlab подумал, что они закончили и просто перешли к следующей команде, удаление флага -d позволяет gitlab ждать.

...