docs(examples): deploy-params, cloudsql-alembic, and playwright-verify samples

Adds runnable samples demonstrating deploy-parameter injection, each
mirrored under integration/examples/ per the repo's sample conventions:

  - custom-actions-deploy-params: a busybox show-params action that prints
    the deploy parameters forwarded by `skaffold exec --set`.
  - custom-actions-cloudsql-migration: an alembic migration custom action
    that receives a Cloud SQL DATABASE_URL via --set on `skaffold exec`.
  - verify-playwright-smoke: a Playwright smoke test run by `skaffold verify`
    that targets a SERVICE_URL supplied via --set, matching Cloud Deploy
    auto-passing the Cloud Run service URL into verify containers.

Author: bogdannazarenko

examples/custom-actions-cloudsql-migration/README.md

@@ -0,0 +1,39 @@
+# Custom actions: Cloud SQL alembic migration
+
+This example shows how `skaffold exec` forwards a deploy parameter — a Cloud SQL
+connection URL — as an environment variable (`DATABASE_URL`) into a database
+migration container. This mirrors
+[Google Cloud Deploy: pass parameters to your deployments](https://docs.cloud.google.com/deploy/docs/parameters),
+where deploy parameters are surfaced into the execution environment so that
+predeploy/postdeploy hooks (such as schema migrations) can consume them without
+baking secrets into `skaffold.yaml`.
+
+## Try it
+
+```console
+$ skaffold exec db-migrate \
+    --set DATABASE_URL='postgresql+pg8000://USER:PASS@/APP?unix_sock=/cloudsql/PROJECT:REGION:INSTANCE/.s.PGSQL.5432'
+```
+
+The `alembic` container will echo:
+
+```
+alembic upgrade head -> postgresql+pg8000://USER:PASS@/APP?unix_sock=/cloudsql/PROJECT:REGION:INSTANCE/.s.PGSQL.5432
+```
+
+In a real project the container image bundles your application and Alembic, and
+the command is `["alembic", "upgrade", "head"]`. Alembic reads `DATABASE_URL`
+to connect to Cloud SQL (typically through the
+[Cloud SQL Auth Proxy](https://cloud.google.com/sql/docs/postgres/sql-proxy) or a
+unix socket under `/cloudsql`).
+
+## Precedence
+
+When the same key is supplied from multiple sources, later entries win:
+
+1. `--env-file` / base env
+2. `--set-value-file`
+3. `--set` (highest priority)
+
+On key collision, deploy parameters override a container's own `env:` entry
+declared in `skaffold.yaml`.

examples/custom-actions-cloudsql-migration/skaffold.yaml

@@ -0,0 +1,18 @@
+apiVersion: skaffold/v4beta14
+kind: Config
+metadata:
+  name: cloudsql-migration-demo
+customActions:
+  - name: db-migrate
+    containers:
+      - name: alembic
+        # busybox keeps this sample runnable. In a real project, swap it for your
+        # migrations image and run the real command, e.g.:
+        #   image: your-registry/myapp-migrations:latest
+        #   command: ["alembic", "upgrade", "head"]
+        # alembic reads the Cloud SQL connection string from DATABASE_URL, which
+        # is supplied as a deploy parameter via `--set` (never hard-coded here).
+        image: busybox
+        command: ["sh", "-c"]
+        args:
+          - 'echo "alembic upgrade head -> ${DATABASE_URL}"'

examples/custom-actions-deploy-params/README.md

@@ -0,0 +1,32 @@
+# Custom actions: deploy parameters
+
+This example demonstrates how `skaffold exec` forwards deploy parameters
+— values supplied on the command line with `--set` or `--set-value-file`
+— as environment variables into every container of the invoked custom
+action. This mirrors [Google Cloud Deploy: pass parameters to your deployments](https://docs.cloud.google.com/deploy/docs/parameters).
+
+## Try it
+
+```console
+$ skaffold exec show-params \
+    --set TF_VAR_bucket=my-bkt \
+    --set REGION=us-central1
+```
+
+The `printer` container will echo:
+
+```
+TF_VAR_bucket=my-bkt
+REGION=us-central1
+```
+
+## Precedence
+
+When the same key appears in multiple sources, later entries win:
+
+1. `--verify-env-file` / base env
+2. `--set-value-file`
+3. `--set` (highest priority)
+
+On key collision, deploy parameters override a container's own `env:`
+entry declared in `skaffold.yaml`.

examples/custom-actions-deploy-params/skaffold.yaml

@@ -0,0 +1,12 @@
+apiVersion: skaffold/v4beta14
+kind: Config
+metadata:
+  name: deploy-params-demo
+customActions:
+  - name: show-params
+    containers:
+      - name: printer
+        image: busybox
+        command: ["sh", "-c"]
+        args:
+          - 'echo "TF_VAR_bucket=${TF_VAR_bucket}"; echo "REGION=${REGION}"'

examples/verify-playwright-smoke/Dockerfile

@@ -0,0 +1,12 @@
+FROM mcr.microsoft.com/playwright:v1.44.0-jammy
+
+WORKDIR /smoke
+
+COPY package.json playwright.config.ts ./
+RUN npm install
+
+COPY tests ./tests
+
+# SERVICE_URL is injected at run time by `skaffold verify --set SERVICE_URL=...`
+# and consumed as the Playwright baseURL.
+CMD ["npx", "playwright", "test"]

examples/verify-playwright-smoke/README.md

@@ -0,0 +1,41 @@
+# Verify: Playwright smoke test with a service URL
+
+This example shows how `skaffold verify` forwards a deploy parameter — the URL of
+a freshly deployed service — as an environment variable (`SERVICE_URL`) into a
+verify container that runs a [Playwright](https://playwright.dev) smoke test.
+
+This mirrors
+[Google Cloud Deploy](https://docs.cloud.google.com/deploy/docs/parameters),
+which automatically passes the Cloud Run service URL into verify containers so
+post-deploy smoke tests can target the revision that was just rolled out.
+
+## Layout
+
+- `Dockerfile` — builds the `smoke-tests` image from the official Playwright base,
+  bundling the test sources.
+- `playwright.config.ts` — uses `process.env.SERVICE_URL` as the Playwright
+  `baseURL`.
+- `tests/smoke.spec.ts` — a minimal smoke test that requests `/` and asserts a
+  successful response.
+
+## Try it
+
+`skaffold verify` runs the verify container from the built image; build first and
+pipe the resulting tags into `verify`:
+
+```console
+$ skaffold build -q | skaffold verify \
+    --set SERVICE_URL=https://my-service-abc-uc.a.run.app
+```
+
+The `playwright` container runs `npx playwright test` against
+`SERVICE_URL`. Supplying a different `--set SERVICE_URL=...` retargets the smoke
+test without changing `skaffold.yaml`.
+
+## Precedence
+
+When the same key is supplied from multiple sources, later entries win:
+
+1. `--env-file` / base env
+2. `--set-value-file`
+3. `--set` (highest priority)

examples/verify-playwright-smoke/package.json

@@ -0,0 +1,11 @@
+{
+  "name": "verify-playwright-smoke",
+  "version": "1.0.0",
+  "private": true,
+  "scripts": {
+    "test": "playwright test"
+  },
+  "devDependencies": {
+    "@playwright/test": "^1.44.0"
+  }
+}

examples/verify-playwright-smoke/playwright.config.ts

@@ -0,0 +1,12 @@
+import { defineConfig } from '@playwright/test';
+
+// baseURL comes from the SERVICE_URL deploy parameter, injected as an environment
+// variable by `skaffold verify --set SERVICE_URL=...`. This mirrors Google Cloud
+// Deploy, which automatically passes the Cloud Run service URL into verify
+// containers so post-deploy smoke tests can target the freshly deployed revision.
+export default defineConfig({
+  testDir: './tests',
+  use: {
+    baseURL: process.env.SERVICE_URL,
+  },
+});

examples/verify-playwright-smoke/skaffold.yaml

@@ -0,0 +1,18 @@
+apiVersion: skaffold/v4beta14
+kind: Config
+metadata:
+  name: playwright-smoke-demo
+build:
+  artifacts:
+    - image: smoke-tests
+      docker:
+        dockerfile: Dockerfile
+verify:
+  - name: smoke-test
+    container:
+      name: playwright
+      image: smoke-tests
+      # SERVICE_URL is supplied as a deploy parameter via `--set` and injected
+      # as an environment variable into this container. Playwright reads it as
+      # the baseURL (see playwright.config.ts). This mirrors Google Cloud Deploy,
+      # which automatically passes the Cloud Run service URL into verify tasks.

examples/verify-playwright-smoke/tests/smoke.spec.ts

@@ -0,0 +1,10 @@
+import { test, expect } from '@playwright/test';
+
+// A minimal smoke test: hit the root of the deployed service (baseURL ==
+// SERVICE_URL) and assert it responds successfully. Extend with real
+// user-facing assertions for your application.
+test('service responds on /', async ({ page }) => {
+  const response = await page.goto('/');
+  expect(response, 'no response from SERVICE_URL').not.toBeNull();
+  expect(response!.ok()).toBeTruthy();
+});