DEV Community: Leo

A native ClickHouse target lands in a CI platform, and the boring parts are the point

Leo — Tue, 15 Sep 2026 10:25:19 +0000

The first thing I do when a new database target lands in a CI tool is check what happens to my secrets. Not the marketing screenshots. The connection string, the password, and the retry behaviour when the query hangs at 3am. Buddy shipped a native ClickHouse target last week, and it clears exactly that first checkpoint: store the connection once, then run queries, schema migrations, and post-deployment data checks from any pipeline step.

If you have ever wired ClickHouse into a generic runner, you know the shape of the pain. You stash a URL and a password in five secret variables, then paste a clickhouse-client invocation into shell steps across three workflows, and hope nobody adds a verbose flag that echoes the DSN into a public build log. The new target moves that plumbing behind a stored connection you configure at the workspace level.

What actually changes in the day

A native database target is not a headline feature. It is a quiet one, and that is why I like it. Look at the workflow it unlocks: a schema migration step that reads the same stored connection as the downstream analytics check, a post-deploy assertion that counts rows against the release you just cut, a rollback path that does not require re-entering credentials during a hotfix at the worst possible hour.

Two things I would still test before trusting this in a critical release path. First, how the target surfaces errors when a query times out or returns a partial result set, because ClickHouse queries can succeed loudly and fail quietly on tail cases. Second, whether the audit trail on the stored connection is granular enough to answer "who ran what against production last Thursday" without an export dance through three UIs.

How other tools tackle the same job

You have options for pointing a pipeline at ClickHouse, and each of them makes a different trade. An honest tour:

dbt. If your team already lives in dbt for transformations and tests, dbt is the stronger pick for analytics checks against ClickHouse. Its test primitives were built for exactly that shape, and the community around ClickHouse-flavoured dbt is real.
Flyway or Liquibase. Dedicated schema-migration tools with community and third-party ClickHouse drivers. Worth the extra layer if you need repeatable, versioned migrations with proper checksums.
Bytebase. A change-management surface on top of migrations, with review workflows and drift detection. Overkill for a small stack, appropriate when compliance wants a paper trail.
GitHub Actions or GitLab CI with clickhouse-client. The lowest-friction path when your team has strong Bash discipline and does not want another abstraction. The trade is exactly what a stored native target is now solving: credentials spread across secret variables until nobody remembers which one the migration step reads.
Buddy. A fair option when you want the connection stored once and the same target reused across query, migration and post-deploy check steps in one pipeline. See the ClickHouse target release notes for the specifics.

What I am watching next: whether the stored target composes cleanly with the pipeline's existing secrets and outputs surface, so a migration step and an analytics check can share a hostname without pretending to share a transaction. That is the part that decides whether this stays a nice convenience or becomes the default way I reach for ClickHouse in a build.

Google named Leader in Gartner's inaugural Enterprise AI Assistants Magic Quadrant

Leo — Mon, 14 Sep 2026 00:27:14 +0000

Google Cloud said this week that Gartner has placed it in the Leaders quadrant of its inaugural 2026 Magic Quadrant for Enterprise AI Assistants, on both axes: Completeness of Vision and Ability to Execute. The Google post ties the placement to Gemini Enterprise, which it frames as moving past chat into multi-step, end-to-end workflows driven by AI agents.

The badge is a marketing outcome. What lands on a platform team is the product framing. Per Google's post, Gemini Enterprise drives multi-step, end-to-end workflows through AI agents, and those are the workflows a pipeline already runs.

What the announcement actually contains

The post asserts a Leader placement on both dimensions and links to the full Magic Quadrant through Gartner. It does not restate Gartner's methodology, the other vendors on the chart, or the specific criteria weighted for a category that did not exist before. What is public is Google's placement claim and the Gemini Enterprise pitch attached to it.

Where an assistant lands in the pipeline

Two things carry over into build and deploy work regardless of a ranking.

First, agent workflows need credentials somewhere. An assistant that reaches into source control, an artifact store, or a runner is a new principal in the identity system. It inherits whatever access the surrounding tooling already grants, and the surface is wider than a demo shows.

Second, multi-step means auditable, or it does not. Every action an agent takes should leave a trace a reviewer can read later. If the audit event drops the agent's identity, or collapses ten steps into a single line, the trail stops being useful during a post-incident review.

For platform teams the useful questions start after the badge: which scopes an assistant is granted, whose audit log the actions land in, and what the blast radius looks like when an agent misfires. Those answers belong in a runbook.

Your DevOps platform's real bill is not on the invoice

Leo — Sun, 13 Sep 2026 16:24:59 +0000

The first time I watched a finance partner cross-reference our CI/CD invoice with actual minutes burned, I felt my stomach drop for the platform team. We had negotiated the seat price down to the cent. We had not really priced the six-minute pipeline that ran a hundred and fifty times a day across three environments, or the four engineers who quietly kept the runner fleet from wandering off. GitLab put out a blog post this week that names this whole shadow bill directly, and it is worth reading with a spreadsheet open.

