iplweb / bpp / 24717593325
65%

DEFAULT BRANCH: dev
Ran
Jobs 0
Files 0
Run time –
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
24717593325

push

github

mpasternak 
ci(docker-build): staging-tag + Trivy CRITICAL gate przed promocja do canonical

Obecny flow "build -> push -> Trivy scan" byl bezuzyteczny jako gate:
bake pushowal od razu pod kanoniczny tag (:<wersja>, :latest), a Trivy
z --exit-code 0 + continue-on-error + || true zawsze konczyl zielono.
CVE w obrazie masteru trafialby do Docker Hub zanim ktos by go zobaczyl.

Nowy flow (3 fazy):

  1. Build -> push do staging tagu ":sha-<short_sha>" (niekanoniczny,
     unikalny per build, nigdzie nie linkowany)
  2. Trivy gate TYLKO na master:
     - CRITICAL z fixem -> hard fail, promocja sie nie wykonuje
     - HIGH -> raport w GitHub Step Summary (nie blokuje; dominuje szum)
     - --ignore-unfixed -> bez fixa nic nie da sie zrobic
     - skip false-positives: autobahn/cryptosign.py, slapdtest/certs/
  3. docker buildx imagetools create -> promocja manifestu pod
     kanoniczny tag (wersja, :latest na master). Metadata only, ~sek.

Feature branche nie sa skanowane (ich tagi sa tymczasowe, skan dodawal
by 3.5 min do iteracji). Cache Trivy vulndb w /tmp trzyma sie miedzy
skanami 6 obrazow.

Zastrzezenie: Docker Hub nie pozwala un-pushnac digestu. Staging-tag
pattern chroni przed odkryciem (canonical tag nie powstaje), nie przed
istnieniem obrazu w rejestrze. Dla pelnej izolacji trzeba prywatnego
staging registry - niepotrzebne przy obecnej skali.

Dokumentacja flow w naglowku workflow + sekcja "Docker image publishing"
w CLAUDE.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Source Files on build 24717593325
Detailed source file information is not available for this build.