import { type Result } from "@fjall/generator";
import { type ManifestDockerService } from "@fjall/util/manifest";
import type { DeployParams, DeployResult } from "../../types/params.js";
import type { ApplicationOperation } from "../../types/operations.js";
import type { DeployServices } from "../serviceFactory.js";
import { type DockerBuildProducts } from "./dockerBuildHelper.js";
/**
 * Resolve the ECR image tag the rollout should pin against for a given
 * manifest service. Keys the content-hash tag map by the bare `<service>`
 * name — the SAME key `dockerBuildHelper.buildGroup` writes and the
 * `<ServiceName>ImageTag` CfnParameter consumes. The build target is folded
 * into the tag VALUE (`<service>(-<target>)?-sha-<id>`), never the key; a
 * `<service>-<target>` key would miss the freshly-pushed tag for every
 * multi-stage service (e.g. the webapp `deploy-worker`/`scan-worker`).
 * Returns `undefined` when the caller did not push a build for this service
 * (the rollback path); the caller then uses an explicit `--image-tag` if
 * supplied, else fails — no moving `-latest` tag exists to guess against.
 */
export declare function lookupContentHashTag(manifestService: ManifestDockerService, contentHashTagsByService: Record<string, string>): string | undefined;
/**
 * Re-base an operator-supplied `--image-tag` onto a specific ECS service.
 *
 * A multi-image stack pushes each service's image under its own
 * `<service>-…` tag family into ONE shared ECR repository (the webapp:
 * `app-sha-<id>`, `scan-worker-sha-<id>`, `deploy-worker-sha-<id>`). The
 * supplied rollback tag names exactly one of those families, but the same
 * build identity (`-sha-<id>` / `-latest` suffix) exists for every service.
 * Applying the supplied tag VERBATIM to every service rolls the wrong image
 * onto the others — e.g. the worker services boot the app image, run
 * `react-router serve`, and crash on app-only secrets. Because all services
 * share one repo, the wrong tag genuinely resolves to a real digest, so the
 * downstream digest-verify cannot catch it; the prefix must be corrected here.
 *
 * This strips the matched `<service>-` prefix and re-prepends the current
 * service's name, preserving the build-identity suffix. Longest-prefix match
 * guards against substring service names (`worker` vs `scan-worker`). When the
 * supplied tag carries no recognised service prefix (a bare custom tag like
 * `latest` or `v1.2.3`), it cannot be re-based and is returned verbatim — the
 * caller surfaces a warning on multi-service stacks.
 */
export declare function rebaseRollbackTagForService(suppliedTag: string, serviceName: string, allServiceNames: readonly string[]): string;
/**
 * Code-only deployment orchestrator.
 *
 * Replaces a buggy `forceNewDeployment: true` rollout (which left the task
 * definition pinned at the previous image tag) with an explicit
 * RegisterTaskDefinition + UpdateService(taskDefinition: newArn) sequence.
 *
 * `contentHashTagsByService` MUST come from the same build phase that just
 * pushed the artifacts (`runDockerBuild` returns this map). Keys are
 * `<service>` or `<service>-<target>`; values are the bare content-hash tag
 * stem (`<service>(-<target>)?-sha-<12hex>`). `options.imageTag` (the
 * explicit `--image-tag <tag>` rollback) bypasses this map; it is re-based
 * per service via `rebaseRollbackTagForService` so each service rolls its OWN
 * `<service>-…` image family (a multi-image stack shares one ECR repo, so an
 * un-rebased tag would silently roll the wrong service's image).
 *
 * `options.serviceImageTags` (F12) is a THIRD, mutually-exclusive tag source:
 * an exact per-service map (bare service name → tag) recorded by a prior
 * Release. Unlike `imageTag`, map-supplied tags are never re-based — they
 * already name the exact service — and never fall back to tag pinning; see
 * `serviceImageTagsRollback.ts`.
 *
 * `dockerBuildProducts` is the FULL build-phase output (only present on the
 * plain-code-only path, when a build actually ran this cycle — `undefined`
 * for both rollback modes, which roll an existing tag and never rebuild). It
 * carries `imageDigestsByService` so `lambdaCodeOnlyRollout.ts`'s primary
 * path can build a digest-pinned `ImageUri` without an extra ECR call —
 * `contentHashTagsByService` alone (the historical 4th param) isn't enough
 * for that.
 *
 * Every lane rolls from the app's image repository, which this derives as
 * the build that pushes into it does (`ecrRepoUri`): each digest lookup is
 * made there, and a service's new revision changes only the containers whose
 * image is there, the schema gate excepted (`appImageContainers.ts`).
 */
export declare function deployCodeOnly(params: DeployParams, services: DeployServices, operation: ApplicationOperation, contentHashTagsByService: Record<string, string>, dockerBuildProducts?: DockerBuildProducts): Promise<Result<DeployResult>>;
/**
 * Derive an ECR repository ARN from an image URI of shape
 * `<account>.dkr.ecr.<region>.amazonaws.com/<repo>`. Returns "" when the URI
 * does not match the ECR pattern (e.g. third-party registries) so the caller
 * can persist the imageUri without a misleading ARN.
 */
export declare function deriveEcrRepositoryArn(repoUri: string): string;