import type { CdkTestAppOptions } from './cdk-test-app'; import type { DestructiveChange, AssertionResults } from '../workers/common'; export interface CommonOptions { /** * The level of verbosity for logging. * * @default 0 */ readonly verbosity?: number; } export interface WatchOptions extends CommonOptions { /** * ARN of the IAM role for CloudFormation to assume during deploy/destroy * * @default - use the bootstrap cfn-exec role */ readonly roleArn?: string; } /** * Options for the integration test runner */ export interface RunOptions extends CommonOptions { /** * Whether or not to run `cdk destroy` and cleanup the * integration test stacks. * * Set this to false if you need to perform any validation * or troubleshooting after deployment. * * @default true */ readonly clean?: boolean; /** * If set to true, the integration test will not deploy * anything and will simply update the snapshot. * * You should NOT use this method since you are essentially * bypassing the integration test. * * @default false */ readonly dryRun?: boolean; /** * If this is set to false then the stack update workflow will * not be run * * The update workflow exists to check for cases where a change would cause * a failure to an existing stack, but not for a newly created stack. * * @default true */ readonly updateWorkflow?: boolean; /** * List of git tags to deploy in sequence before deploying the current code. * When provided, replaces the normal merge-base update workflow. * * @default - use the normal update workflow */ readonly updateFromTags?: string[]; /** * ARN of the IAM role for CloudFormation to assume during deploy/destroy * * @default - use the bootstrap cfn-exec role */ readonly roleArn?: string; /** * Whether to allow resources that fail to delete during a stack update. * * When false, the test will fail if CloudFormation skips deleting a resource * during a stack update. When true, only a warning is printed. * * @default false */ readonly allowDeleteFailures?: boolean; } type RunnerOptions = Omit & { /** * Just for testing * * Use the comparison output directory for deployments, instead of a separate output * directory. * * Preferably, we synth into a separate directory so that snapshot comparison assembly and * deployment assembly don't trample on each other, but the tests in this repository have * been set up to use the same directory. */ TESTING_useComparisonOutputDirectory?: boolean; }; /** * An integration test runner that orchestrates executing * integration tests */ export declare class IntegTestRunner { private readonly appOptions; private readonly destructiveChanges?; private readonly test; constructor(appOptions: RunnerOptions, destructiveChanges?: DestructiveChange[] | undefined); /** * Orchestrates running integration tests. Currently this includes * * 1. (if update workflow is enabled) Deploying the snapshot test stacks * 2. Deploying the integration test stacks * 2. Saving the snapshot (if successful) * 3. Destroying the integration test stacks (if clean=false) * * The update workflow exists to check for cases where a change would cause * a failure to an existing stack, but not for a newly created stack. */ runIntegTestCase(runOptions: RunOptions): Promise; private createSnapshot; /** * Runs cdk deploy --watch for an integration test * * This is meant to be run on a single test and will not create a snapshot */ watchIntegTest(options: WatchOptions): Promise; /** * Checkout the snapshot directory at a specific git ref (tag, commit, branch). * Fails fast if the snapshot does not exist at the given ref. */ private checkoutSnapshotAtRef; /** * Deploy the snapshot from each git tag in sequence, then let the caller * deploy the current code as the final update. */ private deployFromTags; /** * When running integration tests with the update path workflow * it is important that the snapshot that is deployed is the current snapshot * from the upstream branch. In order to guarantee that, first checkout the latest * (to the user) snapshot from upstream * * It is not straightforward to figure out what branch the current * working branch was created from. This is a best effort attempt to do so. * This assumes that there is an 'origin'. `git remote show origin` returns a list of * all branches and we then search for one that starts with `HEAD branch: ` */ private checkoutSnapshot; /** * Perform a integ test case stack destruction */ private destroyTestAndAssertions; private watch; /** * Perform a integ test case deployment, including * performing the update workflow */ private deployTestAndAssertions; /** * Process the outputsFile which contains the assertions results as stack * outputs */ private processAssertionResults; /** * Parses an error message returned from a CDK command */ private parseError; } export {}; //# sourceMappingURL=integ-test-runner.d.ts.map