Лекция №10. GitHub Actions

1. Введение в GitHub Actions

Что такое GitHub Actions?

GitHub Actions — это встроенный инструмент автоматизации, предоставляемый GitHub для организации непрерывной интеграции (CI) и непрерывной поставки (CD) программного обеспечения. Он позволяет пользователям GitHub автоматизировать различные процессы, связанные с их проектами, включая тестирование, развертывание, сборку, и даже управление зависимостями. Функциональность GitHub Actions может использоваться для выполнения скриптов и сценариев на основе событий, происходящих в репозитории.

Основные возможности

GitHub Actions предоставляет широкий набор возможностей для автоматизации процессов разработки:

Поддержка нескольких операционных систем. Исполнители могут быть настроены для выполнения задач на Windows, macOS и Linux, что позволяет тестировать и развертывать приложения в разных окружениях.
Автоматизация CI/CD процессов. GitHub Actions может быть использован для выполнения тестов, сборки и развертывания приложений. Например, при каждом новом коммите может запускаться процесс сборки и тестирования кода для обеспечения его целостности и функциональности.
Управление артефактами. Результаты сборки могут быть сохранены как артефакты, что полезно для последующего анализа или распространения.
Интеграция с другими системами. С помощью GitHub Actions можно легко взаимодействовать с различными внешними сервисами, например, системами развертывания, управления задачами или аналитическими платформами.
Планирование задач. Рабочие процессы могут быть запущены по расписанию, используя синтаксис cron, что позволяет, например, автоматически запускать тесты в определённое время или выполнять регулярные задачи, такие как обновление зависимостей.

Пример простого рабочего процесса

Ниже приведен пример рабочего процесса, который запускается при каждом коммите и выполняет тестирование Python-приложения:

name: CI

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: '3.8'
    - name: Install dependencies
      run: pip install -r requirements.txt
    - name: Run tests
      run: pytest

В этом примере рабочий процесс запускается на каждый push в репозиторий, использует последнюю версию Ubuntu в качестве среды выполнения и выполняет следующие шаги: проверяет код из репозитория, устанавливает версию Python, загружает зависимости и запускает тесты.

GitHub Actions — это мощный и гибкий инструмент для автоматизации рабочих процессов, тесно интегрированный с экосистемой GitHub. Он позволяет эффективно организовывать процессы CI/CD, тестировать и развертывать приложения, а также выполнять другие задачи автоматизации. Будучи высоко расширяемым и модульным, он предоставляет возможности для создания индивидуальных решений, соответствующих уникальным потребностям проекта.

Зачем использовать CI/CD?

CI/CD (Continuous Integration / Continuous Delivery или Continuous Deployment) — это практика, направленная на автоматизацию и оптимизацию процессов разработки, тестирования и развертывания программного обеспечения. Она представляет собой стратегию, которая позволяет разработчикам более эффективно управлять изменениями в коде, обеспечивать его качество и ускорять цикл выпуска новых версий.

Основные принципы CI/CD

Непрерывная интеграция (Continuous Integration, CI) — это процесс частого слияния (интеграции) изменений в коде из отдельных веток разработчиков в основную ветку. Цель CI заключается в том, чтобы автоматизировать сборку и тестирование программного обеспечения с каждой новой итерацией кода. Интеграция происходит регулярно, чтобы как можно раньше выявить возможные конфликты и ошибки, возникающие при объединении изменений от разных разработчиков.
Непрерывная доставка (Continuous Delivery, CD) — это методология, при которой код готов к развертыванию в любое время. В отличие от CI, CD предполагает, что изменения кода, прошедшие автоматическое тестирование, могут быть вручную или автоматически развернуты на конечной среде (стейджинг или продакшн). CD фокусируется на автоматизации этапов развертывания и требует, чтобы система была постоянно готова к выпуску новых версий.
Непрерывное развертывание (Continuous Deployment, также CD) — это расширение практики непрерывной доставки, при котором каждое изменение, прошедшее автоматические тесты, автоматически развертывается в рабочей (production) среде без ручного вмешательства.

Зачем использовать CI/CD?

Снижение риска ошибок и дефектов в коде

Одним из основных преимуществ CI является возможность раннего выявления ошибок. Когда изменения кода интегрируются часто и проходят автоматическое тестирование, вероятность появления неожиданных проблем на более поздних стадиях разработки значительно снижается. Автоматизированные тесты позволяют обнаруживать ошибки непосредственно после внесения изменений, что облегчает их исправление, так как они еще свежи в памяти разработчика.

Быстрая обратная связь

CI/CD позволяет разработчикам быстрее получать обратную связь о качестве их изменений. Когда каждая итерация кода автоматически тестируется, разработчик сразу видит результаты своих изменений. Это ускоряет процесс устранения ошибок и способствует улучшению качества конечного продукта. Более того, быстрая обратная связь важна для поддержания высокой мотивации команды и обеспечения прозрачности процесса разработки.

Ускорение процесса разработки

CI/CD значительно ускоряет выпуск новых функций и исправлений. В традиционных процессах разработка может занимать много времени из-за длительных циклов тестирования, ручных проверок и развертываний. CI/CD автоматизирует эти процессы, позволяя команде сосредоточиться на добавлении новых функций, вместо того чтобы тратить время на ручные тесты и развертывания. Это особенно важно в условиях высокой конкуренции, когда скорость выпуска продукта на рынок имеет стратегическое значение.

Повышение качества программного обеспечения

Автоматическое тестирование и частые интеграции способствуют созданию более стабильного и качественного программного обеспечения. Разработчики могут уверенно внедрять изменения, зная, что они будут сразу протестированы и не приведут к регрессии в функционале. Постоянное тестирование и проверка новых изменений также снижают количество дефектов, попадающих в продакшн.

Упрощение процесса развертывания

Непрерывная доставка и развертывание автоматизируют процесс развертывания на серверы, что уменьшает вероятность ошибок, связанных с человеческим фактором. Развертывание становится предсказуемым и безопасным процессом, поскольку выполняется автоматически с использованием проверенных скриптов и конфигураций.

Снижение времени на исправление ошибок (Mean Time to Recovery, MTTR)

Когда система CI/CD настроена эффективно, время на исправление ошибок сокращается благодаря автоматическому тестированию и интеграции. Ошибки выявляются и устраняются на ранних стадиях, прежде чем они окажут влияние на пользователей. Это, в свою очередь, сокращает время простоя и снижает затраты на техническое обслуживание.

Обеспечение согласованности и воспроизводимости

CI/CD гарантирует, что каждое изменение кода проходит через одни и те же этапы тестирования и развертывания. Это обеспечивает согласованность и воспроизводимость всего процесса разработки и развертывания, что важно для поддержания качества на всех этапах жизненного цикла программного обеспечения.

Минимизация ручного труда и повышение эффективности

