▶️ Запуск CI из Jira

Часто нужно запустить специфичную джобу для конкретной задачи: пересчитать метрики, перепроверить безопасность, прогнать дополнительные тесты. Обычно мы идём в Jenkins или GitHub Actions, ищем нужную джобу, вводим параметры.

Информация о нужном действии находится в Jira, но инструмент для его выполнения — отдельно. Хочется проще: добавил лейбл к задаче и всё запустилось автоматически.

Что можно сделать:

Jira отправляет вебхук с информацией о лейблах в GitHub через repository_dispatch. GitHub Actions ловит это событие, парсит лейблы и запускает нужные шаги. На примере ниже: если в Jira добавили лейбл rebuild-docker, GitHub Actions пересобирает Docker образ. После выполнения можно написать результат комментарием обратно в Jira.

name: Jira Triggered Job

on:
  repository_dispatch:
    types: [jira-trigger]

jobs:
  handle-trigger:
    runs-on: ubuntu-latest
    steps:
      # Парсим labels из payload'a
      - name: Parse Jira event
        id: parse
        run: |
          LABELS="${{ fromJSON(github.event.client_payload).labels }}"
          ISSUE="${{ fromJSON(github.event.client_payload).issueKey }}"
          
          echo "issue=$ISSUE" >> $GITHUB_OUTPUT
          echo "labels=$LABELS" >> $GITHUB_OUTPUT
          echo "Получены labels: $LABELS для issue: $ISSUE"
      
      # Если в labels есть 'rebuild-docker', запускаем пересборку
      - name: Rebuild Docker
        if: contains(steps.parse.outputs.labels, 'rebuild-docker')
        run: |
          echo "🐳 Пересобираем Docker для ${{ steps.parse.outputs.issue }}"
          docker build -t myapp:latest .
          docker push myapp:latest
          echo "DOCKER_STATUS=✅ Docker образ успешно пересобран" >> $GITHUB_ENV
      
      # Если в labels есть 'run-tests', запускаем тесты
      - name: Run Tests
        if: contains(steps.parse.outputs.labels, 'run-tests')
        run: |
          echo "✅ Запускаем тесты для ${{ steps.parse.outputs.issue }}"
          npm test
          echo "TESTS_STATUS=✅ Тесты пройдены успешно" >> $GITHUB_ENV
      
      # Если в labels есть 'security-scan', запускаем проверку безопасности
      - name: Security Scan
        if: contains(steps.parse.outputs.labels, 'security-scan')
        run: |
          echo "🔒 Security scan для ${{ steps.parse.outputs.issue }}"
          npm audit
          echo "SECURITY_STATUS=✅ Security scan завершен" >> $GITHUB_ENV
      
      # Пишем результаты комментарием в Jira
      - name: Comment in Jira
        if: always()
        uses: actions/github-script@v7
        with:
          script: |
            const issue = context.payload.client_payload.issueKey;
            const labels = context.payload.client_payload.labels;
            
            let comment = '🤖 Автоматизированные действия:\n\n';
            
            if (labels.includes('rebuild-docker')) {
              comment += '✅ rebuild-docker: Docker образ пересобран\n';
            }
            if (labels.includes('run-tests')) {
              comment += '✅ run-tests: Тесты запущены\n';
            }
            if (labels.includes('security-scan')) {
              comment += '✅ security-scan: Проверка безопасности завершена\n';
            }

Затем добавьте триггер в Jira, который будет отправлять пейлод:

{
  "event_type": "jira-trigger",
  "client_payload": {
    "issueKey": "{{issue.key}}",
    "labels": "{{issue.labels}}"
  }
}

на урл:

https://api.github.com/repos/ВАШ_НИК/ВАШ_РЕПО/dispatches

с headers:

Authorization: token ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Accept: application/vnd.github.v3+raw+json
Content-Type: application/json

Замените ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx на ваш GitHub токен, который можно получить по пути GitHub → Settings → Developer settings → Personal access tokens → Tokens.

Это особенно полезно в больших командах, где не все имеют доступ к GitHub Actions, но все работают с Jira. QA может добавить security-scan — и проверка запустится автоматически.

🐸 Библиотека devops'a

#арсенал_инженера

🐸 Библиотека devops'a

#пятничный_деплой

💾 На полке в университете нашли Unix

В хранилище Университета Юты нашли магнитную ленту 1973 года с надписью «UNIX Original From Bell Labs V4». Если это действительно четвёртая версия Unix, то это один из самых важных артефактов в истории программирования.

V4 — это первая версия Unix, написанная на языке C вместо ассемблера. Именно это сделало Unix портируемым: код можно было скомпилировать для разных компьютеров почти без изменений.

Полная копия V4 долго считалась потеряной. Остались только куски кода и справочные страницы. Третья и пятая версии хорошо документированы, а четвёртая — пропуск в истории. Между тем она знаменует момент, когда операционная система превратилась из эксперимента Bell Labs в систему, которую можно переносить и учиться на ней.