The framing is simple. Subscription fees and license costs, GitLab writes, "only tell one part of the story." The total cost of ownership for a DevOps platform also includes variable costs like CI/CD compute and AI usage, plus the infrastructure, tools, and employee time required to keep software delivery moving. There is nothing revolutionary in that sentence, but I have watched enough platform reviews go sideways on exactly this point to be glad someone is writing it down as a checklist.

The line items nobody prices at signup

When you buy a CI/CD platform you buy a promise about seats. What you consume, month after month, is closer to a utility bill.

Start with compute. Every hosted-runner minute has a rate card, and the rate goes up sharply once you leave the free tier or step onto a bigger machine class. If you have not looked at your own numbers lately, pull the last three months of runner minutes by workflow and sort descending. Usually one or two workflows dominate. Then look at how many of those runs were retries, PR churn, or scheduled jobs that nobody remembers scheduling. That is real money.

Then AI usage. Any platform now shipping agent features or in-editor assistants prices those on tokens or requests, and the meter runs whether the suggestion shipped or not. In my own team we saw the AI line item move from a rounding error to a real budget conversation in about a quarter, and we were not doing anything unusual with it. If you have not yet, ask your vendor for a per-user, per-day breakdown before signing a bigger tier.

Then the human line. Engineer time to build custom actions, to babysit self-hosted runners, to chase flaky tests, to onboard a new team onto the pipeline template. This is the cost that never appears on any invoice and often outweighs everything else. GitLab's post lumps this in with "the infrastructure, tools, and employee time required to keep software delivery moving," which I think is exactly right, if a little polite about how large that number can get.

A back-of-the-envelope that will not embarrass you

If your finance partner wants a defensible number, four buckets get you most of the way:

Subscription and seats. Sticker price times headcount, minus whatever multi-year discount you actually secured. This is the easy row.
Variable platform usage. Hosted-runner minutes, storage for artifacts and caches, network egress if your platform meters it, and AI or agent tokens. Pull last quarter, annualise it, and add a growth factor honest to your hiring plan.
Adjacent infrastructure. Self-hosted runner fleet (VMs, container hosts, the load balancer in front of them), the secrets manager, the artifact registry, and whatever observability you point at CI. Some of this may already be on a cloud bill; count it anyway.
People time. Platform engineers dedicated to the pipeline, plus a fraction of every other engineer's week that goes to pipeline maintenance instead of shipping. A conservative one day per engineer per month is a starting point; measure it if you can.

Add the four. That is your TCO. It will be a bigger number than the invoice, and that is the point.

Where the platforms actually differ

The comparison worth having is not "which one has the lowest seat price." It is which one moves cost from the invoice into your engineering-hours column, or the other way around. A few honest observations, based on running or watching each of these in production:

GitHub Actions is where most teams already are, so the marginal seat cost is often zero. The bill quietly grows through Actions minutes on hosted runners and, more recently, Copilot and agent tokens. If you host your own runners you inherit the whole babysitting workload, and it is not trivial.
GitLab CI/CD couples the pipeline to the SCM, the registry, the security scanners and now agent features in one subscription. That collapses several line items, which is the pitch the linked post is implicitly making. The trade-off is a heavier product surface to run, especially self-managed, and a real migration cost if you are not already there.
CircleCI is a strong pick when your bottleneck is orchestration on hosted infra and you want to stop thinking about runner ops. It bills on credits, which makes forecasting straightforward, and its parallelism controls can genuinely bring wall-clock time and cost down at the same time. If you are heavy on custom Docker workflows across many services, it deserves a real look before anything else on this list.
Buildkite flips the model: hosted control plane, your compute. If you already have a good Kubernetes or bare-metal fleet, the compute line collapses into an existing cloud bill and the platform bill stays small. If you do not, you are back to babysitting runners.
Jenkins has no license line, which is what makes it deceptively cheap. The people-time bucket is where the money lives, and it lives there permanently. I still like Jenkins on teams with a real platform crew and an unusual pipeline shape; I would not pick it fresh today for a small team optimising for TCO.
Buddy (buddy.works) is one option worth weighing when the human-time bucket is your worst one and you would rather build pipelines by dragging actions than by writing YAML. The pipeline editor collapses a lot of the setup work into visual configuration, which can lower the engineer-hours side of TCO for smaller teams. It is not the right answer if you want deep programmatic control of every step, or if your team already has a fluent YAML-first workflow that they like; CircleCI or Buildkite will fit better there.

None of these is universally cheapest. Cost lives in the shape of your team and your workload, not in the sticker price.

The rough edge

A TCO worksheet is only as honest as your telemetry. If you cannot tell me which workflow burned the most runner minutes last month, or how many AI calls your agents made and for what, you are not calculating TCO, you are guessing at it. Before you compare vendors, spend a week getting those two numbers out of your current platform. The comparison gets much shorter after that.

What I am watching next

I want to see whether platforms start publishing their AI and agent usage in the same shape as their compute usage: per user, per project, per pipeline, exportable. The compute meter got readable over the last few years, mostly because customers demanded it. The AI meter is where the compute meter was in 2019, and finance will be back with the same questions soon enough. If your vendor cannot show you a clean per-project AI breakdown yet, put it on the next QBR agenda. Mine did.

