SSH key pair
GitHub SSH authentication uses a private key kept on the local machine and a corresponding public key added to the GitHub account; a passphrase protects the private key at rest.
2. Git Workflow у PyCharm/IntelliJ →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Що змінилося після запису
Урок пропонує уявляти job як чистий container або окрему машину.
GitHub окремо визначає GitHub-hosted і self-hosted runners. Hosted job отримує fresh runner instance за documented contract, але environment не перетворює self-hosted runner на isolated container.
Перевірено за документацією 2026-07-31; точна дата зміни не встановлена.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Що змінилося після запису
Publish job завантажує report artifacts і deploys GitHub Pages.
Поточний official Pages flow вимагає configure-pages, upload-pages-artifact і deploy-pages; deploy job має needs, pages: write, id-token: write, environment github-pages і може повертати canonical page_url.
Поточний contract перевірено 2026-07-31; одна дата зміни не встановлена.
2. Практика та написання пайплану CI/CD →Choosing the runner for a job
Уточнює відмінність GitHub-hosted і self-hosted runners та contract runs-on.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн → Першоджерело ↗Artifact
Файл або набір файлів, створений під час workflow run і збережений GitHub для обміну між jobs або подальшого завантаження.
2. Практика та написання пайплану CI/CD →CI secret
Protected value, яке workflow отримує через secret context або environment, а не з version-controlled source. Відсутній secret у GitHub Actions expression повертає порожній string.
Юзер менеджмент та костилі з якими ви стикнетесь в житті →Як працює SSH-доступ до GitHub
SSH використовує пару ключів. Приватний ключ залишається лише на довіреному комп’ютері й не публікується. Публічний ключ призначений для передавання сервісу на кшталт GitHub: сервер пов’язує його з акаунтом і перевіряє, що клієнт володіє відповідним приватним ключем. Якщо локальний проєкт уже ініціалізовано як Git-репозиторій, PyCharm/IntelliJ може опублікувати його через Share Project on GitHub. Перед цим варто налаштувати автентифікацію та перевірити, під яким акаунтом працює IDE.
GitHub-акаунт і авторизація в JetBrains IDE
Спочатку потрібно створити та підтвердити GitHub-акаунт. У settings JetBrains IDE знаходиться розділ GitHub, де можна увійти через browser authorization. У відео також згадується personal access token як альтернатива. Ця авторизація дає IDE можливість створювати, клонувати та оновлювати repositories.
Валідація workflow й підсумок
Спроба вивести URL через `run` у неправильному місці YAML ламає workflow schema, і GitHub відхиляє конфігурацію ще до тестів. Команду переносять усередину валідного step. IDE plugin і GitHub validation допомагають ловити такі структурні помилки до або одразу після push. Фінальний мінімальний ланцюжок: pytest створює `allure-results`, test jobs передають їх як artifacts, publish job генерує site, GitHub Pages розміщує report, а Playwright traces поки зберігаються окремо як надійний diagnostic artifact.
Публікація report у GitHub Pages
Окрема publish job завантажує artifacts, створені smoke/regression jobs, готує Pages artifact і виконує deployment. Artifact є мостом між runners: файл, створений однією job, не з’являється автоматично на машині іншої job. У repository settings джерелом Pages обирається GitHub Actions, а environment `github-pages` отримує правила deployment, сумісні з task branches. Наприкінці workflow ще має test failures, тому урок завершується чесною межею: механізм pipeline і Pages показано, але конкретні нестабільні тести потребують подальшого розбору.
Коміт і публікація на GitHub
Перед першим комітом Git запитує ім’я та email автора. Автор радить не встановлювати ці значення глобально, якщо для особистих і робочих репозиторіїв використовуються різні облікові дані. Після локального коміту проєкт можна опублікувати через Share Project on GitHub, авторизувати PyCharm і створити remote-репозиторій. Коміт і публікація — різні дії: зелений статус файлів показує локальну індексацію/зміни, а наявність remote і push потрібно перевіряти окремо. Підсумкова стратегія локаторів: обирати читабельні атрибути, які команда може контролювати; домовлятися про них з розробниками; accessibility-, CSS- та XPath-підходи використовувати відповідно до реальної розмітки, а не як догму.
CI runners, agents і вартість виконання
GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Генерація ключа, passphrase і 2FA
Показано генерацію ключа командою `ssh-keygen` з email-коментарем, вибір шляху збереження та введення passphrase. Символи passphrase в терміналі не відображаються — це нормальна поведінка. Публічну частину додають у GitHub Settings → SSH and GPG keys. Приватну частину не копіюють у GitHub, чати або репозиторій. Додатково рекомендується ввімкнути двофакторну автентифікацію. Після зміни налаштувань автентифікації IDE може знадобитися перезапуск.
Клонування існуючого repository
Якщо repository вже існує на GitHub, GitLab чи Bitbucket, правильний початок — `Git Clone`, а не повторна публікація. З Git hosting копіюється HTTPS або SSH URL, в IDE обирається локальна папка, після чого проєкт клонується. GitHub Desktop може виконати ту саму операцію, але відео демонструє вбудовані IDE-інструменти.
Домашні завдання через GitHub
[Дивитися з 10:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=630s). Щотижня очікується один або кілька нових tests. Перша домашня робота публікується як repository link; наступні — в окремих branches і pull requests порівняно з `main`. Це дає reviewer-у точний diff конкретного модуля, а учневі — невеликий, але реальний portfolio artifact. Якщо PR уже merged, треба чітко вказати commit або зміни, які відповідають домашній роботі.