CI secret
Protected value, яке workflow отримує через secret context або environment, а не з version-controlled source. Відсутній secret у GitHub Actions expression повертає порожній string.
Юзер менеджмент та костилі з якими ви стикнетесь в житті →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Self-hosted runner не є isolation boundary
GitHub попереджає, що код workflow на self-hosted runner може скомпрометувати машину та доступні secrets. Один runner виконує одну job одночасно, але це не гарантує ізоляцію між послідовними jobs; для untrusted workflows потрібні ephemeral runners або інша isolation strategy.
Інфраструктура автотестів та її нюанси →Using secrets in GitHub Actions
Пояснює передачу secrets у workflow і обмеження secret expressions.
Юзер менеджмент та костилі з якими ви стикнетесь в житті → Першоджерело ↗Self-hosted runners reference
Фіксує поточні властивості, routing і responsibility model self-hosted runners.
Інфраструктура автотестів та її нюанси → Першоджерело ↗GitHub-акаунт і авторизація в JetBrains IDE
Спочатку потрібно створити та підтвердити GitHub-акаунт. У settings JetBrains IDE знаходиться розділ GitHub, де можна увійти через browser authorization. У відео також згадується personal access token як альтернатива. Ця авторизація дає IDE можливість створювати, клонувати та оновлювати repositories.
Full Line completion і GitHub Copilot
В IntelliJ IDEA вмикається Full Line completion для Java. На відміну від звичайного completion, яке пропонує проіндексовані класи, методи й доступні члени об'єктів, Full Line completion намагається запропонувати цілий рядок на основі контексту коду. Викладач описує цю модель як локальну й радить спочатку попрацювати саме з нею. GitHub Copilot може запропонувати кілька рядків, метод або клас, але така генерація не гарантує коректності. Для повторюваних Page Objects і тестових дій підказки можуть бути доречними, проте кожну пропозицію потрібно читати й перевіряти. У відео також наголошено на відмінності між локальною моделлю та передаванням контексту сторонньому сервісу.
CI runners, agents і вартість виконання
GitHub і GitLab називають виконавців jobs runners, Jenkins — agents. Хмарні runners зручні, але в приватних організаціях хвилини виконання можуть тарифікуватися. Self-hosted runner працює всередині інфраструктури компанії, дає більше контролю над ресурсами й доступами та часто зменшує операційну вартість регулярних прогонів.
Публікація локального проєкту
Для локального проєкту використовується IDE action `Share Project on GitHub`: вказується назва repository та його visibility. Перед першим commit треба переглянути список файлів. `.idea`, логи та інші локальні артефакти не мають випадково потрапити до repository.
Клонування існуючого 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 або зміни, які відповідають домашній роботі.
Мережевий доступ і self-hosted runners
Відкривати приватне середовище для широкого діапазону IP хмарного CI дорого в підтримці й збільшує поверхню атаки. Практичніший варіант — runner усередині контрольованої мережі: GitHub або GitLab передає йому job, а сам runner уже має потрібний маршрут до тестової інфраструктури. Доступ усе одно обмежують мережевими правилами й мінімальними правами конкретного runner.
Локальний і глобальний Git config
Кожен commit містить ім'я та email автора. Якщо на машині є персональний GitHub, корпоративний акаунт і окремий клієнтський профіль, один глобальний config може створити неправильну історію авторства. Тому для робочих репозиторіїв корисно задавати `user.name` і `user.email` локально. Практичні команди: `git config --list --show-origin` показує активні значення та їх джерела; `git config user.name` і `git config user.email` читають поточну ефективну ідентичність; `git config --local user.name "Name"` та `git config --local user.email "email@example.com"` задають її лише для поточного репозиторію. Для груп каталогів Git також підтримує умовні include-правила, наприклад окремий профіль для всіх репозиторіїв певної компанії.