Google's Antigravity SDK lets you assemble your own agent hub

Leo — Sun, 13 Sep 2026 08:26:08 +0000

I have wanted this thing for months. Not the SDK exactly, but the small dignity of running an agent inside my own hub and being able to answer, at any point, "what is it doing right now?". Google's Antigravity SDK, published on September 8, 2026, is the piece I was waiting for: the same runtime that powers Antigravity 2.0 and the Antigravity CLI, exposed as a library you can wire into your own control plane.

If you are on a platform team that has been quietly weighing "adopt a managed agent platform" against "build our own hub and keep control of the trust boundary", this changes the shape of that conversation. You are no longer choosing between the polished commercial box and a wall of glue code.

What the SDK actually is

Google frames the choice honestly. For teams that want turnkey deployment and governance, the pitch is still Gemini Enterprise Agent Platform. The SDK is for the other camp: developers with bespoke workflows or custom execution engines, building lightweight agent hubs from the ground up. What they get is the runtime engine used inside Antigravity 2.0 and its CLI, published as a library. When the core runtime is updated, agents built on the SDK inherit those changes automatically.

The runtime supports Gemini 3.1 Pro and Gemini 3.8 Flash, and the announcement centres on a Python API.

The four pieces I care about

Google groups the SDK around four building blocks, and each one maps onto a real pain I have hit trying to run agents in production workflows.

Start with skills. A skill in the Antigravity SDK is a folder with a SKILL.md file, and the runtime picks them up from filesystem paths you pass in, then injects them into the agent's prompt dynamically. No external registry to babysit. If you have ever shipped a prompt-template package and regretted the release process, you will feel the difference on your first commit.

Next, the built-in file tools. The SDK ships LIST_DIR, FIND_FILE, SEARCH_DIR, VIEW_FILE, CREATE_FILE and EDIT_FILE, and they execute only inside directories you list in the workspaces parameter, governed by declarative safety policies such as policy.workspace_only(). Operations outside the authorized paths are blocked. This is the part I would have hand-rolled badly. Having it as a first-class config item saves an entire class of near-misses.

Then the session trajectories. Every conversation carries a save_dir and a conversation_id, and the runtime persists full turn trajectories, tool receipts and artifacts under traj-<conversation_id>. Reattach a session by passing the same id back in. Anyone who has tried to reconstruct what an agent actually did from a scrollback buffer will read the trajectory docs first.

Last, the lifecycle hooks. Async hooks fire at session start, before and after each tool call, and at session end. The pre_tool_call_decide hook is the human-in-the-loop gate: your code can approve, modify or reject a tool call before it runs. Hooks also broadcast telemetry over WebSockets, which is how the Google post frames the dashboard use case: watch multiple agents live and steer them when they drift.

There is a small extra treat in the response API. A single model response exposes three concurrent async iterators: response for the visible tokens, response.thoughts for the internal reasoning deltas, and response.tool_calls for typed tool events. If you want a UI that shows the agent's thinking in one pane and its actions in another, that is the shape you want.

Where it fits, and where I would still hesitate

The best fit is a platform team that already knows what an agent hub should feel like for its developers, and just wants a runtime that will not fight them. The declarative workspace policies mean you can hand a hub to a product team without also handing them a paved road to shell out.

I have two honest reservations. The SDK is Python in this announcement, so a JVM or Go platform team is looking at a sidecar or a wait. And it is a Google runtime built to run Gemini models. If your compliance story requires model portability, an SDK that lists two Gemini variants as its supported models is a signal to plan for that boundary early.

What I am watching next

Two things. Whether the trajectory format is stable enough to use as a compliance artifact (auditors love a directory of receipts, as long as the schema does not drift on them). And whether other agent runtimes take the "skills are directories" shape seriously. If they do, prompt packaging finally starts to look like software, and CI teams stop shipping prompts through backchannels.

If you try it, tell me what your first hook did. Mine will be a boring one: log to the same aggregator every other service already writes to, so on-call has one place to look.

GitLab's Co-Create recap lands W3C trace context and merge-train limits in CI/CD

Leo — Sun, 13 Sep 2026 00:26:35 +0000

What shipped

GitLab's Co-Create program recap, published September 10, names three shipped CI/CD changes worth pulling out from the marketing frame: W3C Trace Context variables inside pipeline jobs, configurable merge-train pipeline limits, and a REST API for Terraform state protection rules. All three landed via GitLab's user-collaboration program in the first half of 2026, per the post.

Two new predefined variables, CI_TRACEPARENT and CI_TRACESTATE, bring W3C Trace Context into pipeline jobs. Teams can now correlate traces across parent and child pipelines, per GitLab, so a slow child pipeline stops being an opaque "10 more minutes" in the parent's timeline.

Configurable merge train pipeline limits landed alongside that. Teams can set a cap that matches their plan and capacity, per the post. If your merge train has ever quietly grown into a queue nobody remembered to cap, this is the knob.

The third change is a REST API for Terraform state protection rules covering retrieve, create, update and delete. Protection-rule state moves out of the UI and into whatever governance pipeline already runs for the rest of your infrastructure controls.

