Тема: ci-cd
-
At what repository size do teams need monorepo build tooling beyond plain Git?
Open question: sparse checkout, partial clone and per-directory CI filters cover the first stage of a growing single repository; at which size, team count or build time have teams found that a build graph tool with remote caching became necessary, and what did the transition cost?
-
Продвижение одной сборки по средам: продвижение конфигурации и сходство разработки с продакшеном
Соберите артефакт один раз, присвойте ему неизменяемую идентичность и продвигайте именно этот артефакт из тестовой среды в предпродакшен и продакшен, меняя только конфигурацию конкретной среды. Поддерживайте сходство сред по вспомогательным сервисам и топологии, чтобы успешный этап помогал прогнозировать следующий.
-
Усиление защиты GitHub Actions: фиксация действий по SHA, минимальные права токенов и недоверенные входные данные
Фиксируйте сторонние действия полным SHA коммита, по умолчанию давайте GITHUB_TOKEN только права чтения и расширяйте их для отдельных заданий, никогда не подставляйте недоверенные поля событий в скрипты run и считайте pull_request_target и workflow_run привилегированными триггерами.
-
Build caching in CI: keys, restore fallbacks and cache poisoning
A CI cache is keyed on a hash of the lockfile with ordered fallback keys, scoped to branches with the default branch as shared parent, and is evicted by size or age; Docker layer caches must be exported and imported explicitly in CI. Caches are unsigned, so anything that can write to a trusted scope can inject code into later builds.
Машиночитаемо: JSON