Автоматизация задач, таких как тестирование, сборка, проверка качества и развертывание, освобождает время команды для работы над более сложными и важными аспектами проекта. Ручное тестирование или развертывание могут быть длительными, подвержены ошибкам и требуют большого внимания. CI/CD устраняет эту нагрузку, позволяя сэкономить ресурсы и повысить общую производительность команды.

Поддержка DevOps культуры

Использование CI/CD — важный компонент DevOps, подхода к разработке и эксплуатации программного обеспечения, который ориентирован на тесную интеграцию и сотрудничество между командами разработки и операционной поддержки. CI/CD способствует внедрению принципов DevOps, таких как автоматизация, быстрая обратная связь и непрерывное улучшение, что в конечном итоге приводит к лучшей синхронизации работы команд и улучшению бизнес-результатов.

Пример использования CI/CD в реальном проекте

Представим себе проект по разработке веб-приложения. Внедрение CI/CD в этом проекте позволит команде:

Автоматизировать тестирование каждой новой функции с помощью модульных и интеграционных тестов.
Сразу после успешного тестирования автоматически собирать приложение для развертывания.
Автоматически развертывать приложение на сервере стейджинга для последующего тестирования и демонстрации заказчику.
При необходимости настроить автоматическое развертывание на продакшн-сервер сразу после прохождения всех проверок.

В результате команда сократит время от разработки до поставки продукта пользователю, повысит его качество и снизит количество ошибок в продакшн-среде.

CI/CD является важнейшей практикой современной разработки программного обеспечения, позволяющей ускорить выпуск продукта на рынок, повысить его качество и надежность, а также улучшить процессы управления изменениями. Благодаря автоматизации тестирования, сборки и развертывания CI/CD снижает риск возникновения ошибок, минимизирует время на исправление проблем и повышает общую эффективность разработки. Внедрение CI/CD позволяет командам сосредоточиться на создании новых возможностей, а не на решении рутинных задач, связанных с процессами тестирования и развертывания.

Преимущества использования GitHub Actions

Интеграция в экосистему GitHub. Actions полностью интегрированы в платформу GitHub, что позволяет использовать их с нативной поддержкой репозиториев, pull request'ов, issues и других функциональных возможностей GitHub.
Расширяемость. Сообщество GitHub активно создает и делится своими действиями в GitHub Marketplace, что позволяет разработчикам быстро находить и использовать готовые решения для своих рабочих процессов.
Гибкость и модульность. Благодаря возможности использования кастомных действий и различных исполнителей, рабочие процессы могут быть настроены под конкретные потребности проекта.
Открытость и доступность. Пользователи могут легко создавать собственные действия и делиться ими с сообществом, а также использовать GitHub Actions как на публичных, так и на частных репозиториях.

Ограничения и особенности

Хотя GitHub Actions предоставляет мощные инструменты для автоматизации, у него есть и свои ограничения:

Ограниченные ресурсы на публичных исполнителях. В зависимости от типа аккаунта (бесплатный или платный), пользователи могут иметь ограничения по времени работы задач, объему вычислительных ресурсов и доступному дисковому пространству.
Конфиденциальность данных. При работе с приватными репозиториями или конфиденциальными данными нужно внимательно подходить к настройке переменных среды и секретов, чтобы избежать утечек информации.

2. Основные концепции

1. Workflow (рабочие процессы)

Это конфигурации автоматизации, которые определяют, когда и как должен выполняться набор действий. Рабочий процесс описывается в формате YAML и хранится в папке .github/workflows репозитория. В одном проекте может быть несколько рабочих процессов.

2. Events (события)

Действия, которые инициируют выполнение рабочего процесса. Это может быть множество событий, таких как push (отправка кода в репозиторий), pull_request (создание или обновление запроса на слияние), или любые другие события, происходящие в репозитории, например, создание релиза, открытие issue или даже планирование по расписанию с использованием cron.

3. Jobs (задачи)

Отдельные шаги, выполняемые в рабочем процессе. Каждая задача может выполняться параллельно или последовательно, в зависимости от конфигурации. Важно отметить, что каждая задача выполняется на отдельном изолированном средстве исполнения (runner), которое может быть как виртуальной машиной, так и контейнером.

4. Steps (шаги)

Это инструкции, которые выполняются в рамках задачи. Шаги могут включать команды оболочки или действия, определенные в самом GitHub Actions. Шаги выполняются последовательно в пределах одной задачи.

5. Runners (исполнители)

Cреды, где выполняются задачи. GitHub предоставляет как общедоступные (hosted) исполнители, на которых можно запускать рабочие процессы, так и возможность настройки собственных (self-hosted) исполнителей для более точного контроля над процессом.

6. Actions (действия)

Это повторно используемые компоненты рабочего процесса, которые могут быть разработаны как самими пользователями, так и сообществом. Это своего рода модули, которые содержат готовую логику для выполнения тех или иных операций, таких как настройка окружения, деплой кода и т.д.

3. Создание первого Workflow

Как создать файл workflow в GitHub Actions

Для создания первого workflow в GitHub Actions необходимо выполнить следующие шаги:

Создайте репозиторий на GitHub, если у вас его еще нет. Это может быть как публичный, так и приватный репозиторий.
Перейдите в репозиторий, в котором вы хотите создать workflow.
Создайте папку для workflow-файлов. Workflow-файлы хранятся в папке .github/workflows вашего репозитория. Эта папка должна находиться в корневом каталоге проекта.
Создайте YAML-файл внутри этой папки. Назовите его соответствующим образом, например ci.yml или build.yml. Этот файл будет содержать все инструкции для GitHub Actions о том, как запускать рабочий процесс (workflow).

Структура команд в этом файле определяется с использованием формата YAML, который прост для чтения и модификации.

Пример создания файла:

mkdir -p .github/workflows
touch .github/workflows/build.yml

Пример простого workflow для сборки проекта

Рассмотрим простой пример workflow, который автоматически собирает проект на языке Python. Этот workflow запускается при каждом новом коммите (push) в репозиторий или при создании Pull Request, и выполняет автоматическую сборку проекта.

name: CI

# Определяем события, которые запускают workflow
on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

# Определяем задачу (job) для выполнения
jobs:
  build:
    runs-on: ubuntu-latest  # Среда выполнения задачи (Linux)

    steps:
      - name: Checkout repository  # Шаг для клонирования репозитория
        uses: actions/checkout@v2

      - name: Set up Python  # Настройка версии Python
        uses: actions/setup-python@v2
        with:
          python-version: '3.9'

      - name: Install dependencies  # Установка зависимостей
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt

      - name: Run tests  # Запуск тестов
        run: |
          pytest

Пояснение к коду:

name: задает имя для рабочего процесса (workflow). Это имя будет отображаться в интерфейсе GitHub Actions.
on: определяет события, которые будут инициировать запуск workflow. В данном случае это события push (каждый новый коммит в ветку main) и pull_request (создание или обновление Pull Request в ветку main).
jobs: описывает задачи, которые будут выполняться. В данном примере задача называется build.
runs-on: определяет платформу, на которой будет выполняться задача. Мы используем образ ubuntu-latest, что означает, что задача будет выполняться в виртуальной машине с Ubuntu.
steps: содержит шаги, которые будут выполнены в рамках задачи:
- actions/checkout@v2 клонирует текущий репозиторий.
- actions/setup-python@v2 устанавливает указанную версию Python (в данном случае 3.9).
- Далее происходит установка зависимостей из файла requirements.txt с помощью pip и запуск тестов с использованием pytest.