Where it will bite

The tracing variables close a real observability gap, but they are variables, not spans. You still need an OpenTelemetry-aware collector on the runner side, or a job step that reads the variables and emits its own span, before anything shows up in your tracing backend. GitLab exposes the context; the plumbing between the CI job and the trace store is on you.

The merge-train limits ship as a per-project setting, per the post. That helps a team owning one monorepo; it does not help a platform team that wants one cap across a hundred projects. Watch for whether an instance-wide equivalent follows.

Co-Create itself was credited with more than 650 contributors and 4,874 product improvements across more than 100 product groups in H1 2026. The number to hold onto is the smaller one: three CI/CD changes that will change what your pipeline can do next Monday.

Kubernetes 1.37 promotes gang scheduling to a first-class Workload API in beta

Leo — Sat, 12 Sep 2026 16:26:35 +0000

Kubernetes 1.37 promotes three pieces of the Workload-Aware Scheduling (WAS) effort to beta, giving batch and ML pipelines a native, all-or-nothing scheduling primitive that until now lived in third-party operators. Per the release blog, the Workload and PodGroup APIs, Workload-Aware Preemption (WAP), and shared Dynamic Resource Allocation (DRA) ResourceClaims for PodGroups all graduate together.

Gang scheduling itself is not new. Volcano, YuniKorn and Kueue have carried the pattern in operator form for years, each with its own PodGroup shape and its own answers on preemption and quota. The v1.37 beta is the same idea standardised into an API surface that the in-tree scheduler and the built-in Job controller can consume directly, without an out-of-tree scheduler plugin in the loop.

What actually graduates

Three things move from alpha to beta together, per the Kubernetes post:

The Workload and PodGroup APIs, the objects that let the scheduler treat a set of pods as a unit and refuse to place any of them unless all of them can be placed.
Workload-Aware Preemption, the eviction logic that respects those grouping semantics instead of pulling one pod out of a gang and stranding the rest.
Shared DRA ResourceClaims for PodGroups, so a group of pods that needs one GPU allocation or one network-fabric slice can share the claim rather than each pod holding its own.

The Job controller is updated in the same release to consume the expanded APIs. That is the piece that matters for anyone who already runs batch or distributed training as Jobs. The blog lists advanced scheduling policies, more flexible disruption modes, and topology-aware placement as the new Job-level surface.

Two enablers ship alongside. A workloadbuilder Go library and a set of controller-integration APIs aim at operator authors who want to plug their own controllers into WAS without reimplementing the primitives from scratch.

Where a platform team feels it

Anywhere a pipeline schedules a distributed training run, a Spark job, or a large parallelised test matrix onto a shared cluster. The failure mode WAS is targeting is the one platform teams have been papering over with quotas and priority classes: half a training job's pods land, the other half wait behind a preemption, and the scheduled half sits burning GPU hours while the workload cannot actually start. All-or-nothing scheduling lines the accounting up with what the job needed.

A related win is preemption you can reason about in a runbook. Under classic priority-based preemption, evicting one pod of a training gang effectively stalled the whole gang until the missing pod was rescheduled. WAP evicts at the workload boundary. Easier to explain to a data-science team asking why their run died, easier to page on.

The alpha piece to note but not depend on

Landing in alpha next to the beta graduations is a CompositePodGroup API, which layers multi-level topology constraints onto the PodGroup shape. The blog frames it around hierarchical workloads such as JobSet and LeaderWorkerSet, where a single logical training run is a group of groups: leaders, followers, and a specific placement relationship between them.

Alpha means feature-gated off by default. Do not build a production dependency on CompositePodGroup during the 1.37 cycle. The shape may shift before beta.

Adoption and rollback

The three beta pieces are enabled by default on upgrade. If a platform team runs a rule of "GA only in production", that rule still keeps WAS out until a later release. If the rule is "beta and above", the operational question is what your existing batch stack does when the built-in scheduler starts honouring PodGroup objects it did not previously understand. Volcano, Kueue and their peers each need their own audit against the native semantics before you flip a workload from operator-managed to controller-native, and the audit is the part that will surprise you if you skip it.

Rolling back is a feature-gate disable on kube-apiserver, kube-controller-manager and the scheduler, followed by a restart. There is no data migration to unwind: a Workload object is CRD-shaped, and an older scheduler ignores it. Walk that path on a staging cluster before the upgrade, not after a bad preemption at 3am.

Safari Technology Preview 252 adds @supports named-feature(), unprefixed user-select and two accessible-name fixes

Leo — Sat, 12 Sep 2026 16:08:09 +0000

I wired up the small pieces of this release before writing anything, and the ones I wanted most were the two I could not fake before. Named-feature() as a test, and a way to read a rule's own condition back off the OM. Not a headliner drop, but it clears a couple of stubborn corners.

Safari Technology Preview 252 was published 11 September 2026 by Jon Davis and pulls in WebKit changes between 319252@main and 320112@main. Preview channel, one engine, no Baseline claim on any of this.

What actually landed

Five items, all small, all hand-authorable:

