chore(release): merge werf upstream into delivery-kit (2.80.2-dk.1) - #387
Conversation
…erf#7856) ## Summary Operations statistics (`--build-report-operations` / `--log-debug`) now cover the whole command run instead of only the conveyor: werf config render, giterminism initialization and pre-build registry/git calls are measured, and the summary is printed once before the command exits. Previously a command spending most of its time before the build reported a summary covering a fraction of it (observed: `build time: 0.14s` out of an 11.8s command, with a 4.2s config render invisible). ## What - The operations summary blocks are printed before the command exits on the commands that save a build report (`build`, `bundle publish`, `converge`, `lint`, `plan`, `render`, `stages copy`); the console line is `command time:` instead of `build time:`. For `converge` the single summary prints after the deploy. - The accepted log level captured at command start is restored before printing, so a nelm action lowering it (e.g. `render` sets Error) does not drop the summary. - Printing respects the effective log verbosity at command start: under `--log-quiet` nothing is printed, and `helm get-autogenerated-values` is quiet by default, so its summary stays hidden as before this PR. - Two new operations appear in the report and the summary: `config render` (werf.yaml templating) and `giterminism init` (git worktree/submodules initialization). - Pre-build registry, git and docker calls are now counted: the existing hooks were no-ops until the collector entered the context. - VERIFIED: smoke on macOS with the Docker backend for `build` and `render` — the summary lists `config render` and `giterminism init`, the JSON report `Operations` section contains them alongside build-phase operations, and without the flag no summary is printed and no sections appear. - The console summary covers the whole command run; a saved JSON report covers the operations recorded since the previous report of the same command — with `--follow` that includes the polling between builds and failed retry attempts. A failed report write does not lose observations: they stay pending until a report is successfully written. - VERIFIED: a 25s `build --follow --dev` session prints one summary with `giterminism init: 13` while the last report carries `giterminism init: 1` and a single-iteration `StageCache`. - Commands not saving a build report (`compose`, `run`, `kube-run`, `export`) keep the previous conveyor-scoped behavior under `--log-debug`. - The JSON report schema does not change; `Operations`/`StageCache` stay opt-in behind the same gate. - SSH passphrase wait is deliberately not measured: it is interactive input, absent in CI. ## Why The collector was created inside `Conveyor.Build()`/`ShouldBeBuilt()`, coupling the statistics scope to the conveyor lifetime: everything before it — config render, giterminism init, sync clientID registry calls — ran with no collector in the context, so the already-placed measurement hooks recorded nothing and the printed total covered only the build. Command-scoped installation with collector reuse in the conveyor closes the gap without touching the hooks or the report schema; the alternative of leaving per-conveyor scope and wrapping each pre-build phase separately would keep the misleading `build time` total and duplicate gate logic in every command. The report keeps per-build semantics via flush-delta summaries because CI parses `--build-report-path` per build, while the console block is a human-facing whole-command view. --------- Signed-off-by: Evgeniy Frolov <evgeniy.frolov@flant.com>
🤖 I have created a release *beep* *boop* --- ## [2.80.0](werf/werf@v2.79.2...v2.80.0) (2026-09-25) ### Features * **build:** collect operations statistics for the whole command run ([werf#7856](werf#7856)) ([51c0d31](werf@51c0d31)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
## Summary The `2` documentation config fails under werf 3 because it still uses the removed Ansible builder. Reproduce with werf 3: `werf config list --dir docs --env test` on the unmodified branch. ## What - Write the web image's nginx configuration with the shell setup already used on main, instead of `ansible.copy`. - Preserve the nginx configuration text, including literal shell variables, and retain the existing `fromImage` and `import.image` references. - VERIFIED: the updated config renders with werf 3.6.1 and werf 2.77.2 for both test and production. ## Why CI must deploy versioned documentation with the same werf 3 driver as current documentation. Port only the incompatible builder block so the maintained branch remains usable by werf 2 as well. Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
## Summary Builds performing repeated reads and writes against a bearer-authenticated registry exchange a new token for each operation, even while an earlier token remains valid. Reuse valid bearer credentials across matching operations to reduce requests to the registry's authorization service. ## What - Sequential and concurrent operations with the same registry, TLS policy, token URL and request identity reuse an in-memory bearer credential; concurrent cache misses share one exchange. - Different credentials, registries and requested scopes remain isolated, and a canceled waiter does not cancel another caller's exchange. - Cached credentials are reused only with more than 30 seconds remaining; near-expiry credentials and credentials rejected by the registry are acquired again, and failed exchanges are not retained. - Registry rejection on an equivalent explicit default port invalidates the cached token; different schemes and nondefault ports remain isolated. - Token-only responses use the Distribution protocol's 60-second default lifetime, supporting GitLab responses without `expires_in`; explicit lifetimes and earlier `issued_at` values bound reuse conservatively. - The cache holds at most 128 credentials per registry API instance and does not persist tokens or add configuration. - OAuth exchanges, refresh-token responses and malformed token responses retain the existing uncached behavior. - Registry operations keep independent upload state and progress completion, including concurrent image and index pushes, tagging and deletion. ## Why Each remote operation constructs a new go-containerregistry client and bearer transport, whose initialization performs a token exchange. Reusing the underlying HTTP connection transport does not retain that authorization. Caching credentials at this transport boundary avoids sharing the dependency's mutable bearer and upload state or retaining per-operation progress options. The fallback lifetime follows the [Distribution token authentication specification](https://distribution.github.io/distribution/spec/auth/token/). Tokens remain opaque; the cache does not interpret JWT claims or change the registry's authorization decisions. The expiry reserve limits reuse near expiration, but does not guarantee token validity throughout a long upload. The existing go-containerregistry behavior when retrying a consumed upload body after an authorization challenge is outside this change. --------- Signed-off-by: Anton Peretrukhin <anton.peretrukhin@flant.com> Co-authored-by: Anton Peretrukhin <anton.peretrukhin@flant.com>
Follow up on werf#7955 with test-only changes. Add an HTTP request without an explicit port so the authority test detects removal of scheme isolation. Widen the expiry test’s cache-hit window from two to ten seconds and its renewal timeout from six to fifteen seconds to tolerate scheduling delays; production code is unchanged. Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
🤖 I have created a release *beep* *boop* --- ## [2.80.1](werf/werf@v2.80.0...v2.80.1) (2026-09-29) ### Bug Fixes * **build:** reduce repeated registry token requests ([werf#7955](werf#7955)) ([08dd45b](werf@08dd45b)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
… immutable field change (werf#7990) Signed-off-by: Dmitry Mordvinov <dmitry.mordvinov@flant.com>
…erf#7993) ## Summary A committed ignore pattern ending in a backslash previously made `werf build` panic with `syntax error in pattern`. Builds now return an error identifying the selected ignore file and invalid pattern. Reproduce with a reachable Docker backend: ```sh mkdir dockerignore-repro && cd dockerignore-repro git init -q printf 'project: ignore-error\nconfigVersion: 1\n---\nimage: app\ndockerfile: Dockerfile\nstaged: false\n' > werf.yaml printf 'FROM scratch\n' > Dockerfile printf '%s\n' Dockerfile 'archive-old\' > .dockerignore git add . git -c user.name=Test -c user.email=test@example.com -c commit.gpgsign=false commit -qm repro werf build --repo=:local ``` ## What - Invalid patterns in `.dockerignore` and `Dockerfile.dockerignore` produce a normal build error naming the file and pattern. - Patterns rejected during lazy compilation, including exclusions such as `![z-a]`, fail during matcher creation instead of panicking during path matching. - VERIFIED: the reproducer exits with code 1 and reports `read ignore file ".dockerignore": parse ignore pattern "archive-old\\": syntax error in pattern` without a panic. - Valid matching, ignore-file selection order, Dockerfile reinclusion, and cache identities remain unchanged; `.gitignore` continues to be interpreted by Git. ## Why The matcher constructor panicked on user-supplied syntax errors, and Moby defers some pattern compilation until matching. Validate every pattern before exposing the matcher and propagate errors through the existing build error path so users can locate and correct the rule. Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
🤖 I have created a release *beep* *boop* --- ## [2.80.2](werf/werf@v2.80.1...v2.80.2) (2026-10-01) ### Bug Fixes * **build:** report invalid .dockerignore patterns without panicking ([werf#7993](werf#7993)) ([1e6268e](werf@1e6268e)) * **deploy:** recreate StatefulSet and other custom-validated kinds on immutable field change ([werf#7990](werf#7990)) ([1a7e9b3](werf@1a7e9b3)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please).
Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
Release-As: v2.80.2-dk.1 Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
Upstream's new report flush spec calls NewBuildPhase(nil, ...), which panics here: the fork's constructor eagerly builds the sbom step from the conveyor's container backend and storage manager. Construct the phase directly with the report options and an images report, the only state the spec exercises. Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com>
Initialize the upstream command-scoped collector before every SBOM get mode so pre-build operations and failures reach the summary. Extend the disabled-SBOM regression to assert config-render timing and command scope. Signed-off-by: Aleksei Igrychev <aleksei.igrychev@palark.com> (cherry picked from commit 7a9a7f5)
|
Validation for
Environment caveat: initial macOS and shared-host Linux unit runs exposed existing mirror-configuration tests that also fail at base Not a full e2e run. All changes are on the topic branch; the PR targets release branch |
|
Maintainer explicitly authorized merging despite the current CI failures. The failed jobs report |
Summary
Sync werf
2throughaa880b349(2.80.2) into delivery-kit2, preserving fork customizations. Pin the next release to2.80.2-dk.1withRelease-As.What
--build-report-operations/WERF_BUILD_REPORT_OPERATIONS.312d2f269472to7d2829eb1373, allowing recreation of StatefulSets and other custom-validated kinds when an immutable field changes and the configured deletion policy permits recreation.sbom getmode, including pre-build operations and failure paths; extend the disabled-SBOM regression to check command-scoped output.CHANGELOG.mdand.release-please/2/manifest.jsonunchanged; release-please owns their update after merge.Release-As: v2.80.2-dk.1in an empty commit and preserve delivery-kit dependencies and commands.Why
Bring the maintenance branch up to werf 2.80.2 without replacing fork behavior or importing upstream changelog entries.