Рабочий процесс создания кода с переменными среды

#bash #continuous-integration #devops #continuous-deployment #aws-codebuild

#bash #непрерывная интеграция #devops #непрерывное развертывание #aws-создание кода

Вопрос:

У меня есть монолитный проект github, в котором есть несколько разных приложений, которые я хотел бы интегрировать с рабочим процессом AWS Codebuild CI / CD. Моя проблема в том, что если я вношу изменения в один проект, я не хочу обновлять другой. По сути, я хочу создать логическую ветку, которая развертывается по-разному в зависимости от файлов, измененных в конкретном коммите.

В основном мой репозиторий проектов выглядит так:

 - API
  -node_modules
  -package.json
  -dist
  -src
- REACTAPP
  -node_modules
  -package.json
  -dist
  -src
- scripts
  - 01_install.sh
  - 02_prebuild.sh
  - 03_build.sh
- .ebextensions
  

Что касается развертывания, мой API проект развертывается в elastic beanstalk, а мой REACTAPP развертывается в виде статических файлов в S3. Я попробовал несколько вещей, но решил, что единственный жизнеспособный подход — вручную выполнить этот deploy шаг в моем собственном 03_build.sh скрипте, потому что нет способа создать это динамически на этапе развертывания Codebuild(Я могу ошибаться).

В любом случае, моя проблема в том, что мне, по сути, нужно создать дерево решений, чтобы определить, какой проект будет завершен, поэтому, если я внесу изменения в API и нажму, он не будет автоматически развертывать REACTAPP на S3 без необходимости (и наоборот).

Мне удалось заставить это работать на локальном хосте, обновляя переменные среды в определенные моменты процесса сборки, а затем считывая их отдельными шагами. Однако это не удается при Codedeploy из-за проблем с разрешениями, т.Е. Я, похоже, не могу обновлять переменные env из самого процесса CI.

Очевидно, что мой buildconf.yml выглядит так:

 version: 0.2

env:
  variables:
    VARIABLES: 'here'
    AWS_ACCESS_KEY_ID: 'XXXX'
    AWS_SECRET_ACCESS_KEY: 'XXXX'
    AWS_REGION: 'eu-west-1'
    AWS_BUCKET: 'mybucket'
phases:
  install:
    commands:
      - sh ./scripts/01_install.sh
  pre_build:
    commands:
      - sh ./scripts/02_prebuild.sh
  build:
    commands:
      - sh ./scripts/03_build.sh
  

Я запускаю свои собственные сценарии оболочки для выполнения некоторой логики и пытаюсь передавать переменные между сценариями: install-> prebuild-> build

Чтобы привести один пример, вот 01_install.sh где я diff использую каждую версию проекта, чтобы определить, нужно ли ее обновлять (извините за любые незначительные ошибки в bash):

 #!/bin/bash

# STAGE 1
# _______________________________________
# API PROJECT INSTALL
# Do if API version was changed in prepush (this is just a sample and I'll likely end up storing the version amp; previous version within the package.json):

if [[ diff ./api/version.json ./api/old_version.json ]] > /dev/null 2>amp;1
## then
echo "🤖 Installing dependencies in API folder..."
cd ./api/ amp;amp; npm install

## Set a variable to be used by the 02_prebuild.sh script
TEST_API="true"
export TEST_API
else
 echo "No change to API"
fi

# ______________________________________
# REACTAPP PROJECT INSTALL

# Do if REACTAPP version number has changed (similar to above):
...
  

Затем на следующем этапе я читаю эти переменные, чтобы определить, следует ли мне запускать тесты в проекте 02_prebuild.sh :

 #!/bin/bash

# STAGE 2
# _________________________________
# API PROJECT PRE-BUILD
# Do if install was initiated
if [[ $TEST_API == "true" ]]; then
    echo "🤖 Run tests on API project..."
    cd ./api/ amp;amp; npm run tests
    echo $TEST_API
    BUILD_API="true"
    export BUILD_API
else
   echo "Don't test API"
fi

# ________________________________
# TODO: Complete for REACTAPP, similar to above
...
  

В моем окончательном сценарии я использую BUILD_API переменную для сборки в dist папку, затем я развертываю ее либо в Elastic Beanstalk (для API), либо в S3 (для REACTAPP).

Когда я запускаю это локально, это работает, однако, когда я запускаю его в Codebuild, я получаю сбой разрешений, предположительно, потому, что мои сценарии bash не могут export ENV_VAR . Мне интересно, знает ли кто-нибудь, как обновить ENV_VARIABLES из самого процесса сборки, или у кого-нибудь есть лучший подход для достижения моих целей (процесс сборки с условными / переменными в Codebuild)

РЕДАКТИРОВАТЬ: итак, подход, который мне удалось заставить работать, заключается в том, что вместо использования переменных Env я создаю новые файлы с определенными именами, используя fs затем чтение содержимого файла для принятия логических решений. Я могу получить доступ к этим файлам из каждого из сценариев bash, поэтому он работает довольно элегантно с некоторой автоматической очисткой.

Я не буду редактировать исходный вопрос, поскольку это все еще проблема, и я хотел бы знать, как / если другие люди решили это. Я все еще играю с тем, как на самом деле использовать команды eb deploy и s3 cli в сценариях сборки, поскольку codebuild, похоже, не поставляется с установленным eb cli, и мой .ebextensions файл, похоже, не соблюдается.

Ответ №1:

Репозитории управления версиями, такие как Github, могут быть настроены на отправку события post в конечную точку API при переходе в ветку. Вы можете использовать этот post-запрос в lambda через API Gateway. Эти данные события включают в себя, какие файлы были изменены с фиксацией. Затем лямбда-функция может обработать это событие, чтобы определить, что нужно развернуть. Если вы испытываете трудности с развертыванием на своих серверах из контейнера codebuild, вы можете попробовать опубликовать артефакт в s3 с устанавливаемым пакетом, а затем попросить ваш сервер захватить его оттуда.