Using secrets in GitHub Actions
Пояснює передачу secrets у workflow і обмеження secret expressions.
Юзер менеджмент та костилі з якими ви стикнетесь в житті → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
CLI не скасовує policy та data risk
Не передавайте proprietary code, secrets, logs, customer data або PII зовнішньому AI provider без explicit approval і визначених controls. Спосіб запуску через CLI не змінює governance, privacy та contractual requirements.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Self-hosted runner не є isolation boundary
GitHub попереджає, що код workflow на self-hosted runner може скомпрометувати машину та доступні secrets. Один runner виконує одну job одночасно, але це не гарантує ізоляцію між послідовними jobs; для untrusted workflows потрібні ephemeral runners або інша isolation strategy.
Інфраструктура автотестів та її нюанси →Визначити дозволену AI trust boundary
Випишіть типи даних, які workflow передає provider.
Позначте secrets, PII, customer data, proprietary code та contractual restrictions.
Для кожного типу визначте allowed provider, redaction, retention і approval owner.
Не запускайте workflow, доки blocking policy questions не закриті.
Data-flow checklist із дозволом або явною забороною для кожного типу даних.
Калібруйте перевірку за ризиком
Repository diff є засобом порівняння, а не доказом якості. Перегляньте й зрозумійте зміну, запустіть релевантний check/test і перевірте observable behavior; для authentication, sensitive data, secrets та safety-critical code потрібен сильніший oversight.
Репозиторій як довідник до модулів →Не публікуйте дані робочого проєкту
Перед запитанням або прикладом приберіть domains, secrets, персональні дані й identifiers зі screenshots, HTML та endpoint fragments.
Практика курсу на YOY, домашні завдання та формат ПМП →Що не можна комітити
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
Одна схема ключів, CI secrets і `.env.example`
Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
Environment configuration і secrets
Environment-specific base URLs, client IDs, users і non-secret defaults можуть жити в typed configuration/enum. Client secret, password і tokens не комітяться: вони передаються з CI secret store/environment. Відео показує enum/singleton-like initialization. Важливіший invariant: immutable configuration можна безпечно читати parallel tests, а mutable token/session state не можна безумовно розділяти між users/threads.
Environment variables і межа простого `.env`
Environment variable передає процесу значення на кшталт base URL, username або password без hardcode у вихідному коді. У Unix-подібній оболонці змінну можна експортувати перед запуском; у Windows вона задається іншим системним механізмом. `.env` є зручним локальним представленням таких пар ключ–значення, яке застосунок читає під час старту. Проблема з'являється, коли один продукт має кілька web/API/admin-сервісів і кожному потрібні окремі URL та credentials. Плоский набір ключів розростається, префікси дублюються, а залежності між значеннями стають неочевидними. Для невеликого проєкту `.env` достатній; переходити на складніший формат варто після реального зростання конфігурації.
AI як інструмент оптимізації та межі дозволеного
[Дивитися з 02:15](https://www.youtube.com/watch?v=reaHS8_pZbU&t=135s). AI може прискорити механічний refactoring, роботу з CI pipelines, Docker images, reporting, logs і повторюваними змінами. Цінність виникає не від підписки як такої, а від знайденого repeatable workflow: зібрати потрібний context, виконати вузьку задачу, перевірити diff і зберегти лише підтверджений результат. У відео звучить порада приховувати AI use через CLI та локальні ignore rules, якщо client його забороняє. Це ризикована практика: відсутність desktop app не робить передачу даних невидимою для network/security controls і не скасовує contractual restrictions. Без explicit approval не можна передавати proprietary code, secrets, logs або customer data зовнішньому provider. Безпечний шлях — узгоджений tool, дозволений data scope, redaction і локальний/offline workflow там, де це справді відповідає policy.
Живий продукт, test design і безпечні запитання
[Дивитися з 08:00](https://www.youtube.com/watch?v=viR9Rnmxse4&t=480s). YOY навмисно лишається живим продуктом із evolving behavior, щоб учні бачили не стерильні приклади, а неоднозначні UI states, responsive issues, calendars, images, links, QR та chat/network mode. Помічену неточність не варто автоматично списувати на «специфіку»: вона може розростися в regression. Питання про робочі проєкти треба анонімізувати — прибирати domains, secrets, персональні дані та інші identifiers зі screenshot, HTML або endpoint fragment.
Перевірка staged diff перед commit і push
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Організація test class, `boolean` і практика
Рекомендований порядок у класі: test data, самі tests, а потім допоміжні methods. Спершу можна залишати methods біля конкретного test class, побачити реальне дублювання й лише тоді ділити UI на Page Objects або components. `Boolean.parseBoolean` і `assertEquals(expected, actual)` показані як ще один приклад перетворення тексту з UI; практична задача — написати три-чотири читабельні tests, винести secrets у `.env` і потренувати IDE refactorings.