@supports named-feature(...) now parses. A test aimed at behaviours that were previously undetectable — the ones a property/value probe or a selector() body could not reach.
CSSConditionRule.supports and CSSMediaRule.matches are exposed to the CSSOM.
The unprefixed user-select property is supported.
text-decoration-inset now accepts percentage values.
Two accessible-name fixes. A display: contents element no longer includes text from its siblings in its accessible name. And list marker text no longer leaks into accessible names or values that requested the text without markers.

What I'm watching next

Named-feature() is the one to prototype under a @supports block. It's the escape hatch we haven't had — where a property/value pair or a selector() test can't answer whether a behaviour is on. Cross-engine landing is the next signal to watch. The two accessible-name fixes are the ones I'll re-run screen-reader spot checks against, because those are the kind of quiet correctness change that only shows up when you go looking.

Kubernetes 1.37 turns native histograms on by default for its own metrics

Leo — Sat, 12 Sep 2026 08:24:38 +0000

Kubernetes 1.37 flips native histograms on by default for its own metrics, per the release blog. It is a beta graduation of the change that landed in 1.36 alpha under KEP-5808, and it targets one specific pain: the shape of the duration data the control plane exposes to Prometheus.

Enabled by default means most clusters upgrading to 1.37 will start emitting the newer format without an opt-in flag. Whether your monitoring stack ingests it is a separate question.

Classic histograms, briefly

A classic Prometheus histogram exports one time series per bucket boundary. A ten-bucket histogram with a handful of labels quietly turns into dozens of series, and the TSDB pays for every one of them. Get the boundaries wrong at design time and the data is quietly useless: latency that shifts into microseconds, or blows past the top bucket, vanishes into +Inf, and any histogram_quantile call over coarse buckets interpolates its way to a plausible-looking wrong answer. The Kubernetes blog names all three of these: the bucket guessing game, cardinality cost, and interpolation error.

What ships in 1.37

Native histograms replace the fixed-bucket exposition with dynamically-sized buckets driven by the observed distribution. The blog cites duration and latency metrics as the target, calling out API server request latencies and scheduling durations. The KEP has been baking since 1.36; the beta step means enabled by default, still tunable through the standard feature-gate machinery if you need to back it out.

The release calls the result high-resolution, low-cardinality observability, with a meaningful drop in telemetry storage and scraping overhead. That is the design goal restated, and the mechanism plausibly delivers it. Nothing in the release notes says otherwise.

Where a CI/CD team feels it

Anywhere a pipeline reads control-plane latency percentiles to gate a step. If your progressive-delivery job queries API server request-duration percentiles to decide "cluster is healthy, promote the canary," the shape of the data behind that query is different in 1.37. Higher-resolution percentiles are the upside. The downside is that any alert threshold calibrated against interpolated numbers from classic buckets may fire at slightly different times, or stop firing, once the histogram gets more honest about what actually happened.

Same story for the internal SLO dashboards that platform teams point at their clusters. The number you looked at last week and the number you look at next week are computed by different code paths, even if the label set on the graph is identical.

The scrape side is the catch

Native histograms are a Prometheus feature. Your scrape stack has to understand them to store them. If you run an older Prometheus, an ingester that only speaks classic exposition, or a hosted metrics vendor that has not shipped native-histogram support yet, the new series can be dropped or downgraded to the classic representation on the wire, and the storage and quantile benefits go with them. The Kubernetes post does not enumerate a minimum stack; check your ingester's own release notes before you count the win. OpenTelemetry's exponential histogram is a sibling design solving the same problem from a different direction, so if your pipeline already routes through an OTel collector there is a translation step to think through as well.

Second catch: it is beta. Beta in Kubernetes has meant "enabled by default and generally reliable" for a while now, but it is still not GA. If the platform team has a rule about only running GA features on production clusters, native histograms sit on the wrong side of that line until a later release lifts them.

Rollback path

Standard feature-gate disable across the API server, controller manager and scheduler, followed by a restart. That is the operational read: nothing you have not done before, no data migration to unwind, dashboards revert to their previous shape the moment the classic exposition comes back. Worth walking through on a lab cluster before the upgrade, not during it.

interactive-widget lands in WebKit: three ways to react when the keyboard opens

Leo — Sat, 12 Sep 2026 04:08:51 +0000

You built a chat UI. Sticky composer at the bottom, position: fixed. On a phone the user taps the input, the on-screen keyboard slides up, and your composer sits under it. Or it does not. Or it does on one browser and not the other, and the layout viewport is a different height than it was two seconds ago, and half your app has scrolled itself into a corner. That behaviour, which used to be the browser's business alone, now has a knob. WebKit just wired it up.

The knob, and where it lives

The directive is interactive-widget, and it goes inside the same viewport meta tag you already have in every mobile page. Bramus confirmed the WebKit implementation on his blog and shows the exact shape:

<meta name="viewport"
      content="width=device-width, initial-scale=1.0, interactive-widget=resizes-content">

Three values are defined. Each one answers the same question a different way: when a virtual keyboard (or any similar interactive UA widget) opens, which viewport should react?

Two viewports, one keyboard