Запуск workflow вручную и автоматически

Автоматический запуск workflow

Workflow может запускаться автоматически на основании событий, происходящих в репозитории. В разделе on: YAML-файла можно указать различные события, которые будут инициировать автоматический запуск рабочего процесса:

push: запуск рабочего процесса при отправке кода в определённую ветку (или все ветки).
pull_request: запуск при создании или обновлении Pull Request.
schedule: запуск по расписанию, используя синтаксис cron.
workflow_dispatch: позволяет вручную запускать workflow через интерфейс GitHub.

Пример настройки для автоматического запуска по расписанию:

on:
  schedule:
    - cron: "0 0 * * 1"  # Запуск по понедельникам в полночь

Здесь workflow будет запускаться автоматически каждую неделю в понедельник в 00:00 по UTC.

Запуск workflow вручную

Для возможности ручного запуска рабочего процесса через интерфейс GitHub Actions используется событие workflow_dispatch. Это событие позволяет пользователям запустить workflow в любое время из раздела "Actions" на странице репозитория.

Пример добавления возможности запуска вручную:

on:
  workflow_dispatch:  # Разрешает запуск workflow вручную

Чтобы запустить workflow вручную:

Перейдите в ваш репозиторий на GitHub.
Нажмите на вкладку Actions в верхней части страницы.
Выберите workflow, который вы хотите запустить.
В правой части экрана вы увидите кнопку Run workflow (если настроено событие workflow_dispatch).
Нажмите кнопку, чтобы запустить workflow.

Кроме того, при настройке workflow_dispatch можно передавать параметры при запуске workflow вручную. Например, можно настроить параметры для выбора конкретной ветки или окружения:

on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Выберите окружение для развертывания'
        required: true
        default: 'production'
        type: choice
        options:
          - production
          - staging
          - development

Теперь, при ручном запуске workflow через интерфейс GitHub, пользователю будет предложено выбрать одно из указанных окружений.

Создание и настройка workflows с использованием GitHub Actions предоставляет разработчикам мощные инструменты для автоматизации задач, связанных с тестированием, сборкой и развертыванием приложений. Процесс создания workflow начинается с создания YAML-файла в папке .github/workflows, где можно определить события для автоматического запуска, а также задать шаги, которые будут выполняться в процессе.

Возможность запуска workflows как автоматически, так и вручную делает GitHub Actions гибким инструментом, который может использоваться как для регулярных задач (например, CI/CD), так и для одноразовых операций, требующих ручного запуска.

4. Использование Actions

Как найти и использовать готовые actions из GitHub Marketplace

GitHub Marketplace — это платформа, на которой разработчики могут находить и использовать готовые actions для автоматизации своих workflow в GitHub Actions. Готовые actions представляют собой модули, которые выполняют конкретные задачи, например, установку программного окружения, тестирование кода или деплой.

Шаги по поиску и использованию actions:

Переход в GitHub Marketplace:
- Зайдите на сайт GitHub и перейдите в раздел GitHub Marketplace. Этот раздел доступен на верхней панели сайта.
- В Marketplace можно найти различные расширения для GitHub, включая actions.
Фильтрация по Actions:
- На странице Marketplace выберите категорию Actions в меню фильтрации, чтобы увидеть все доступные готовые actions.
Поиск Actions по ключевым словам:
- В строке поиска можно вводить ключевые слова, связанные с вашими потребностями. Например, для поиска actions, связанных с тестированием, можно использовать запросы вроде "test", "pytest", "CI".
Просмотр информации о конкретной action:
- Нажмите на интересующую action для просмотра её подробного описания. В этом разделе вы увидите инструкции по использованию, поддерживаемые параметры и примеры конфигурации.
Использование action:
- В описании action в GitHub Marketplace всегда приводится пример кода для использования этой action в workflow. Чтобы использовать action, вам достаточно скопировать соответствующий фрагмент YAML-кода и вставить его в ваш workflow-файл (в папку .github/workflows вашего репозитория).

Пример использования готовой action из GitHub Marketplace для настройки Python:

steps:
  - uses: actions/checkout@v2
  - name: Set up Python 3.9
    uses: actions/setup-python@v2
    with:
      python-version: '3.9'

В этом примере используется готовая action actions/setup-python@v2, которая автоматически настраивает выбранную версию Python для выполнения дальнейших шагов.

Написание собственной Action

Если вам нужно выполнить специфические задачи, которые не покрываются готовыми actions, вы можете создать свою собственную action. Собственные actions могут быть использованы для выполнения любых команд или скриптов, а также могут быть общими для использования другими разработчиками.

Существуют два основных типа actions:

Docker Actions: Эти actions запускаются в контейнерах Docker и могут использовать любую среду или инструменты, которые поддерживаются в контейнере. Они подходят для сложных задач, требующих специфической среды исполнения.
JavaScript Actions: Эти actions написаны на JavaScript и выполняются непосредственно в среде Node.js. Они более легковесны и не требуют использования Docker.

Шаги для создания собственной JavaScript Action:

Создайте репозиторий для хранения вашей action или используйте уже существующий репозиторий.
Создайте папку action в корне вашего репозитория. В этой папке будет храниться код вашей action.
Создайте файл action.yml. Этот файл будет описывать вашу action, включая входные данные, выходные данные и команды для выполнения.

Пример action.yml:

name: "Hello World Action"
description: "Простая action, выводящая сообщение Hello World"
author: "Your Name"

inputs:
  who-to-greet:  # Параметр, который принимает action
    description: "Имя человека для приветствия"
    required: true
    default: "World"

runs:
  using: "node12"
  main: "index.js"  # Основной скрипт для выполнения

Создайте файл index.js. Этот файл будет содержать код на JavaScript, который выполняет логику action. Например, он может выводить приветствие:

Пример index.js:

const core = require('@actions/core');

try {
  const nameToGreet = core.getInput('who-to-greet');
  console.log(`Hello ${nameToGreet}!`);
  const time = new Date().toTimeString();
  core.setOutput('time', time);
} catch (error) {
  core.setFailed(error.message);
}

Опубликуйте вашу action. Для этого просто закоммитьте файлы в репозиторий. Если вы хотите, чтобы ваша action была доступна в GitHub Marketplace, нужно выполнить дополнительные шаги по регистрации action на платформе.

Использование вашей action в workflow:

После создания вашей action, её можно использовать в любом workflow. Пример использования:

steps:
  - uses: actions/checkout@v2
  - name: Run my custom action
    uses: your-username/your-repository@v1
    with:
      who-to-greet: 'GitHub Actions'

Здесь используется ваша собственная action из репозитория your-username/your-repository.

