Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Environment secrets стають доступними job лише після виконання налаштованих protection rules. Не друкуйте secrets у logs і не зберігайте їх у workflow або summary-файлах.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →Пояснює передачу secrets у workflow і обмеження secret expressions.
Юзер менеджмент та костилі з якими ви стикнетесь в житті → Першоджерело ↗Не передавайте proprietary code, secrets, logs, customer data або PII зовнішньому AI provider без explicit approval і визначених controls. Спосіб запуску через CLI не змінює governance, privacy та contractual requirements.
Як працювати на спокійному проєкті та з нав’язаними оцінками →Пояснює environments, protection rules, variables, secrets і межу isolation self-hosted runners.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн → Першоджерело ↗Логічна ціль deployment у GitHub Actions, яка може мати власні protection rules, variables і secrets та обмежувати доступ до них.
1. Теорія CI/CD та як ви можете інтегрувати тести в пайплайн →GitHub попереджає, що код workflow на self-hosted runner може скомпрометувати машину та доступні secrets. Один runner виконує одну job одночасно, але це не гарантує ізоляцію між послідовними jobs; для untrusted workflows потрібні ephemeral runners або інша isolation strategy.
Інфраструктура автотестів та її нюанси →Repository-level secrets доступні workflow всього репозиторію, тоді як environment secrets можна обмежити конкретним оточенням і його protection rules. Workflow явно посилається на потрібні значення, тому конфігурація стає частиною контракту запуску, але самі секрети не з’являються у YAML. Кожну job варто уявляти як чистий контейнер або машину на базі визначеного image, наприклад `ubuntu-latest`. Наступне практичне відео показує, як на такому runner послідовно виконати checkout, setup, install і tests.
Runner повинен отримати base URLs, users, passwords, tokens та інші параметри без commit у репозиторій. У GitHub Actions значення можна зберігати як repository secrets/variables або прив’язувати до environments на кшталт DEV, STG і PROD. Environment-level значення зручні, коли ті самі ключі мають різні значення та правила доступу для різних середовищ. На реальному проєкті права на створення або зміну secrets можуть належати не автоматизатору. Це окрема залежність від власників репозиторію чи DevOps-команди, яку треба з’ясувати заздалегідь. Для малого набору параметрів не потрібно будувати складну config-систему: достатньо найпростішого контрольованого scope, який не розкриває секрети.
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.
Код має звертатися до стабільних логічних ключів на кшталт `BASE_URL`, не до `DEV_BASE_URL` або `STAGE_BASE_URL` з ручним replace. Цільове середовище вибирає джерело значень, а не інші назви змінних. Завдяки цьому локальний і CI-запуск проходять тим самим шляхом. У CI значення зберігаються як захищені secrets/variables або як секретний файл. Репозиторій містить лише `.env.example` чи аналогічний шаблон зі структурою та без реальних credentials. Якщо використовується config server, CI може зберігати лише мінімальні credentials для доступу до нього.
Environment variable передає процесу значення на кшталт base URL, username або password без hardcode у вихідному коді. У Unix-подібній оболонці змінну можна експортувати перед запуском; у Windows вона задається іншим системним механізмом. `.env` є зручним локальним представленням таких пар ключ–значення, яке застосунок читає під час старту. Проблема з'являється, коли один продукт має кілька web/API/admin-сервісів і кожному потрібні окремі URL та credentials. Плоский набір ключів розростається, префікси дублюються, а залежності між значеннями стають неочевидними. Для невеликого проєкту `.env` достатній; переходити на складніший формат варто після реального зростання конфігурації.
[Дивитися з 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.
[Дивитися з 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.
У Testomat.io API token не обов’язково є готовим bearer token для всіх запитів: його може бути потрібно обміняти на JWT через login endpoint. Урок демонструє, чому тип авторизації треба перевіряти за документацією та реальною відповіддю API. Секрет зберігається в environment variable, а не в коді. Постійне використання email/password додає зайвий запит і ширший секрет; token flow варто обирати лише якщо backend справді його підтримує.
Перед кожним commit потрібно відкрити список змінених файлів і переглянути конкретні рядки. Досвід не усуває ризик випадково додати пароль, token, локальну конфігурацію, тимчасовий коментар або сторонню зміну. `.gitignore` зменшує ризик, але не замінює перегляд staged diff. Корисна послідовність: перевірити `git status`, додати лише потрібні файли, переглянути staged diff, створити вузький commit і ще раз перевірити гілку перед push. Коментарі в коді оцінюються за користю; назви функцій, змінних і локаторів мають пояснювати намір без зайвого шуму.
Під час перегляду diff виявляється пароль, випадково включений у коміт. Якщо коміт ще не відправлено, в IDE можна виконати Undo Commit, замінити значення, знову переглянути diff і створити виправлений коміт. Важливе уточнення: якщо справжній секрет уже потрапив у remote, видалення з поточного файлу або додавання `.gitignore` недостатньо — секрет залишається в історії. Його треба негайно відкликати або змінити, а очищення історії виконувати за погодженим командним процесом.