Fast refresher, because the values only make sense against it. A mobile browser tracks two viewports on the same page. The layout viewport is what CSS resolves against, the box 100vh and your fixed elements pin themselves to. The visual viewport is the currently visible slice of that layout, which can shrink when the user pinch-zooms or when browser chrome eats into it. Historically the keyboard could shrink either, both, or neither, and the choice was the browser's.

interactive-widget moves that choice into the meta tag:

resizes-visual is the default. Only the visual viewport gets smaller. Your layout stays the same size; the keyboard just crops what the user can see of it. Fixed elements do not move.
resizes-content shrinks both viewports. The layout viewport becomes shorter for as long as the keyboard is up. 100vh reports the new, shorter height. Fixed elements reflow against it.
overlays-content shrinks neither. The keyboard is drawn on top of the page and the layout is left alone, similar to what the Virtual Keyboard API's overlaysContent = true gives you.

The default matches what Safari has always done and what Chromium switched to in Chrome 108, back in 2022, when the two engines aligned on "keyboard shrinks only the visual viewport" as the baseline. What is new is that a page can now opt out of the default in either direction.

Picking a value for a real layout

Think in mechanism, not vibes. The value you want is the one that keeps your positioning math honest while the keyboard is on screen.

If your UI is a normal document, an article, a form, a settings page, leave the default. resizes-visual means your CSS heights do not twitch, the user scrolls the field into view, and life carries on. Changing it here would break more than it fixes.

If your UI is a full-height app shell with a bottom-pinned toolbar (chat composer, note editor, camera controls), you probably want resizes-content. The layout viewport becomes shorter, 100vh reports the smaller height, and the toolbar you pinned to bottom: 0 sits above the keyboard instead of behind it. No JavaScript required, no manual measurement of the keyboard height, no listening for visualViewport.resize. You give up some layout stability, because a keyboard toggle now triggers a real reflow. That is the price for the layout you asked for.

If you are drawing your own chrome and want the keyboard to feel like a floating panel on top of the app, overlays-content is the honest answer. Nothing reflows; you take responsibility for whatever the keyboard is now covering, exactly as you would with the Virtual Keyboard API in overlay mode.

Three values, one line of HTML, and the layout algorithm follows.

The support caveat you should not skip

Two things to know before you ship it.

First, "WebKit implemented it" is not the same sentence as "Safari shipped it". Bramus makes the distinction explicit and says it is not yet confirmed whether the WebKit implementation will actually land in Safari. WebKit is the engine; Safari is one of the browsers that ships that engine, and features can sit in WebKit for a while before a Safari release picks them up. To try it today he had to build WebKit locally and run it in the MobileMiniBrowser shell on the iPhone Simulator, which is not a workflow you hand to users.

Second, since this is a viewport meta directive, an engine that has not implemented it will simply ignore the token and fall back to its own default behaviour. That is fine. You can add interactive-widget=resizes-content to your app shell today and it will do nothing on browsers that do not know the value yet, and start doing the right thing on the ones that do. Progressive enhancement, in the most literal sense.

Where this leaves mobile layout craft

The Virtual Keyboard API has been the JavaScript answer to this problem for a while, and it is still the right tool when you want to know the keyboard's pixel height and lay out around it. What interactive-widget gives you is the declarative, HTML-only version: one directive in the tag you already ship, no scripts, no measurements. The two overlap on the overlays-content case and diverge everywhere else.

The interesting part is what a second engine picking this up does to the shape of the problem. A keyboard-aware layout has always meant either trusting the browser or measuring with JS and crossing your fingers. A meta directive that both major engines respect turns the question into a design choice that lives next to your other viewport tokens. Now the work is picking which value your app actually wants, and watching whether Safari itself picks up the WebKit change.

When your pipeline is fast and your product still isn't

Leo — Sat, 12 Sep 2026 00:25:23 +0000

The last time I tuned a CI pipeline from twelve minutes down to five, I felt like I'd earned my paycheck for the quarter. Then a PM told me that the feature we were racing to ship had been in prioritization discussions since April. It was August. My five minutes suddenly felt smaller.

I thought about that conversation while reading Brad Nelson's piece on DevOps.com, "DevOps' Three Ways Were Never About Tooling." Nelson, who wrote "I Think, Therefore I Know: Scientific Thinking for Unscientific Organizations" and co-hosts The Agile for Agilists podcast, has a blunt argument. The community that reads a site like this one (and yes, I mean us) has been reducing DevOps maturity to a CI/CD scoreboard, and he thinks we are grading the wrong test.

The argument, in his words

Nelson walks through the original DevOps canon: Flow, Feedback, and Continual Learning. His claim is that each was written to apply to the whole system that turns an idea into revenue, and each has been quietly narrowed to the slice an engineer can see from their laptop.

On Flow, he asks a question I have been unable to shake: "what does the movement of value look like from aha to ka-ching?" His example, borrowed from Mik Kersten's "Project to Product," is a Nationwide analysis showing that only 2.5 percent of a 120-day end-to-end flow lived in development. If that number is anywhere near right for your org, adding engineers to speed up code is optimizing the least of it.