Примеры популярных Actions

Существуют множество популярных готовых actions, которые активно используются разработчиками для решения различных задач. Вот несколько примеров:

actions/checkout@v4:
- Описание: Используется для клонирования репозитория в среду выполнения рабочего процесса.
- Пример использования:
```
steps:
  - uses: actions/checkout@v4
```
actions/setup-node@v4:
- Описание: Настраивает среду Node.js для выполнения дальнейших задач.
- Пример использования:
```
steps:
  - uses: actions/setup-node@v4
    with:
      node-version: '14'
```
actions/setup-python@v5:
- Описание: Настраивает среду Python.
- Пример использования:
```
steps:
  - uses: actions/setup-python@v5
    with:
      python-version: '3.11'
```
docker/build-push-action@v2:
- Описание: Action для сборки и публикации Docker-образов. Он полезен для автоматизации задач, связанных с контейнеризацией.
- Пример использования:
```
steps:
  - name: Build and push Docker image
    uses: docker/build-push-action@v2
    with:
      context: .
      push: true
      tags: user/repository:latest
```

aws-actions/configure-aws-credentials@v1:

Описание: Используется для настройки AWS-учетных данных для деплоя на платформе AWS.

Пример использования:

steps:
  - name: Configure AWS credentials
    uses: aws-actions/configure-aws-credentials@v1
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: us-west-2

azure/login@v1:
- Описание: Action для входа в Azure и выполнения задач по развертыванию приложений или управлению инфраструктурой.
- Пример использования:
```
steps:
  - uses: azure/login@v1
    with:
      creds: ${{ secrets.AZURE_CREDENTIALS }}
```

GitHub Actions — это гибкий инструмент для автоматизации процессов разработки и развертывания, позволяющий легко находить, использовать и создавать actions для решения любых задач. GitHub Marketplace предоставляет большое количество готовых решений, которые можно интегрировать в ваши workflows, значительно ускоряя и упрощая процессы разработки. Если готовые решения не удовлетворяют вашим требованиям, можно создать собственные actions, адаптированные под специфические задачи вашего проекта.

5. Управление секретами

Управление секретами в GitHub Actions

GitHub Actions позволяет безопасно хранить и использовать секретные данные, такие как API-ключи, пароли и другие конфиденциальные данные, которые необходимы для выполнения рабочих процессов (workflows). Секреты (secrets) — это переменные окружения, которые хранятся в зашифрованном виде и доступны только внутри контекста выполнения workflow. GitHub предоставляет механизм для безопасного управления секретами, что помогает избежать их утечки или компрометации.

Как хранить секреты в GitHub Actions

Чтобы хранить секреты в репозитории GitHub, необходимо выполнить следующие шаги:

Перейдите в репозиторий на GitHub, для которого нужно создать секреты.
Перейдите в раздел настроек репозитория:
- На странице репозитория нажмите на вкладку Settings (Настройки).
Откройте раздел управления секретами:
- В меню настроек слева найдите раздел Secrets and variables и выберите пункт Actions. Здесь вы сможете управлять секретами для GitHub Actions.
Добавьте новый секрет:
- Нажмите на кнопку New repository secret (Новый секрет репозитория).
- В поле Name укажите имя для вашего секрета. Например, API_KEY или DB_PASSWORD.
- В поле Value введите значение секрета (например, сам ключ API или пароль).
- Нажмите кнопку Add secret, чтобы сохранить секрет. После этого секрет будет доступен только для использования в рабочих процессах (workflows) и не будет отображаться в открытом виде.

Секреты можно создавать как на уровне репозитория, так и на уровне организации. Если ваши workflows используют одни и те же секреты в нескольких репозиториях, их можно добавить в настройки организации.

Примечания по безопасности:

После создания секрета его нельзя просмотреть или изменить, можно только удалить и создать новый.
Секреты могут быть использованы только в workflow и не могут быть вызваны извне репозитория.
Секреты недоступны для workflows, запущенных из pull request, если репозиторий форкнут.

Использование секретов в workflow

Секреты в GitHub Actions доступны в виде переменных окружения. Вы можете использовать их в любых шагах рабочего процесса для передачи конфиденциальных данных в команды или действия.

Пример использования секретов в workflow:

name: CI Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code  # Клонирование репозитория
        uses: actions/checkout@v2

      - name: Set up Node.js  # Настройка Node.js
        uses: actions/setup-node@v2
        with:
          node-version: '14'

      - name: Install dependencies  # Установка зависимостей
        run: npm install

      - name: Use secret API key  # Использование секрета
        run: |
          echo "Using API key: ${{ secrets.API_KEY }}"

Пояснение:

${{ secrets.API_KEY }}: Это синтаксис для доступа к секретам. В данном случае API_KEY — это имя секрета, которое было создано ранее в настройках репозитория.
Секреты как переменные окружения: Секреты автоматически преобразуются в переменные окружения. Например, если у вас есть секрет с именем API_KEY, то в командах можно использовать его как $API_KEY на Linux/macOS или %API_KEY% на Windows.

Примеры использования секретов в workflow

Рассмотрим несколько примеров, как можно использовать секреты в разных рабочих процессах.

Пример 1: Подключение к внешнему API с использованием секретного ключа

В этом примере workflow использует секретный ключ API для отправки запроса к внешнему API. Ключ API хранится как секрет API_KEY.

name: API Request Workflow

on: [push]

jobs:
  request:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code  # Клонирование репозитория
        uses: actions/checkout@v2

      - name: Make API request  # Отправка запроса к API
        run: |
          curl -H "Authorization: Bearer ${{ secrets.API_KEY }}" https://api.example.com/data

Здесь curl используется для отправки HTTP-запроса с заголовком авторизации, содержащим секретный ключ API, который безопасно передается через переменную окружения.

Пример 2: Деплой на сервер с использованием SSH-ключа

В данном примере секрет используется для хранения закрытого SSH-ключа, который необходим для деплоя на удаленный сервер.

Создайте секрет с именем SSH_PRIVATE_KEY, который будет содержать ваш приватный ключ SSH.
Используйте секрет в workflow для настройки SSH-соединения:

name: Deployment Workflow

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code  # Клонирование репозитория
        uses: actions/checkout@v2

      - name: Setup SSH key  # Настройка SSH-ключа
        run: |
          mkdir -p ~/.ssh
          echo "${{ secrets.SSH_PRIVATE_KEY }}" > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan example.com >> ~/.ssh/known_hosts

      - name: Deploy to server  # Выполнение деплоя
        run: |
          ssh user@example.com 'bash -s' < deploy.sh

Пояснение:

${{ secrets.SSH_PRIVATE_KEY }}: Используется для безопасной передачи закрытого SSH-ключа.
Настройка SSH: В шаге настройки SSH создается файл с закрытым ключом, устанавливаются необходимые права доступа, и добавляется хост в список известных.

Пример 3: Использование секретов для доступа к базам данных

Если для вашего workflow требуется подключение к базе данных, секреты могут использоваться для хранения учетных данных, таких как имя пользователя и пароль.