➡️ Источник

🐸 Библиотека devops'a

#пульс_индустрии

🛠 Изоляция тестовых данных

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

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

export TEST_SCHEMA="t_$(uuidgen | tr -d '-')"
psql -c "CREATE SCHEMA ${TEST_SCHEMA};"
pytest --db-schema="${TEST_SCHEMA}" ; rc=$?
psql -c "DROP SCHEMA ${TEST_SCHEMA} CASCADE;"
exit $rc

Схема создаётся перед тестами, используется, например, в pytest через параметр --db-schema, а затем удаляется.

🐸 Библиотека devops'a

#root@prompt

🤩 MX Linux наконец стал systemd-friendly

Вышла MX Linux 25 «Infinity» — первая версия, построенная на Debian 13 «Trixie».

Главное изменение: если раньше MX позиционировал себя как systemd-free дистрибутив, то теперь все ISO идут с systemd по умолчанию. Это не значит, что сторонников sysVinit выгнали — для Xfce и Fluxbox есть sysVinit варианты.

Инсталлятор получил поддержку 64-bit UEFI Secure Boot. Теперь можно ещё и настроить zram swap-устройства. Доступны три десктопа: Xfce 4.20, KDE Plasma 6.3.6 и Fluxbox 1.3.

➡️ Release notes

🐸 Библиотека devops'a

#пульс_индустрии

🔒 Статистика паролей за 2025 год

В 2025 году наибольший слив паролей случился с утечкой 16 миллиардов паролей — одна из крупнейших в истории. При этом 94% пользователей повторяют пароли на разных сервисах, что усиливает риски.

Три четверти паролей не соответствуют базовым требованиям безопасности, а простые пароли типа «123456» до сих пор в лидерах по использованию.

💬 Какие практики применяются у вас на проекте? Находили листочки с паролями на мониторе? Делитесь в комментах👇

➡️ Статистика по паролям

🐸 Библиотека devops'a

#разбор_полётов

❓ Как внедрить zero-trust между микросервисами

Для внедрения zero-trust между микросервисами в DevOps нужно последовательно наложить несколько ключевых слоёв безопасности.

Первое — включить mTLS с распределённой идентичностью на уровне ворклоадов с помощью SPIFFE/SPIRE. Это значит каждой службе присваивается короткоживущий X.509-сертификат (SVID), который автоматически ротацируется и используется для взаимной аутентификации и шифрования трафика.

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

Далее — построить авторизацию по идентичности, используя RBAC или Open Policy Agent (OPA). Это даёт возможность задавать политики доступа в зависимости от конкретной сущности-сервиса, а не на уровне IP или сети. Ещё слой сетевых ограничений добавляют Kubernetes NetworkPolicy, которые ограничивают коммуникацию только разрешёнными путями.

В Kubernetes для реализации zero-trust-mTLS удобно использовать сервис-меши типа Istio, Linkerd или Ambient Mesh (sidecarless). Для мультикластера нужна федерация trust domains, чтобы распространять доверие и идентификацию между кластерами, а также централизованный аудит для мониторинга и инцидент-реакции.

🐸 Библиотека devops'a

#задача_со_звёздочкой

😊 AI-помощник, который всегда под рукой

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

Вы просто кликаете «Watch Screen», и помощник анализирует ваш экран, помогая разобраться с любыми вопросами без излишних переключений. Это экономит время и позволяет сохранить концентрацию на важном.

➡️ Поспрашивать про свой экран

🐸 Библиотека devops'a

#арсенал_инженера

📉 Главные тренды DevOps в России

Новый отчет State of DevOps Россия 2025 раскрывает ключевые направления развития практики DevOps в России.

Cloud-трансформация — отдельный важный тренд. Managed- и PaaS-сервисы меняют подходы к инфраструктуре и автоматизации процессов.

DevSecOps в отчете рассматривается как необходимый элемент безопасности, внедряемый без ущерба для скорости разработки.

Искусственный интеллект становится помощником, снимая нагрузку с специалистов и оптимизируя бизнес- и продуктовые процессы.

🐸 Библиотека devops'a

#пульс_индустрии

🛠 Управление политикам в Kubernetes по-человечески

Kyverno — это policy engine, работающий внутри Kubernetes. Он позволяет проверять, изменять и создавать ресурсы на основе заданных политик.

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

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

В недавнем обновлении 1.16.0 появились новые фичи и фиксы:

• Добавлен vigilant mode, который запрещает использование celPreconditions без validate.cel.

• Исправлены ошибки в тестах generate VAP chainsaw.

• Добавлены функции генерации отчетов для MAPs.

• Исправлены проблемы с обновлением статуса, вызванные разным форматом времени.

• В Helm chart добавлена поддержка рендера Openreports ресурсов и возможность включения соответствующих флагов.

И другие изменения.

➡️ Репозиторий
➡️ Release Notes

🐸 Библиотека devops'a

#арсенал_инженера