On Feedback, Nelson is stricter than most CI/CD writing I read. Value can only be judged by the customer, he argues, so an internal loop, however fast, is not the loop that matters. He cites the familiar research (Pendo, Standish Group, Microsoft, Google) that around 80 percent of shipped features are rarely or never used. Fast delivery of the wrong thing is a more efficient way to be wrong.

On Continual Learning, his framing is that feedback without a behavior change is a report, not learning. Every roadmap, he writes, is a stack of hypotheses until a user gets near it.

Where the DX crowd should sit with this

I want to defend our patch of ground for a moment. Faster pipelines are a component of Flow, not a distraction from it, and it is much easier to measure a build queue than a boardroom. But Nelson is landing a fair blow. Every deploy-frequency chart I have ever presented has treated "deploy" as the finish line. The customer meeting the change is the actual finish line. Deploy is a checkpoint on the way there.

Where I would push back a little: the CI/CD scoreboard is not only vanity. When my team's median PR-to-main dropped under an hour, product started proposing smaller experiments, because the cost of trying one had collapsed. Fast pipelines change what leadership dares to attempt. That is Flow too, even if it is downstream of the interesting decisions.

The verdict I'm sitting with

Nelson does not hand you a Monday morning to-do list, and I think that is honest, because the answer depends entirely on where your 120 days actually live. If most of your lead time is in a build queue or a flaky test suite, keep tuning. You will feel the difference on your next PR. If most of it is in a prioritization meeting that reconvenes every two weeks, no runner upgrade will save you. It is a product problem wearing a pipeline costume.

What I am watching next: whether the platform-engineering movement, which has spent a couple of years building golden paths for engineers, starts building the equivalent for the product-decision loop. That is the part of the pipeline no one has a Grafana dashboard for yet, and it is the part Nelson is asking us to look at.

GitLab's critical patch: unauth file read from the commits API

Leo — Fri, 11 Sep 2026 16:26:11 +0000

Every CI system is a trust hierarchy pretending to be a build tool. Somewhere at the bottom of that hierarchy, someone put an authentication check that assumed the caller had already been checked. This week that assumption cost GitLab a Critical.

GitLab shipped patch releases 19.3.2, 19.2.6, and 19.1.8 on September 10, per the release note. Eighteen CVEs across Community Edition and Enterprise Edition, two of them Critical, six High, nine Medium, one Low. The self-managed guidance is the usual: upgrade immediately. GitLab.com is already running the patched version. GitLab Dedicated customers do not need to take action.

You do.

The one to open first

CVE-2026-85706 is the top of the read. Per the advisory: "an unauthenticated user could have read arbitrary files from the GitLab server due to improper path confinement and missing authentication enforcement in the repository commits API." Unauthenticated. Arbitrary files. From the commits API. Three phrases you never want in the same sentence.

For self-managed the affected range is CE and EE 18.7 through 19.3, and the fix landed only in 19.1.8, 19.2.6 and 19.3.2. If your platform team has been letting patch windows slip because "we're on the latest minor", check whether "latest minor" means 19.3.0 or 19.3.2. There is a difference now, and it is public.

The second Critical, CVE-2026-87719, has a smaller blast radius but a sharper one for anyone running Duo Chat. The advisory: "an authenticated user with Duo Chat access to obtain Advanced Search instance configurations and sensitive credentials using a specially crafted GraphQL subscription argument." Sensitive credentials. From a chat surface. Through a GraphQL subscription. If your assistant integration was already the part of the deployment nobody quite audited, congratulations: it is now the part nobody quite audited that also leaks configuration.

What the CI owner should actually rotate

Past the two Criticals, CVE-2026-88765 (High) is next on the pile: "an authenticated user to achieve remote code execution by importing a specially crafted Git project export to overflow the Unicode conversion buffer." Project import is exactly the surface a Developer-role account is expected to touch. Now it is also a Unicode-buffer overflow away from RCE on the instance that owns your pipelines.

Then CVE-2026-79708, also High: "a developer user to execute a policy test pipeline on projects within their group and access protected CI/CD variables." Protected CI/CD variables are the ones you told your compliance reviewer would only be reachable by protected branches on production jobs. A developer with policy-test-pipeline access can now reach them from a test path.

Rotate the ones that live on affected instances. All of them, if that answer is faster than the audit.

The upgrade itself is the second incident

Here is the part the release note says out loud, and the part worth rereading before scheduling the window: "This patch will cause downtime during the upgrade as migrations must complete before GitLab can start." That applies to single-node installs. Multi-node instances "with proper zero-downtime upgrade procedures" can apply the patch without downtime, per the same note. Which is to say: if you have not rehearsed the zero-downtime playbook, you are going to take the outage.

A Critical unauthenticated file read is not a defer-until-next-Tuesday event. A migration-heavy patch is not a "run it in prod first" event. Those two facts collide, and the collision is where CI teams lose weekends.

Verdict

GitLab did the right thing here on the release-note side: a coordinated cut across three supported minor lines, per-CVE descriptions instead of a vague "security fixes" blurb, explicit deployment guidance for both the SaaS side and self-managed operators. That is the version of security shipping we want.

It is also, as ever, only half of the transaction. The other half is you, on a Wednesday night, dragging a self-managed 19.2.x instance forward while your on-call engineer keeps refreshing the pipelines page.