Создайте секреты для имени пользователя и пароля:
- DB_USERNAME: имя пользователя базы данных.
- DB_PASSWORD: пароль к базе данных.
Используйте эти секреты в workflow:

name: Database Access Workflow

on: [push]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code  # Клонирование репозитория
        uses: actions/checkout@v2

      - name: Connect to database  # Подключение к базе данных
        run: |
          mysql -h db.example.com -u ${{ secrets.DB_USERNAME }} -p${{ secrets.DB_PASSWORD }} -e 'SHOW DATABASES;'

Пояснение:

mysql: Команда для подключения к MySQL базе данных. Имя пользователя и пароль передаются через секреты, что обеспечивает безопасность данных.

GitHub Actions предоставляет мощные инструменты для безопасного хранения и использования конфиденциальных данных в рабочих процессах. Секреты позволяют передавать такие данные, как ключи API, SSH-ключи и учетные данные для баз данных, не подвергая их риску утечки. Секреты можно легко настроить через интерфейс GitHub, а их использование в workflow возможно через переменные окружения.

Благодаря тому, что секреты хранятся в зашифрованном виде и доступны только в контексте выполнения рабочего процесса, они обеспечивают высокий уровень безопасности при работе с конфиденциальной информацией в процессе автоматизации.

6. Условия и триггеры

Триггеры для запуска workflow в GitHub Actions

GitHub Actions предоставляет различные триггеры для запуска workflows. Триггеры позволяют инициировать выполнение рабочего процесса (workflow) при наступлении определённых событий в репозитории или по расписанию. Эти события могут быть связаны с изменениями в коде (например, push, pull_request), с планировщиком (schedule), или с ручным запуском (workflow_dispatch).

Основные триггеры для запуска workflow

push — Триггер, который срабатывает при отправке (push) коммита в репозиторий. Этот триггер может быть настроен на выполнение workflow при изменениях в определённых ветках или файлах.

Пример:
```
on:
  push:
    branches:
      - main
    paths:
      - 'src/**'
```
Этот пример показывает, что workflow будет запущен только при изменении файлов в папке src в ветке main.
pull_request — Триггер, который срабатывает при создании, изменении или закрытии запроса на слияние (pull request). Это полезно для проверки изменений перед их слиянием в основную ветку.

Пример:
```
on:
  pull_request:
    branches:
      - main
```
В данном случае workflow будет запускаться при каждом запросе на слияние в ветку main.
schedule — Триггер, который запускает workflow по расписанию с использованием синтаксиса cron. Это удобно для регулярных задач, таких как автоматическое тестирование, сборка или обновление зависимостей.

Пример:
```
on:
  schedule:
    - cron: "0 0 * * 1"  # Каждый понедельник в полночь
```
Этот workflow будет запускаться каждый понедельник в 00:00 по UTC.
workflow_dispatch — Триггер, который позволяет запускать workflow вручную через интерфейс GitHub. Этот триггер также позволяет передавать параметры при запуске.

Пример:
```
on:
  workflow_dispatch:
    inputs:
      environment:
        description: 'Выберите окружение для деплоя'
        required: true
        default: 'production'
        type: choice
        options:
          - production
          - staging
```
В этом примере, при запуске workflow вручную через GitHub, пользователь должен выбрать окружение (production или staging), в котором будет выполнен деплой.
workflow_call — Триггер, который позволяет одному workflow вызывать другой. Это полезно для создания модульных workflows и повторного использования логики.

Пример:
```
on:
  workflow_call:
    inputs:
      version:
        type: string
        required: true
```
Такой workflow можно вызвать из другого workflow, передав необходимые параметры.
repository_dispatch — Триггер, который запускает workflow при поступлении специального вебхука. Этот триггер можно использовать для интеграции с внешними системами, которые отправляют вебхуки в GitHub.

Пример:
```
on:
  repository_dispatch:
    types: [deploy]
```
Здесь workflow будет запущен при получении вебхука с типом события deploy.
issue и issue_comment — Эти триггеры запускают workflow при создании или комментарии к issue в репозитории.

Пример:
```
on:
  issues:
    types: [opened, edited]
```
Этот workflow будет запущен при создании или редактировании issue.

Условия выполнения jobs и steps

В GitHub Actions есть возможность задавать условия для выполнения как отдельных jobs (задач), так и отдельных шагов (steps). Это позволяет создавать более гибкие workflows, где выполнение некоторых частей зависит от определённых условий.

Условия выполнения jobs

Для настройки условий выполнения jobs можно использовать директиву if. Она принимает выражение на языке GitHub Expressions, которое должно возвращать true или false. Если выражение возвращает true, job выполняется, если false — job пропускается.

Пример условия для job:

jobs:
  build:
    runs-on: ubuntu-latest
    if: github.event_name == 'push' && github.ref == 'refs/heads/main'
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

В этом примере job будет выполнен только при событии push в ветку main.

Условия выполнения steps

Аналогично условиям для jobs, вы можете задать условия для отдельных шагов (steps) с использованием директивы if. Это позволяет, например, пропускать отдельные шаги, если какое-либо условие не выполнено.

Пример условия для step:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Run tests only on main branch
        if: github.ref == 'refs/heads/main'
        run: npm test

В этом примере шаг с тестированием будет выполнен только для ветки main. Если workflow запущен для другой ветки, этот шаг будет пропущен.

Часто используемые условия для jobs и steps

Условие в зависимости от статуса предыдущего job или step:

Для того чтобы job выполнялся только в случае успеха или провала предыдущего job, можно использовать встроенные переменные статуса:
- success() — возвращает true, если предыдущий job завершился успешно.
- failure() — возвращает true, если предыдущий job завершился неудачей.
- cancelled() — возвращает true, если job был отменён.
Пример:
```
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run tests
        run: npm test

  deploy:
    runs-on: ubuntu-latest
    needs: test
    if: success()
    steps:
      - name: Deploy to production
        run: ./deploy.sh
```
Здесь job deploy будет выполнен только в случае успеха предыдущего job test.
Проверка типа события:

С помощью переменной github.event_name можно проверять, какое событие инициировало запуск workflow.

Пример:
```
jobs:
  deploy:
    runs-on: ubuntu-latest
    if: github.event_name == 'push'
    steps:
      - name: Deploy to production
        run: ./deploy.sh
```
Этот job будет выполнен только при событии push.
Проверка содержимого pull request:

Можно использовать переменные github.event.pull_request для проверки конкретных полей в запросе на слияние.

Пример:
```
jobs:
  check-title:
    runs-on: ubuntu-latest
    if: github.event.pull_request.title != ''
    steps:
      - name: Validate PR title
        run: echo "Pull request has a title"
```
В этом примере шаг будет выполнен только в том случае, если запрос на слияние содержит заголовок.
Использование значений из secrets:

Условия могут включать проверки на наличие или правильность секретных данных.

