Apache Kafka Introduction
Пояснює producers, consumers, topics, retention і partitions.
Вступ до API-автоматизації → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Kafka — ширше, ніж queue
Kafka stores events durably in partitioned topics; reading does not itself remove an event. Retention, replay і ordering within a partition мають бути частиною test design.
Це уточнення навчального спрощення, а не зміна після запису.
Вступ до API-автоматизації →Negative tests для даних і доступу
Спроєктуй negative tests для читання чужого row, підміни owner claim, вставки row поза дозволеним scope та запиту на erasure з legal-retention exception. Відокрем authentication evidence, database authorization і data-lifecycle decision.
Набір cases показує, який шар відхиляє кожну дію та який audit evidence потрібен.
pytest_runtest_makereport
pytest hook, який формує TestReport для фаз setup, call і teardown; custom fixture може використати report для рішення про artifact retention.
Soft delete не доводить GDPR compliance
У відео soft delete й анонімізація розглядаються як спосіб зберегти relational history без ідентифікації людини.
Article 17 визначає право на стирання та винятки, а Recital 26 відрізняє anonymous від pseudonymised data. Реалізація потребує окремих retention і legal-basis rules; soft delete сам по собі недостатній.
2018-05-25
Практика курсу на YOY, домашні завдання та формат ПМП →Storing and sharing data from a workflow
Пояснює upload/download artifacts, retention і передачу test outputs між jobs.
2. Практика та написання пайплану CI/CD → Першоджерело ↗Чому зберігати лише failed traces
Trace для кожного успішного тесту швидко збільшує обсяг CI artifacts. Простий варіант «зберігати все» допустимий для малого набору з коротким retention, але кращий контракт — залишати ZIP лише коли тест упав. Артефакт має жити достатньо, щоб інженер устиг провести root-cause analysis. Retention і upload налаштовуються на рівні CI; сама fixture відповідає лише за локальне створення файлу.
Composite action і artifacts
Повторювані checkout, setup `uv`, setup Python та install dependencies винесено у локальний composite action. Input `install-playwright` вмикає браузерні залежності лише для jobs, яким вони потрібні. Це виправдане перевикористання, бо той самий setup уже виконується в smoke і regression jobs. Після тестів workflow завантажує HTML report і Playwright traces як artifacts. Для них задається retention, наприклад 14 днів: це тимчасові діагностичні результати, а не постійне сховище. HTML report зберігається завжди, traces — переважно після failure.