Signed advisories are cheap. Applying them is not.

Rotate the CI/CD variables. Then upgrade.

Kubernetes v1.37 stops your in-place Pod resize from stalling on a full node

Leo — Fri, 11 Sep 2026 08:25:49 +0000

The first time in-place Pod resize saved me a restart on a real service, I sat and stared at the terminal for a beat too long. Our stateful container was quietly walking its CPU request up by a full core, no eviction, no rollout, no 3am page. A week later a different Pod on a heavily bin-packed node tried the same trick and the resize just parked itself. Deferred. Waiting. That second experience is the whole reason I care about what landed in Kubernetes v1.37.

The gap in-place resize left behind

In-place Pod resize graduated to GA back in v1.35. It lets you edit the resource requests on a live container and have the kubelet apply the change without a restart, which is a genuinely different feeling on-call than every previous vertical-scaling story Kubernetes has shipped. The catch: if the node does not have enough allocatable headroom, the kubelet writes a Deferred value into the container's resizeStatus and the request sits there until capacity naturally frees up.

Deferred is not the same as Infeasible. Infeasible means the request outright exceeds the physical machine, a LimitRange, or a quota, and the kubelet rejects it immediately. Deferred means the request is valid, the kubelet just does not have the room right now. Before v1.37, "right now" could stretch to "indefinitely", because the kube-scheduler was not watching running Pods for pending resizes and would not preempt anything to make space for one.

Kubernetes v1.37 introduces, in alpha, scheduler preemption for in-place Pod resize, guarded by a new feature gate named InPlacePodVerticalScalingSchedulerPreemption. Turn it on and the kube-scheduler will actively evict lower-priority Pods on the same node so a higher-priority Pod's Deferred resize can finally succeed.

How the scheduler picks up a running Pod

Normally, once a Pod has spec.nodeName set, the scheduler considers it placed and stops looking at it. Under the new gate, the scheduler keeps watching Pods carrying the Deferred condition and pulls them back into active scheduling evaluations, specifically so they can trigger preemption. It holds onto them until the kubelet reports the resize actuated.

A few design choices are worth knowing before you flip the gate on:

Preemption is single-node. Placement preemption evaluates every node in the cluster to find the best fit; resize preemption is scoped strictly to the Pod's current node. If evicting every eligible lower-priority workload on that node still does not free enough capacity, the resize stays Deferred.
The scheduler owns all resize preemption. The kubelet has an existing critical-Pod admission handler that can evict locally at admission time, but under this gate that handler stays out of resize decisions. Every eviction runs through the scheduler, so global priority ordering, PodDisruptionBudgets, and graceful termination are respected the same way you already trust them for placement preemption.
Reserved capacity, not a race. The scheduler treats the requested delta as consumed the moment preemption starts, so a second scheduling loop cannot double-book the same CPU. If a higher-priority resize on the same node lands mid-preemption, the kubelet gives it precedence and the scheduler kicks off a new round.

Turning it off where you do not want it

If you already run a controller that would rather size other Pods down or grow the node itself before anyone gets evicted, this behaviour is going to feel intrusive. v1.37 adds a spec.podPreemptionPolicy field on the Node, with a disableResizePreemption list of controller names that opts that node out:

apiVersion: v1
kind: Node
metadata:
  name: <node-name>
spec:
  podPreemptionPolicy:
    disableResizePreemption:
      - "cluster-autoscaler.kubernetes.io/disable-preemption"
      - "operator.example.com/policy-override"

Batch-only nodes, or nodes a custom autoscaler wants to own, can flag themselves and keep the scheduler off the eviction path there. Preemption becomes the last-resort tool the doc calls it, not the default.

Trying it locally

The feature gate must be enabled on the kube-apiserver, the kube-scheduler, and the kubelet, and every node has to be on v1.37 or later. The upstream announcement walks through a single-node kind setup that is the fastest way to internalise what the new controller loop actually does: constrain the node's CPU, deploy a low-priority Pod and a high-priority Pod that together nearly fill it, then patch the high-priority Pod's CPU request past the remaining headroom and watch preemption clear the room. Run that once before you argue for it on a real cluster.

The rough edges

It is alpha, so the API shape is not promised across releases. The single-node scope carries a real limit: a resize that needs more room than the entire node can offer, even after evicting every eligible lower-priority Pod, will still park in Deferred. Cases like a memory-hungry VPA target on a small node are still a job for the cluster autoscaler, not for this. And every platform team I have talked to about this has the same fair worry: preemption acting on running Pods, even lower-priority ones, is a behaviour change your batch-job owners deserve a heads-up about before you enable the gate under them.

What I am watching next

Two things. First, whether this graduates at the same cadence core in-place resize did, alpha to GA over a few releases. Second, whether Vertical Pod Autoscaler starts to treat a Deferred status as a first-class recoverable state now that there is finally a story for unsticking one. If both happen, the "no restart, no re-schedule" promise of in-place resize gets a lot closer to the default experience for a lot more workloads, and the next time one of your services quietly walks its CPU up on a full node, you will not have to notice.