Пример:
```
jobs:
  build:
    runs-on: ubuntu-latest
    if: secrets.MY_SECRET != ''
    steps:
      - name: Use secret
        run: echo "Using secret value"
```
Здесь job будет выполнен только в том случае, если секрет MY_SECRET не пуст.

GitHub Actions предоставляет гибкие механизмы для управления триггерами и условиями выполнения workflows, jobs и steps. Вы можете настроить запуск рабочих процессов при различных событиях, таких как коммиты, запросы на слияние, по расписанию или вручную. Кроме того, с помощью условий выполнения можно управлять тем, какие задачи и шаги будут выполнены, что позволяет более точно адаптировать процесс автоматизации под нужды проекта.

Эти инструменты позволяют обеспечить эффективную автоматизацию CI/CD и других задач, минимизировать ресурсы и время выполнения ненужных операций и повысить общую безопасность и управляемость процесса разработки.

7. Отладка и мониторинг

Отладка и мониторинг в GitHub Actions

Отладка и мониторинг выполнения workflows в GitHub Actions — важный аспект для эффективного управления процессами CI/CD. GitHub предоставляет различные инструменты для просмотра логов, анализа статусов и получения уведомлений о состоянии выполнения рабочих процессов.

Просмотр логов выполнения

Каждый workflow, job и шаг (step) в GitHub Actions генерирует логи, которые можно использовать для отладки и анализа ошибок. Логи содержат информацию о ходе выполнения, вывод команд и любые ошибки, произошедшие во время работы.

Как просматривать логи:

Открытие вкладки Actions в репозитории:
- Зайдите в свой репозиторий на GitHub.
- Перейдите во вкладку Actions, которая находится на верхней панели репозитория.
Выбор workflow:
- На странице Actions вы увидите список всех выполненных workflows. Каждый из них будет отмечен цветным статусом:
  - Зеленый (✔) — успешное выполнение.
  - Красный (✖) — ошибка в процессе выполнения.
  - Желтый (⏳) — workflow находится в процессе выполнения или был пропущен.
Просмотр деталей конкретного workflow:
- Нажмите на любой workflow, чтобы увидеть подробности его выполнения. В этом разделе вы сможете увидеть информацию обо всех jobs, входящих в workflow.
Просмотр логов отдельных jobs:
- Нажмите на конкретный job, чтобы раскрыть список шагов, которые были выполнены в рамках этого job.
- Для каждого шага можно просмотреть логи, нажав на стрелку рядом с именем шага. Это покажет все команды, вывод и любые ошибки, произошедшие в процессе выполнения шага.
Загрузка логов:
- В верхней части страницы с логами есть кнопка Download logs. Она позволяет скачать все логи в одном архиве для дальнейшего анализа локально.

Пример лога выполнения:

Run actions/checkout@v2
  with:
    repository: user/repo
    ref: refs/heads/main
    token: ***
Syncing repository: user/repo
Working directory: /home/runner/work/repo/repo
...
Cloning into 'repo'...
Completed job with ID 'build' in 25s

Логи дают детализированное представление о том, что происходило в процессе выполнения, включая команды, выходные данные, ошибки и предупреждения.

Советы по отладке workflow

Отладка workflows может быть сложной задачей, особенно если процесс автоматизации включает в себя множество шагов и внешних зависимостей. Вот несколько советов, которые помогут упростить отладку и диагностику проблем.

1. Используйте `run:` для вывода отладочной информации

Каждый шаг в workflow, где выполняется команда с помощью run:, может использовать стандартные команды для вывода отладочной информации. Например, можно использовать команды echo для вывода переменных или информации о текущем состоянии системы.

Пример:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Print environment variables
        run: |
          echo "GITHUB_REF: $GITHUB_REF"
          echo "CURRENT_BRANCH: ${{ github.ref }}"

Это поможет вам понять, какие переменные окружения и параметры доступны на каждом этапе выполнения.

2. Использование отладочного вывода (debugging)

GitHub Actions поддерживает встроенный режим отладки, который можно активировать с помощью переменной окружения ACTIONS_RUNNER_DEBUG. Эта переменная выводит дополнительную информацию о ходе выполнения workflow.

Для активации отладочного вывода:

Перейдите в Settings вашего репозитория.
Перейдите в раздел Secrets and variables, выберите Variables.
Добавьте переменную ACTIONS_RUNNER_DEBUG и установите её значение true.

Пример использования:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Enable debug output
        run: echo "ACTIONS_RUNNER_DEBUG=true" >> $GITHUB_ENV

После этого в логах вы получите дополнительную информацию, которая может помочь в диагностике проблем.

3. Используйте условные шаги (conditional steps)

Если у вас возникают ошибки только в определённых условиях, полезно использовать условные шаги с директивой if. Это позволяет запускать определённые шаги только при наступлении конкретных условий и избежать ненужного выполнения шагов.

Пример:

steps:
  - name: Run only on main branch
    if: github.ref == 'refs/heads/main'
    run: echo "This step runs only on the main branch"

4. Проверяйте код возврата (exit code)

Для каждой команды, выполненной в рамках run, можно проверять код возврата. Код возврата 0 указывает на успешное выполнение, а любой другой код — на ошибку.

Пример проверки:

steps:
  - name: Run command
    run: |
      some_command || exit 1

Здесь шаг завершится неудачей, если команда some_command завершится с ошибкой.

5. Используйте `continue-on-error` для временного игнорирования ошибок

Иногда для отладки требуется временно игнорировать ошибки в определённых шагах, чтобы workflow продолжил выполнение. Для этого можно использовать параметр continue-on-error.

Пример:

steps:
  - name: Run tests
    run: npm test
    continue-on-error: true

Этот шаг завершится даже в случае ошибки, что позволяет вам диагностировать другие шаги без прерывания процесса.

Использование статусов и уведомлений

GitHub Actions предоставляет механизм для отслеживания статусов выполнения workflows, jobs и steps. Вы можете использовать различные встроенные инструменты для мониторинга состояния выполнения и получения уведомлений о результатах.

1. Статусы jobs и steps

Каждый job и step в workflow имеет статус, который отображается в интерфейсе GitHub Actions. Основные статусы:

success — Успешное выполнение job или step.
failure — Ошибка при выполнении.
cancelled — Задача была отменена.
skipped — Задача или шаг были пропущены из-за условий.

Статусы можно использовать в условиях выполнения других jobs или шагов:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run tests
        run: npm test

  deploy:
    runs-on: ubuntu-latest
    needs: test
    if: success()  # Выполняется только при успешном завершении job "test"
    steps:
      - name: Deploy to production
        run: ./deploy.sh

Здесь job deploy будет выполнен только если test завершился успешно.

2. Использование статусов в уведомлениях

GitHub поддерживает интеграцию с различными внешними сервисами для отправки уведомлений о статусах workflows. Например, вы можете настроить уведомления в Slack, Telegram или других системах через сторонние actions или webhook'и.

Пример отправки уведомления в Slack:

steps:
  - name: Send Slack notification
    uses: 8398a7/action-slack@v3
    with:
      status: ${{ job.status }}
    env:
      SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

В этом примере используется готовая action для отправки уведомления в Slack с использованием webhook URL, который хранится в секрете SLACK_WEBHOOK_URL.

3. GitHub Checks и статусные бейджи

Каждый workflow может автоматически обновлять статусы с помощью GitHub Checks. Это позволяет интегрировать статусы jobs с системами контроля качества и инструментами CI/CD.

Вы также можете добавить бейджи статуса workflows в файл README.md, чтобы отображать текущий статус прямо на странице репозитория:

![CI](https://github.com/owner/repository/workflows/CI/badge.svg)

Этот бейдж будет обновляться автоматически и показывать текущий статус workflow.

Отладка и мониторинг в GitHub Actions — это важная часть обеспечения стабильной работы CI/CD. GitHub предоставляет детализированные логи, статусные метки и возможность ручной отладки для упрощения диагностики проблем. Инструменты, такие как условные шаги, статусы jobs и интеграции с внешними сервисами для уведомлений, позволяют более гибко управлять процессами и быстро реагировать на ошибки.

8. Практическое задание

Практическое задание: Создание собственного workflow для проекта на C# с использованием GitHub Actions

Цель этого задания — создать автоматизированный CI/CD процесс для проекта на C# с использованием GitHub Actions. Мы рассмотрим создание workflow, который будет автоматически запускать сборку проекта, выполнять тестирование и, при успешном завершении, выполнять деплой на сервер. В качестве примера используем проект, написанный на платформе .NET Core.

Шаг 1: Подготовка проекта на C#

Предположим, что у вас уже есть проект на C# с использованием .NET Core, размещённый в репозитории GitHub. В проекте должна быть настроена структура решения с проектом и тестами, чтобы CI/CD процесс мог автоматизировать сборку и выполнение тестов.

Структура репозитория может быть такой:

/MyDotNetProject
  /MyApp
    MyApp.csproj
  /MyApp.Tests
    MyApp.Tests.csproj
  README.md
  .gitignore

Шаг 2: Создание workflow для CI/CD

Для создания workflow необходимо создать YAML-файл в папке .github/workflows вашего репозитория. Этот файл будет содержать инструкции для GitHub Actions по автоматизации процесса сборки, тестирования и деплоя.

Создание базового workflow

В корневом каталоге вашего проекта создайте папку .github/workflows, если она еще не существует.
Внутри этой папки создайте файл ci-cd.yml.

Пример структуры:

mkdir -p .github/workflows
touch .github/workflows/ci-cd.yml

Откройте файл ci-cd.yml и добавьте базовую конфигурацию для сборки проекта на C#.

Шаг 3: Базовая настройка CI для C# проекта

Мы настроим CI процесс, который будет автоматически запускаться при каждом коммите в репозиторий или при создании pull request. Он будет собирать проект и запускать тесты.

Пример конфигурации workflow:

name: CI/CD Pipeline for MyDotNetProject

# Указываем события, которые будут запускать этот workflow
on:
  push:
    branches:
      - main  # Запуск при коммите в ветку main
  pull_request:
    branches:
      - main  # Запуск при создании Pull Request в ветку main

# Определяем задачи (jobs), которые будут выполнены
jobs:
  build:
    # Указываем операционную систему для выполнения задач
    runs-on: ubuntu-latest

    # Шаги, которые будут выполнены
    steps:
      # Шаг 1: Клонирование репозитория
      - name: Checkout code
        uses: actions/checkout@v2

      # Шаг 2: Установка .NET SDK
      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '7.0.x'  # Устанавливаем последнюю версию .NET 7.0

      # Шаг 3: Восстановление зависимостей
      - name: Restore dependencies
        run: dotnet restore

      # Шаг 4: Сборка проекта
      - name: Build project
        run: dotnet build --configuration Release --no-restore

      # Шаг 5: Запуск тестов
      - name: Run tests
        run: dotnet test --no-restore --verbosity normal

Пояснение:

on: push и on: pull_request — workflow запускается автоматически при коммите в ветку main и при создании pull request в эту ветку.
jobs — определяет набор задач, которые выполняются в виртуальной среде ubuntu-latest.
actions/checkout@v2 — клонирует репозиторий с кодом.
actions/setup-dotnet@v3 — устанавливает .NET SDK версии 7.0.x.
dotnet restore — восстанавливает зависимости проекта.
dotnet build — собирает проект в режиме Release.
dotnet test — запускает тесты проекта.

Шаг 4: Добавление деплоя в CI/CD

Теперь настроим этап деплоя, который будет запускаться только в случае успешного завершения сборки и тестов. Деплой можно настроить на любой сервер, поддерживающий деплой через SSH или другие методы, либо в облачное решение, такое как Azure.

Пример деплоя на удалённый сервер через SSH

В настройках репозитория на GitHub создайте секреты для SSH-подключения к вашему серверу:
- SSH_HOST — IP-адрес или доменное имя сервера.
- SSH_USER — имя пользователя для подключения.
- SSH_PRIVATE_KEY — приватный SSH-ключ для аутентификации.
- SSH_PORT (опционально) — порт для SSH (по умолчанию 22).
Добавьте шаг деплоя в ci-cd.yml:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup .NET
        uses: actions/setup-dotnet@v3
        with:
          dotnet-version: '7.0.x'

      - name: Restore dependencies
        run: dotnet restore

      - name: Build project
        run: dotnet build --configuration Release --no-restore

      - name: Run tests
        run: dotnet test --no-restore --verbosity normal

  deploy:
    # Запуск деплоя только после успешного завершения job "build"
    needs: build
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'  # Деплой только в ветке main

    steps:
      - name: Deploy to server via SSH
        uses: appleboy/ssh-action@v0.1.1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          port: ${{ secrets.SSH_PORT || 22 }}
          script: |
            cd /var/www/myapp
            git pull origin main
            dotnet build --configuration Release
            sudo systemctl restart myapp

Пояснение:

needs: build — job deploy будет выполнен только после успешного выполнения job build.
if: github.ref == 'refs/heads/main' — деплой выполняется только при пуше в ветку main.
appleboy/ssh-action — эта action используется для выполнения команд на удалённом сервере через SSH. Команды в script могут включать такие действия, как обновление кода, сборка и перезапуск службы.

Шаг 5: Настройка уведомлений о статусе CI/CD

Вы можете настроить уведомления для получения информации о статусе выполнения workflows. Один из популярных способов — интеграция с Slack или отправка уведомлений через электронную почту.

Пример отправки уведомлений в Slack:

В настройках вашего репозитория добавьте секрет SLACK_WEBHOOK_URL, который будет содержать URL webhook для отправки сообщений в Slack.
Добавьте шаг уведомления в конец вашего workflow:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      # Ваши шаги для сборки и тестирования

  notify:
    runs-on: ubuntu-latest
    needs: [build, deploy]  # Уведомление после выполнения build и deploy
    steps:
      - name: Send notification to Slack
        uses: 8398a7/action-slack@v3
        with:
          status: ${{ job.status }}
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

Этот шаг отправит сообщение в Slack с указанием результата выполнения workflow (успех или ошибка).

Шаг 6: Запуск workflow вручную

Если вы хотите запускать workflow вручную, добавьте поддержку триггера workflow_dispatch. Это позволит вам запускать процесс сборки и деплоя через интерфейс GitHub.

on:
  workflow_dispatch:

Теперь вы сможете вручную запустить workflow через вкладку Actions на странице репозитория, выбрав необходимый workflow и нажав на кнопку Run workflow.

Настройка CI/CD процесса для проекта на C# с использованием GitHub Actions позволяет автоматизировать ключевые этапы разработки: сборку, тестирование и деплой. Вы можете настроить workflow для работы с конкретными ветками, использовать условия для выполнения различных этапов и интегрировать уведомления для отслеживания статуса выполнения. Это решение не только ускоряет процесс разработки, но и снижает вероятность ошибок при ручной сборке и деплое, что является неотъемлемой частью современного подхода к разработке программного обеспечения.

1. Введение в GitHub Actions​

Что такое GitHub Actions?​

Основные возможности​

Пример простого рабочего процесса​

Зачем использовать CI/CD?​

Основные принципы CI/CD​

Зачем использовать CI/CD?​

Пример использования CI/CD в реальном проекте​

Преимущества использования GitHub Actions​

Ограничения и особенности​

2. Основные концепции​

1. Workflow (рабочие процессы)​

2. Events (события)​

3. Jobs (задачи)​

4. Steps (шаги)​

5. Runners (исполнители)​

6. Actions (действия)​

3. Создание первого Workflow​

Как создать файл workflow в GitHub Actions​

Пример простого workflow для сборки проекта​

Пояснение к коду:​

Запуск workflow вручную и автоматически​

Автоматический запуск workflow​

Запуск workflow вручную​

4. Использование Actions​

Как найти и использовать готовые actions из GitHub Marketplace​

Шаги по поиску и использованию actions:​

Написание собственной Action​

Шаги для создания собственной JavaScript Action:​

Использование вашей action в workflow:​

Примеры популярных Actions​

5. Управление секретами​

Управление секретами в GitHub Actions​

Как хранить секреты в GitHub Actions​

Примечания по безопасности:​

Использование секретов в workflow​

Пояснение:​

Примеры использования секретов в workflow​

Пример 1: Подключение к внешнему API с использованием секретного ключа​

Пример 2: Деплой на сервер с использованием SSH-ключа​

Пояснение:​

Пример 3: Использование секретов для доступа к базам данных​

Пояснение:​

6. Условия и триггеры​

Триггеры для запуска workflow в GitHub Actions​

Основные триггеры для запуска workflow​

Условия выполнения jobs и steps​

Условия выполнения jobs​

Условия выполнения steps​

Часто используемые условия для jobs и steps​

7. Отладка и мониторинг​

Отладка и мониторинг в GitHub Actions​

Просмотр логов выполнения​

Как просматривать логи:​

Пример лога выполнения:​

Советы по отладке workflow​

1. Используйте run: для вывода отладочной информации​

2. Использование отладочного вывода (debugging)​

3. Используйте условные шаги (conditional steps)​

4. Проверяйте код возврата (exit code)​

5. Используйте continue-on-error для временного игнорирования ошибок​

Использование статусов и уведомлений​

1. Статусы jobs и steps​

2. Использование статусов в уведомлениях​

3. GitHub Checks и статусные бейджи​

8. Практическое задание​

Практическое задание: Создание собственного workflow для проекта на C# с использованием GitHub Actions​

Шаг 1: Подготовка проекта на C#​

Шаг 2: Создание workflow для CI/CD​

Создание базового workflow​

Шаг 3: Базовая настройка CI для C# проекта​

Пояснение:​

Шаг 4: Добавление деплоя в CI/CD​

Пример деплоя на удалённый сервер через SSH​

Пояснение:​

Шаг 5: Настройка уведомлений о статусе CI/CD​

Пример отправки уведомлений в Slack:​

Шаг 6: Запуск workflow вручную​

1. Введение в GitHub Actions

Что такое GitHub Actions?

Основные возможности

Пример простого рабочего процесса

Зачем использовать CI/CD?

Основные принципы CI/CD

Зачем использовать CI/CD?

Пример использования CI/CD в реальном проекте

Преимущества использования GitHub Actions

Ограничения и особенности

2. Основные концепции

1. Workflow (рабочие процессы)

2. Events (события)

3. Jobs (задачи)

4. Steps (шаги)

5. Runners (исполнители)

6. Actions (действия)

3. Создание первого Workflow

Как создать файл workflow в GitHub Actions

Пример простого workflow для сборки проекта

Пояснение к коду:

Запуск workflow вручную и автоматически

Автоматический запуск workflow

Запуск workflow вручную

4. Использование Actions

Как найти и использовать готовые actions из GitHub Marketplace

Шаги по поиску и использованию actions:

Написание собственной Action

Шаги для создания собственной JavaScript Action:

Использование вашей action в workflow:

Примеры популярных Actions

5. Управление секретами

Управление секретами в GitHub Actions

Как хранить секреты в GitHub Actions

Примечания по безопасности:

Использование секретов в workflow

Пояснение:

Примеры использования секретов в workflow

Пример 1: Подключение к внешнему API с использованием секретного ключа

Пример 2: Деплой на сервер с использованием SSH-ключа

Пояснение:

Пример 3: Использование секретов для доступа к базам данных

Пояснение:

6. Условия и триггеры

Триггеры для запуска workflow в GitHub Actions

Основные триггеры для запуска workflow

Условия выполнения jobs и steps

Условия выполнения jobs

Условия выполнения steps

Часто используемые условия для jobs и steps

7. Отладка и мониторинг

Отладка и мониторинг в GitHub Actions

Просмотр логов выполнения

Как просматривать логи:

Пример лога выполнения:

Советы по отладке workflow

1. Используйте `run:` для вывода отладочной информации

2. Использование отладочного вывода (debugging)

3. Используйте условные шаги (conditional steps)

4. Проверяйте код возврата (exit code)

5. Используйте `continue-on-error` для временного игнорирования ошибок

Использование статусов и уведомлений

1. Статусы jobs и steps

2. Использование статусов в уведомлениях

3. GitHub Checks и статусные бейджи

8. Практическое задание

Практическое задание: Создание собственного workflow для проекта на C# с использованием GitHub Actions

Шаг 1: Подготовка проекта на C#

Шаг 2: Создание workflow для CI/CD

Создание базового workflow

Шаг 3: Базовая настройка CI для C# проекта

Пояснение:

Шаг 4: Добавление деплоя в CI/CD

Пример деплоя на удалённый сервер через SSH

Пояснение:

Шаг 5: Настройка уведомлений о статусе CI/CD

Пример отправки уведомлений в Slack:

Шаг 6: Запуск workflow вручную