projen-pipelines 0.3.13 → 0.3.15

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/.jsii CHANGED
@@ -16,7 +16,7 @@
16
16
  },
17
17
  "dependencies": {
18
18
  "constructs": "^10.5.1",
19
- "projen": ">=0.99.21 <1.0.0"
19
+ "projen": ">=0.99.47 <1.0.0"
20
20
  },
21
21
  "dependencyClosure": {
22
22
  "constructs": {
@@ -108,7 +108,7 @@
108
108
  },
109
109
  "name": "projen-pipelines",
110
110
  "readme": {
111
- "markdown": "# Projen Pipelines\n\n[![npm version](https://badge.fury.io/js/projen-pipelines.svg)](https://www.npmjs.com/package/projen-pipelines)\n\nProjen Pipelines is an open-source project that automates the generation of CI/CD pipelines using Projen,\na project configuration tool created by the inventor of AWS CDK.\nIt provides high-level abstractions for defining continuous delivery (CD) pipelines for applications,\nspecifically designed to work with the projen project configuration engine.\n\n### Key Features\n\n* Automates code generation for CI/CD pipelines\n* Supports multiple CI/CD platforms (currently GitHub Actions and GitLab CI, with more in development)\n* Provides baked-in proven defaults for pipeline configurations\n* Enables compliance-as-code integration\n* Allows easy switching between different CI/CD platforms without rewriting pipeline configurations\n* Handles complex deployment scenarios with less code\n* Manages AWS infrastructure more efficiently and straightforwardly\n* Automated drift detection for CloudFormation/CDK stacks with scheduled checks and issue creation\n* Automatic versioning with flexible strategies and multiple output targets\n\n### Benefits\n\n* Reduces repetitive work in writing and maintaining pipeline configurations\n* Ensures consistency across projects by using proven defaults\n* Simplifies compliance management by integrating it directly into pipeline definitions\n* Facilitates platform migrations (e.g., from GitHub to GitLab) by abstracting pipeline definitions\n* Provides automatic version tracking and exposure through CloudFormation and SSM Parameter Store\n\n## Beyond AWS CDK: A Vision for Universal CI/CD Pipeline Generation\n\nWhile Projen Pipelines currently focuses on AWS CDK applications, our vision extends far beyond this initial scope.\nWe aim to evolve into a universal CI/CD pipeline generator capable of supporting a wide variety of application types and deployment targets.\n\n### Future Direction:\n\n1. Diverse Application Support: We plan to expand our capabilities to generate pipelines for various application types, including but not limited to:\n * Traditional web applications\n * Terraform / OpenTOFU projects\n * Winglang applications\n * Static websites and single-page applications\n1. Multi-Cloud Deployment: While we started with AWS, we aim to support deployments to other major cloud providers like Azure, Google Cloud Platform, and others.\n1. On-Premises and Hybrid Scenarios: We recognize the importance of on-premises and hybrid cloud setups and plan to cater to these deployment models.\n1. Framework Agnostic: Our goal is to make Projen Pipelines adaptable to work with various development frameworks and tools, not just those related to AWS or cloud deployments.\n1. Extensibility: We're designing the system to be easily extensible, allowing the community to contribute modules for new application types, deployment targets, or CI/CD platforms.\n\nBy broadening our scope, we aim to create a tool that can standardize and simplify CI/CD pipeline creation across the entire spectrum of modern application development and deployment scenarios.\nWe invite the community to join us in this journey, contributing ideas, use cases, and code to help realize this vision.\n\n## How Projen Pipelines work\n![High level Projen Pipelines Overview](documentation/overview.png)\n\nUnder the hood, after you define the pipeline and select the target engine you want to work on, we use code generation methods to create the required CI/CD pipeline in your project.\n\nWe are considering allowing the selection of multiple engines going forward - please let us know if this is a feature you would use!\n\n## Getting Started\n\n### Installation\n\nTo install the package, add the package `projen-pipelines` to your projects devDeps in your projen configuration file.\n\nAfter installing the package, you can import and use the constructs to define your CDK Pipelines.\n\nYou will also have to setup an IAM role that can be used by GitHub Actions. For example, create a role named `GithubDeploymentRole` in your deployment account (`123456789012`) with a policy like this to assume the CDK roles of the pipeline stages (AWS account IDs `123456789013` and `123456789014`):\n```json\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"Statement1\",\n \"Effect\": \"Allow\",\n \"Action\": \"sts:AssumeRole\",\n \"Resource\": [\n \"arn:aws:iam::123456789013:role/cdk-*-123456789013-*\",\n \"arn:aws:iam::123456789014:role/cdk-*-123456789014-*\"\n ]\n }\n ]\n}\n```\n\nAdd a trust policy to this role as described in this tutorial: [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)\n\n### Usage with AWS CDK\n\nYou can start using the constructs provided by Projen Pipelines in your AWS CDK applications. Here's a brief example:\n\n```typescript\nimport { awscdk } from 'projen';\nimport { GithubCDKPipeline } from 'projen-pipelines';\n\n// Define your AWS CDK TypeScript App\nconst app = new awscdk.AwsCdkTypeScriptApp({\n cdkVersion: '2.150.0',\n name: 'my-awesome-app',\n defaultReleaseBranch: 'main',\n devDeps: [\n 'projen-pipelines',\n ],\n});\n\n// Create the pipeline\nnew GithubCDKPipeline(app, {\n stackPrefix: 'MyApp',\n iamRoleArns: {\n default: 'arn:aws:iam::123456789012:role/GithubDeploymentRole',\n },\n pkgNamespace: '@company-assemblies',\n useGithubPackagesForAssembly: true,\n stages: [\n {\n name: 'dev',\n env: { account: '123456789013', region: 'eu-central-1' },\n }, {\n name: 'prod',\n manualApproval: true,\n env: { account: '123456789014', region: 'eu-central-1' },\n }],\n});\n```\n\nAfter running projen (`npx projen`) a new file called `src/app.ts` will be created and contain a specialized CDK App class for your project.\n\nYou can then use this in your `main.ts` to configure your deployment.\n\n```typescript\nimport { PipelineApp } from './app';\nimport { BackendStack } from './stack';\n\nconst app = new PipelineApp({\n provideDevStack: (scope, id, props) => {\n return new BackendStack(scope, id, {\n ...props,\n apiHostname: 'api-dev',\n myConfigSetting: 'value-for-dev',\n });\n },\n provideProdStack: (scope, id, props) => {\n return new BackendStack(scope, id, {\n ...props,\n apiHostname: 'api',\n myConfigSetting: 'value-for-prod',\n });\n },\n providePersonalStack: (scope, id, props) => {\n return new BackendStack(scope, id, {\n ...props,\n apiHostname: `api-${props.stageName}`,\n myConfigSetting: 'value-for-personal-stage',\n });\n },\n});\n\napp.synth();\n```\n\n### Drift Detection\n\nProjen Pipelines includes built-in support for automated drift detection of your CloudFormation/CDK stacks. This feature helps you identify when your deployed infrastructure has diverged from your code definitions.\n\n```typescript\nimport { GitHubDriftDetectionWorkflow } from 'projen-pipelines';\n\nnew GitHubDriftDetectionWorkflow(app, {\n schedule: '0 0 * * *', // Daily at midnight\n createIssues: true, // Automatically create GitHub issues\n stages: [\n {\n name: 'production',\n region: 'us-east-1',\n roleArn: 'arn:aws:iam::123456789012:role/DriftDetectionRole',\n failOnDrift: true,\n },\n ],\n});\n```\n\nSee the [drift detection documentation](docs/drift-detection.md) for detailed configuration options and examples.\n\n### Setting Up Trust Relationships Between Accounts\n\nWhen planning to manage multiple staging environments, you will need to establish trust relationships. This process centralizes deployment control, improving operational efficiency and security by consolidating deployment management through a singular, monitored channel. Here is a simplified diagram for the setup:\n\n![Trust relationship](documentation/trust.svg)\n\n#### Step 1: Bootstrapping Each Account\n\nBootstrapping initializes the AWS CDK environment in each account. It prepares the account to work with AWS CDK apps deployed from other accounts. Use the `cdk bootstrap` command for this purpose. Replace `<deployment_account_id>` with the actual AWS account ID of your deployment account.\n\nYou can use the [CloudShell](https://aws.amazon.com/cloudshell/) to bootstrap each staging account:\n\n```bash\ncdk bootstrap --trust <deployment_account_id> --cloudformation-execution-policies \"arn:aws:iam::aws:policy/AdministratorAccess\"\n```\n\n**Note:**\n\nWhile `AdministratorAccess` grants full access to all AWS services and resources, it's not recommended for production environments due to security risks. Instead, create custom IAM policies that grant only the necessary permissions required for deployment operations.\n\n### Deployment\n\nThe `<Engine>CDKPipeline` class creates and adds several tasks to the projen project that then can be used in your pipeline to deploy your application to AWS.\n\nHere's a brief description of each one:\n\n1. **deploy:personal** - This task deploys the application's personal stage, which is a distinct, isolated deployment of the application. The personal stage is intended for personal use, such as testing and development.\n\n2. **watch:personal** - This task deploys the personal stage of the application in watch mode. In this mode, the AWS CDK monitors your application source files for changes, automatically re-synthesizing and deploying when it detects any changes.\n\n3. **diff:personal** - This task compares the deployed personal stage with the current state of the application code. It's used to understand what changes would be made if the application were deployed.\n\n4. **destroy:personal** - This task destroys the resources created for the personal stage of the application.\n\n5. **deploy:feature** - This task deploys the application's feature stage. The feature stage is used for new features testing before these are merged into the main branch.\n\n6. **diff:feature** - This task is similar to `diff:personal`, but for the feature stage.\n\n7. **destroy:feature** - This task destroys the resources created for the feature stage of the application.\n\n8. **deploy:<stageName>** - This task deploys a specific stage of the application (like 'dev' or 'prod').\n\n9. **diff:<stageName>** - This task compares the specified application stage with the current state of the application code.\n\n10. **publish:assets** - This task publishes the CDK assets to all accounts. This is useful when the CDK application uses assets like Docker images or files from the S3 bucket.\n\n11. **bump** - This task bumps the version based on the latest git tag and pushes the updated tag to the git repository.\n\n12. **release:push-assembly** - This task creates a manifest, bumps the version without creating a git tag, and publishes the cloud assembly to your registry.\n\nRemember that these tasks are created and managed automatically by the `CDKPipeline` class. You can run these tasks using the `npx projen TASK_NAME` command.\n\n## Versioning\n\nProjen Pipelines includes a comprehensive versioning system that automatically tracks and exposes deployment versions through various AWS services. This feature enables deployment traceability, automated rollback decisions, and comprehensive audit trails.\n\n### Basic Versioning Configuration\n\nTo enable versioning in your pipeline, add the `versioning` configuration:\n\n```typescript\nimport { awscdk } from 'projen';\nimport { GithubCDKPipeline, VersioningStrategy, VersioningOutputs } from 'projen-pipelines';\n\nconst app = new awscdk.AwsCdkTypeScriptApp({\n // ... other config\n});\n\nnew GithubCDKPipeline(app, {\n // ... other pipeline config\n\n versioning: {\n enabled: true,\n strategy: VersioningStrategy.commitCount(),\n outputs: VersioningOutputs.standard()\n }\n});\n```\n\n### Versioning Strategies\n\nProjen Pipelines provides several built-in versioning strategies:\n\n#### Git Tag Strategy\nUses git tags as the version source, with optional prefix stripping:\n\n```typescript\n// Basic git tag strategy\nconst strategy = VersioningStrategy.gitTag();\n\n// With custom configuration\nconst strategy = VersioningStrategy.gitTag({\n stripPrefix: 'v', // Strip 'v' from tags (v1.2.3 → 1.2.3)\n annotatedOnly: true, // Only use annotated tags\n includeSinceTag: true // Include commits since tag\n});\n```\n\n#### Package.json Strategy\nUses the version from your package.json file:\n\n```typescript\n// Basic package.json strategy\nconst strategy = VersioningStrategy.packageJson();\n\n// With custom configuration\nconst strategy = VersioningStrategy.packageJson({\n path: './package.json',\n includePrerelease: true,\n appendCommitInfo: true\n});\n```\n\n#### Commit Count Strategy\nUses the number of commits as the version:\n\n```typescript\n// Basic commit count strategy\nconst strategy = VersioningStrategy.commitCount();\n\n// With custom configuration\nconst strategy = VersioningStrategy.commitCount({\n countFrom: 'all', // 'all' | 'since-tag'\n includeBranch: true, // Include branch name\n padding: 5 // Zero-pad count (00001)\n});\n```\n\n#### Build Number Strategy\nCreates a version from build metadata:\n\n```typescript\n// Basic build number strategy\nconst strategy = VersioningStrategy.buildNumber();\n\n// With custom configuration\nconst strategy = VersioningStrategy.buildNumber({\n prefix: 'release',\n commitCount: { countFrom: 'all', padding: 5 }\n});\n// Output: release-01234-3a4b5c6d\n```\n\n#### Custom Composite Strategy\nCreate your own version format using template variables:\n\n```typescript\nconst strategy = VersioningStrategy.create(\n '{git-tag}+{commit-count}-{commit-hash:8}',\n {\n gitTag: { stripPrefix: 'v' },\n commitCount: { countFrom: 'since-tag' }\n }\n);\n// Output: 1.2.3+45-3a4b5c6d\n```\n\n### Version Output Configurations\n\nControl how and where version information is exposed:\n\n#### CloudFormation Outputs\nExport version information as CloudFormation stack outputs:\n\n```typescript\n// Basic CloudFormation output\nconst outputs = VersioningOutputs.cloudFormationOnly();\n\n// With custom configuration\nconst outputs = VersioningOutputs.cloudFormationOnly({\n exportName: 'MyApp-{stage}-Version'\n});\n```\n\n#### SSM Parameter Store\nStore version information in AWS Systems Manager Parameter Store:\n\n```typescript\n// Basic parameter store\nconst outputs = VersioningOutputs.parameterStoreOnly('/myapp/{stage}/version');\n\n// Hierarchical parameters\nconst outputs = VersioningOutputs.hierarchicalParameters('/myapp/{stage}/version', {\n includeCloudFormation: true\n});\n```\n\nThis creates parameters like:\n- `/myapp/prod/version` → Full version JSON\n- `/myapp/prod/version/commit` → Commit hash\n- `/myapp/prod/version/tag` → Git tag\n- `/myapp/prod/version/count` → Commit count\n\n#### Standard Configuration\nThe recommended configuration that uses CloudFormation outputs with optional Parameter Store:\n\n```typescript\nconst outputs = VersioningOutputs.standard({\n parameterName: '/myapp/{stage}/version',\n});\n```\n\n### Output Formats\n\nVersion information can be output in two formats:\n\n**Plain Format:** Simple string values in CloudFormation\n```yaml\nOutputs:\n AppVersion:\n Value: \"1.2.3+45-3a4b5c6d\"\n Description: \"Application version\"\n AppCommitHash:\n Value: \"3a4b5c6def1234567890\"\n Description: \"Git commit hash\"\n```\n\n**Structured Format:** JSON object with comprehensive metadata in SSM\n```json\n{\n \"version\": \"1.2.3\",\n \"commitHash\": \"3a4b5c6def1234567890\",\n \"commitCount\": 1234,\n \"commitsSinceTag\": 45,\n \"branch\": \"main\",\n \"tag\": \"v1.2.3\",\n \"deployedAt\": \"2024-01-15T10:30:00Z\",\n \"deployedBy\": \"github-actions\",\n \"buildNumber\": \"456\",\n \"environment\": \"production\"\n}\n```\n\n### Stage-Specific Overrides\n\nConfigure different versioning strategies for different stages:\n\n```typescript\nnew GithubCDKPipeline(app, {\n versioning: {\n enabled: true,\n strategy: VersioningStrategy.gitTag(),\n outputs: VersioningOutputs.standard(),\n stageOverrides: {\n dev: {\n strategy: VersioningStrategy.commitCount(),\n outputs: VersioningOutputs.minimal()\n },\n prod: {\n validation: {\n requireTag: true,\n tagPattern: /^v\\d+\\.\\d+\\.\\d+$/\n }\n }\n }\n }\n});\n```\n\n### Template Variables\n\nAll strategies support these template variables:\n- `{git-tag}` - Git tag (with optional prefix stripping)\n- `{package-version}` - Version from package.json\n- `{commit-count}` - Number of commits\n- `{commit-hash}` - Full commit hash\n- `{commit-hash:8}` - Short commit hash (8 characters)\n- `{branch}` - Git branch name\n- `{build-number}` - CI/CD build number\n\n### Benefits of Versioning\n\n1. **Deployment Traceability**: Always know exactly which code version is deployed\n2. **Automated Rollback**: Use version information for automated rollback decisions\n3. **Audit Trail**: Comprehensive deployment history with metadata\n4. **Multi-Stage Support**: Different versioning strategies per environment\n5. **Zero Configuration**: Works out-of-the-box with sensible defaults\n6. **CI/CD Integration**: Automatically detects version info from CI/CD environments\n\n### Feature Branch Deployments\n\nProjen Pipelines supports automated feature branch deployments for GitHub Actions. This allows you to deploy and test your changes in isolated environments before merging to the main branch. Gitlab support is currently missing.\n\n#### Configuration\n\nTo enable feature branch deployments, add the `featureStages` configuration to your pipeline:\n\n```typescript\nnew GithubCDKPipeline(app, {\n stackPrefix: 'MyApp',\n iamRoleArns: {\n default: 'arn:aws:iam::123456789012:role/GithubDeploymentRole',\n },\n featureStages: {\n env: { account: '123456789013', region: 'eu-central-1' },\n },\n stages: [\n // ... your regular stages\n ],\n});\n```\n\n#### How It Works\n\nWhen feature stages are configured, two GitHub workflows are created:\n\n1. **deploy-feature** - Automatically deploys your feature branch when a pull request is labeled with `feature-deployment`\n2. **destroy-feature** - Automatically destroys the feature deployment when:\n - The pull request is closed\n - The `feature-deployment` label is removed from the pull request\n\n#### Using Feature Deployments\n\n1. Create a pull request with your changes\n2. Add the `feature-deployment` label to trigger deployment\n3. The feature environment will be deployed with a stack name including your branch name\n4. Remove the label or close the PR to destroy the feature environment\n\nThe feature deployment uses the `--force` flag when destroying to ensure cleanup without manual confirmation.\n\n### AWS Amplify Deployment\n\nProjen Pipelines includes support for deploying static websites and single-page applications to AWS Amplify Hosting. This feature provides automated deployment of build artifacts to Amplify, with built-in support for multiple environments and branch-based deployments.\n\n#### Configuration\n\nTo add Amplify deployment to your pipeline, use the `AmplifyDeployStep`:\n\n```typescript\nimport { AmplifyDeployStep } from 'projen-pipelines';\n\n// Using a static Amplify app ID\nconst deployStep = new AmplifyDeployStep(project, {\n appId: 'd123gtgt770s1x',\n artifactFile: 'dist.zip',\n branchName: 'main', // optional, defaults to 'main'\n region: 'us-east-1', // optional, defaults to 'eu-central-1'\n});\n\n// Using dynamic app ID extraction from CDK outputs\nconst deployStep = new AmplifyDeployStep(project, {\n appIdCommand: 'jq -r \\'.MyStack.AmplifyAppId\\' cdk-outputs.json',\n artifactFile: 'build.zip',\n environment: 'production', // optional, for environment-specific deployments\n});\n```\n\n#### How It Works\n\nThe Amplify deployment step:\n1. Checks for any pending Amplify deployments and cancels them if needed\n2. Creates a new deployment with the Amplify service\n3. Uploads your build artifact (zip file) to Amplify\n4. Starts the deployment and monitors its progress\n5. Validates the deployment succeeded\n\n#### Build Artifact Preparation\n\nBefore using the Amplify deployment step, ensure your build process creates a zip file containing your static website assets:\n\n```bash\n# Example: Creating a deployment artifact\nnpm run build\ncd dist && zip -r ../dist.zip . && cd ..\n```\n\n#### Multi-Stage Deployments\n\nFor multi-stage deployments with different Amplify apps per environment:\n\n```typescript\n// In your CDK stack, output the Amplify app ID\nnew CfnOutput(this, 'AmplifyAppId', {\n key: 'AmplifyAppId',\n value: amplifyApp.appId,\n});\n\n// In your pipeline configuration\nconst deployStep = new AmplifyDeployStep(project, {\n appIdCommand: `jq -r '.${stackName}.AmplifyAppId' cdk-outputs-${stage}.json`,\n artifactFile: 'website.zip',\n environment: stage,\n branchName: stage === 'prod' ? 'main' : stage,\n});\n```\n\n## Current Status\n\nProjen-Pipelines is currently in version 0.x, awaiting Projen's 1.0 release. Despite its pre-1.0 status, it's being used in several production environments.\n\n## Contributing\n\n### By raising feature requests or issues\n\nUse the Github integrated \"[Issues](https://github.com/taimos/projen-pipelines/issues/new)\" view to create an item that you would love to have added to our open source project.\n\n***No request is too big or too small*** - get your thoughts created and we'll get back to you if we have questions!\n\n### By committing code\n\nWe welcome all contributions to Projen Pipelines! Here's how you can get started:\n\n1. **Fork the Repository**: Click the 'Fork' button at the top right of this page to duplicate this repository in your GitHub account.\n\n2. **Clone your Fork**: Clone the forked repository to your local machine.\n\n```bash\ngit clone https://github.com/<your_username>/projen-pipelines.git\n```\n\n3. **Create a Branch**: To keep your work organized, create a branch for your contribution.\n\n```bash\ngit checkout -b my-branch\n```\n\n4. **Make your Changes**: Make your changes, additions, or fixes to the codebase. Remember to follow the existing code style.\n\n5. **Test your Changes**: Before committing your changes, make sure to test them to ensure they work as expected and do not introduce bugs.\n\n6. **Commit your Changes**: Commit your changes with a descriptive commit message using conventional commit messages.\n\n```bash\ngit commit -m \"feat: Your descriptive commit message\"\n```\n\n7. **Push to your Fork**: Push your commits to the branch in your forked repository.\n\n```bash\ngit push -u origin my-branch\n```\n\n8. **Submit a Pull Request**: Once your changes are ready to be reviewed, create a pull request from your forked repository's branch into the `main` branch of this repository.\n\nYour pull request will be reviewed and hopefully merged quickly. Thanks for contributing!\n\n### How to test changes?\nThe best way currently is to test things locally or - if you have a working stall of all supported CI/CD tools - manually test the functionalities there in diferent projects.\n\n_For local testing:_\nUsing `yalc push` you can install the project locally to your local yalc package manager. You can also use `npm run local-push` instead of this.\n\nWith `yalc add projen-pipelines` you can then use it in a local project.\n\n\n## Future Plans\n\n* Move the project to the Open Construct Foundation for broader community involvement\n* Continue expanding support for different CI/CD platforms and project types\n\nJoin us in elevating CI/CD pipeline discussions from implementation details to fundamental building blocks, and help create a more efficient, standardized approach to pipeline development!\n\n## Known issues\n\n### Environment variable not recognized during `npx projen`\n\nWhen attempting to run `npx projen`, users may encounter an error related to environment variable substitution within configuration files. Specifically, the `${GITHUB_TOKEN}` placeholder fails to be replaced.\n\n#### Solution\n\nTo resolve this issue, prefix the `npx projen` command with the `GITHUB_TOKEN=` environment variable:\n\n```bash\nGITHUB_TOKEN= npx projen\n```\n"
111
+ "markdown": "# Projen Pipelines\n\n[![npm version](https://badge.fury.io/js/projen-pipelines.svg)](https://www.npmjs.com/package/projen-pipelines)\n\nProjen Pipelines is an open-source project that automates the generation of CI/CD pipelines using Projen,\na project configuration tool created by the inventor of AWS CDK.\nIt provides high-level abstractions for defining continuous delivery (CD) pipelines for applications,\nspecifically designed to work with the projen project configuration engine.\n\n### Key Features\n\n* Automates code generation for CI/CD pipelines\n* Supports multiple CI/CD platforms (currently GitHub Actions and GitLab CI, with more in development)\n* Provides baked-in proven defaults for pipeline configurations\n* Enables compliance-as-code integration\n* Allows easy switching between different CI/CD platforms without rewriting pipeline configurations\n* Handles complex deployment scenarios with less code\n* Manages AWS infrastructure more efficiently and straightforwardly\n* Automated drift detection for CloudFormation/CDK stacks with scheduled checks and issue creation\n* Automatic versioning with flexible strategies and multiple output targets\n\n### Benefits\n\n* Reduces repetitive work in writing and maintaining pipeline configurations\n* Ensures consistency across projects by using proven defaults\n* Simplifies compliance management by integrating it directly into pipeline definitions\n* Facilitates platform migrations (e.g., from GitHub to GitLab) by abstracting pipeline definitions\n* Provides automatic version tracking and exposure through CloudFormation and SSM Parameter Store\n\n## Beyond AWS CDK: A Vision for Universal CI/CD Pipeline Generation\n\nWhile Projen Pipelines currently focuses on AWS CDK applications, our vision extends far beyond this initial scope.\nWe aim to evolve into a universal CI/CD pipeline generator capable of supporting a wide variety of application types and deployment targets.\n\n### Future Direction:\n\n1. Diverse Application Support: We plan to expand our capabilities to generate pipelines for various application types, including but not limited to:\n * Traditional web applications\n * Terraform / OpenTOFU projects\n * Winglang applications\n * Static websites and single-page applications\n1. Multi-Cloud Deployment: While we started with AWS, we aim to support deployments to other major cloud providers like Azure, Google Cloud Platform, and others.\n1. On-Premises and Hybrid Scenarios: We recognize the importance of on-premises and hybrid cloud setups and plan to cater to these deployment models.\n1. Framework Agnostic: Our goal is to make Projen Pipelines adaptable to work with various development frameworks and tools, not just those related to AWS or cloud deployments.\n1. Extensibility: We're designing the system to be easily extensible, allowing the community to contribute modules for new application types, deployment targets, or CI/CD platforms.\n\nBy broadening our scope, we aim to create a tool that can standardize and simplify CI/CD pipeline creation across the entire spectrum of modern application development and deployment scenarios.\nWe invite the community to join us in this journey, contributing ideas, use cases, and code to help realize this vision.\n\n## How Projen Pipelines work\n![High level Projen Pipelines Overview](documentation/overview.png)\n\nUnder the hood, after you define the pipeline and select the target engine you want to work on, we use code generation methods to create the required CI/CD pipeline in your project.\n\nWe are considering allowing the selection of multiple engines going forward - please let us know if this is a feature you would use!\n\n## Getting Started\n\n### Installation\n\nTo install the package, add the package `projen-pipelines` to your projects devDeps in your projen configuration file.\n\nAfter installing the package, you can import and use the constructs to define your CDK Pipelines.\n\nYou will also have to setup an IAM role that can be used by GitHub Actions. For example, create a role named `GithubDeploymentRole` in your deployment account (`123456789012`) with a policy like this to assume the CDK roles of the pipeline stages (AWS account IDs `123456789013` and `123456789014`):\n```json\n{\n \"Version\": \"2012-10-17\",\n \"Statement\": [\n {\n \"Sid\": \"Statement1\",\n \"Effect\": \"Allow\",\n \"Action\": \"sts:AssumeRole\",\n \"Resource\": [\n \"arn:aws:iam::123456789013:role/cdk-*-123456789013-*\",\n \"arn:aws:iam::123456789014:role/cdk-*-123456789014-*\"\n ]\n }\n ]\n}\n```\n\nAdd a trust policy to this role as described in this tutorial: [Configuring OpenID Connect in Amazon Web Services](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)\n\n### Usage with AWS CDK\n\nYou can start using the constructs provided by Projen Pipelines in your AWS CDK applications. Here's a brief example:\n\n```typescript\nimport { awscdk } from 'projen';\nimport { GithubCDKPipeline } from 'projen-pipelines';\n\n// Define your AWS CDK TypeScript App\nconst app = new awscdk.AwsCdkTypeScriptApp({\n cdkVersion: '2.150.0',\n name: 'my-awesome-app',\n defaultReleaseBranch: 'main',\n devDeps: [\n 'projen-pipelines',\n ],\n});\n\n// Create the pipeline\nnew GithubCDKPipeline(app, {\n stackPrefix: 'MyApp',\n iamRoleArns: {\n default: 'arn:aws:iam::123456789012:role/GithubDeploymentRole',\n },\n pkgNamespace: '@company-assemblies',\n useGithubPackagesForAssembly: true,\n stages: [\n {\n name: 'dev',\n env: { account: '123456789013', region: 'eu-central-1' },\n }, {\n name: 'prod',\n manualApproval: true,\n env: { account: '123456789014', region: 'eu-central-1' },\n }],\n});\n```\n\nAfter running projen (`npx projen`) a new file called `src/app.ts` will be created and contain a specialized CDK App class for your project.\n\nYou can then use this in your `main.ts` to configure your deployment.\n\n```typescript\nimport { PipelineApp } from './app';\nimport { BackendStack } from './stack';\n\nconst app = new PipelineApp({\n provideDevStack: (scope, id, props) => {\n return new BackendStack(scope, id, {\n ...props,\n apiHostname: 'api-dev',\n myConfigSetting: 'value-for-dev',\n });\n },\n provideProdStack: (scope, id, props) => {\n return new BackendStack(scope, id, {\n ...props,\n apiHostname: 'api',\n myConfigSetting: 'value-for-prod',\n });\n },\n providePersonalStack: (scope, id, props) => {\n return new BackendStack(scope, id, {\n ...props,\n apiHostname: `api-${props.stageName}`,\n myConfigSetting: 'value-for-personal-stage',\n });\n },\n});\n\napp.synth();\n```\n\n### Drift Detection\n\nProjen Pipelines includes built-in support for automated drift detection of your CloudFormation/CDK stacks. This feature helps you identify when your deployed infrastructure has diverged from your code definitions.\n\n```typescript\nimport { GitHubDriftDetectionWorkflow } from 'projen-pipelines';\n\nnew GitHubDriftDetectionWorkflow(app, {\n schedule: '0 0 * * *', // Daily at midnight\n createIssues: true, // Automatically create GitHub issues\n stages: [\n {\n name: 'production',\n region: 'us-east-1',\n roleArn: 'arn:aws:iam::123456789012:role/DriftDetectionRole',\n failOnDrift: true,\n },\n ],\n});\n```\n\nSee the [drift detection documentation](docs/drift-detection.md) for detailed configuration options and examples.\n\n### Setting Up Trust Relationships Between Accounts\n\nWhen planning to manage multiple staging environments, you will need to establish trust relationships. This process centralizes deployment control, improving operational efficiency and security by consolidating deployment management through a singular, monitored channel. Here is a simplified diagram for the setup:\n\n![Trust relationship](documentation/trust.svg)\n\n#### Step 1: Bootstrapping Each Account\n\nBootstrapping initializes the AWS CDK environment in each account. It prepares the account to work with AWS CDK apps deployed from other accounts. Use the `cdk bootstrap` command for this purpose. Replace `<deployment_account_id>` with the actual AWS account ID of your deployment account.\n\nYou can use the [CloudShell](https://aws.amazon.com/cloudshell/) to bootstrap each staging account:\n\n```bash\ncdk bootstrap --trust <deployment_account_id> --cloudformation-execution-policies \"arn:aws:iam::aws:policy/AdministratorAccess\"\n```\n\n**Note:**\n\nWhile `AdministratorAccess` grants full access to all AWS services and resources, it's not recommended for production environments due to security risks. Instead, create custom IAM policies that grant only the necessary permissions required for deployment operations.\n\n### Deployment\n\nThe `<Engine>CDKPipeline` class creates and adds several tasks to the projen project that then can be used in your pipeline to deploy your application to AWS.\n\nHere's a brief description of each one:\n\n1. **deploy:personal** - This task deploys the application's personal stage, which is a distinct, isolated deployment of the application. The personal stage is intended for personal use, such as testing and development.\n\n2. **watch:personal** - This task deploys the personal stage of the application in watch mode. In this mode, the AWS CDK monitors your application source files for changes, automatically re-synthesizing and deploying when it detects any changes.\n\n3. **diff:personal** - This task compares the deployed personal stage with the current state of the application code. It's used to understand what changes would be made if the application were deployed.\n\n4. **destroy:personal** - This task destroys the resources created for the personal stage of the application.\n\n5. **deploy:feature** - This task deploys the application's feature stage. The feature stage is used for new features testing before these are merged into the main branch.\n\n6. **diff:feature** - This task is similar to `diff:personal`, but for the feature stage.\n\n7. **destroy:feature** - This task destroys the resources created for the feature stage of the application.\n\n8. **deploy:<stageName>** - This task deploys a specific stage of the application (like 'dev' or 'prod').\n\n9. **diff:<stageName>** - This task compares the specified application stage with the current state of the application code.\n\n10. **publish:assets** - This task publishes the CDK assets to all accounts. This is useful when the CDK application uses assets like Docker images or files from the S3 bucket.\n\n11. **bump** - This task bumps the version based on the latest git tag and pushes the updated tag to the git repository.\n\n12. **release:push-assembly** - This task creates a manifest, bumps the version without creating a git tag, and publishes the cloud assembly to your registry.\n\nRemember that these tasks are created and managed automatically by the `CDKPipeline` class. You can run these tasks using the `npx projen TASK_NAME` command.\n\n## Versioning\n\nProjen Pipelines includes a comprehensive versioning system that automatically tracks and exposes deployment versions through various AWS services. This feature enables deployment traceability, automated rollback decisions, and comprehensive audit trails.\n\n### Basic Versioning Configuration\n\nTo enable versioning in your pipeline, add the `versioning` configuration:\n\n```typescript\nimport { awscdk } from 'projen';\nimport { GithubCDKPipeline, VersioningStrategy, VersioningOutputs } from 'projen-pipelines';\n\nconst app = new awscdk.AwsCdkTypeScriptApp({\n // ... other config\n});\n\nnew GithubCDKPipeline(app, {\n // ... other pipeline config\n\n versioning: {\n enabled: true,\n strategy: VersioningStrategy.commitCount(),\n outputs: VersioningOutputs.standard()\n }\n});\n```\n\n### Versioning Strategies\n\nProjen Pipelines provides several built-in versioning strategies:\n\n#### Git Tag Strategy\nUses git tags as the version source, with optional prefix stripping:\n\n```typescript\n// Basic git tag strategy\nconst strategy = VersioningStrategy.gitTag();\n\n// With custom configuration\nconst strategy = VersioningStrategy.gitTag({\n stripPrefix: 'v', // Strip 'v' from tags (v1.2.3 → 1.2.3)\n annotatedOnly: true, // Only use annotated tags\n includeSinceTag: true // Include commits since tag\n});\n```\n\n#### Package.json Strategy\nUses the version from your package.json file:\n\n```typescript\n// Basic package.json strategy\nconst strategy = VersioningStrategy.packageJson();\n\n// With custom configuration\nconst strategy = VersioningStrategy.packageJson({\n path: './package.json',\n includePrerelease: true,\n appendCommitInfo: true\n});\n```\n\n#### Commit Count Strategy\nUses the number of commits as the version:\n\n```typescript\n// Basic commit count strategy\nconst strategy = VersioningStrategy.commitCount();\n\n// With custom configuration\nconst strategy = VersioningStrategy.commitCount({\n countFrom: 'all', // 'all' | 'since-tag'\n includeBranch: true, // Include branch name\n padding: 5 // Zero-pad count (00001)\n});\n```\n\n#### Build Number Strategy\nCreates a version from build metadata:\n\n```typescript\n// Basic build number strategy\nconst strategy = VersioningStrategy.buildNumber();\n\n// With custom configuration\nconst strategy = VersioningStrategy.buildNumber({\n prefix: 'release',\n commitCount: { countFrom: 'all', padding: 5 }\n});\n// Output: release-01234-3a4b5c6d\n```\n\n#### Custom Composite Strategy\nCreate your own version format using template variables:\n\n```typescript\nconst strategy = VersioningStrategy.create(\n '{git-tag}+{commit-count}-{commit-hash:8}',\n {\n gitTag: { stripPrefix: 'v' },\n commitCount: { countFrom: 'since-tag' }\n }\n);\n// Output: 1.2.3+45-3a4b5c6d\n```\n\n### Version Output Configurations\n\nControl how and where version information is exposed:\n\n#### CloudFormation Outputs\nExport version information as CloudFormation stack outputs:\n\n```typescript\n// Basic CloudFormation output\nconst outputs = VersioningOutputs.cloudFormationOnly();\n\n// With custom configuration\nconst outputs = VersioningOutputs.cloudFormationOnly({\n exportName: 'MyApp-{stage}-Version'\n});\n```\n\n#### SSM Parameter Store\nStore version information in AWS Systems Manager Parameter Store:\n\n```typescript\n// Basic parameter store\nconst outputs = VersioningOutputs.parameterStoreOnly('/myapp/{stage}/version');\n\n// Hierarchical parameters\nconst outputs = VersioningOutputs.hierarchicalParameters('/myapp/{stage}/version', {\n includeCloudFormation: true\n});\n```\n\nThis creates parameters like:\n- `/myapp/prod/version` → Full version JSON\n- `/myapp/prod/version/commit` → Commit hash\n- `/myapp/prod/version/tag` → Git tag\n- `/myapp/prod/version/count` → Commit count\n\n#### Standard Configuration\nThe recommended configuration that uses CloudFormation outputs with optional Parameter Store:\n\n```typescript\nconst outputs = VersioningOutputs.standard({\n parameterName: '/myapp/{stage}/version',\n});\n```\n\n### Output Formats\n\nVersion information can be output in two formats:\n\n**Plain Format:** Simple string values in CloudFormation\n```yaml\nOutputs:\n AppVersion:\n Value: \"1.2.3+45-3a4b5c6d\"\n Description: \"Application version\"\n AppCommitHash:\n Value: \"3a4b5c6def1234567890\"\n Description: \"Git commit hash\"\n```\n\n**Structured Format:** JSON object with comprehensive metadata in SSM\n```json\n{\n \"version\": \"1.2.3\",\n \"commitHash\": \"3a4b5c6def1234567890\",\n \"commitCount\": 1234,\n \"commitsSinceTag\": 45,\n \"branch\": \"main\",\n \"tag\": \"v1.2.3\",\n \"deployedAt\": \"2024-01-15T10:30:00Z\",\n \"deployedBy\": \"github-actions\",\n \"buildNumber\": \"456\",\n \"environment\": \"production\"\n}\n```\n\n### Stage-Specific Overrides\n\nConfigure different versioning strategies for different stages:\n\n```typescript\nnew GithubCDKPipeline(app, {\n versioning: {\n enabled: true,\n strategy: VersioningStrategy.gitTag(),\n outputs: VersioningOutputs.standard(),\n stageOverrides: {\n dev: {\n strategy: VersioningStrategy.commitCount(),\n outputs: VersioningOutputs.minimal()\n },\n prod: {\n validation: {\n requireTag: true,\n tagPattern: /^v\\d+\\.\\d+\\.\\d+$/\n }\n }\n }\n }\n});\n```\n\n### Template Variables\n\nAll strategies support these template variables:\n- `{git-tag}` - Git tag (with optional prefix stripping)\n- `{package-version}` - Version from package.json\n- `{commit-count}` - Number of commits\n- `{commit-hash}` - Full commit hash\n- `{commit-hash:8}` - Short commit hash (8 characters)\n- `{branch}` - Git branch name\n- `{build-number}` - CI/CD build number\n\n### Benefits of Versioning\n\n1. **Deployment Traceability**: Always know exactly which code version is deployed\n2. **Automated Rollback**: Use version information for automated rollback decisions\n3. **Audit Trail**: Comprehensive deployment history with metadata\n4. **Multi-Stage Support**: Different versioning strategies per environment\n5. **Zero Configuration**: Works out-of-the-box with sensible defaults\n6. **CI/CD Integration**: Automatically detects version info from CI/CD environments\n\n### Feature Branch Deployments\n\nProjen Pipelines supports automated feature branch deployments for GitHub Actions. This allows you to deploy and test your changes in isolated environments before merging to the main branch. Gitlab support is currently missing.\n\n#### Configuration\n\nTo enable feature branch deployments, add the `featureStages` configuration to your pipeline:\n\n```typescript\nnew GithubCDKPipeline(app, {\n stackPrefix: 'MyApp',\n iamRoleArns: {\n default: 'arn:aws:iam::123456789012:role/GithubDeploymentRole',\n },\n featureStages: {\n env: { account: '123456789013', region: 'eu-central-1' },\n },\n stages: [\n // ... your regular stages\n ],\n});\n```\n\n#### How It Works\n\nWhen feature stages are configured, two GitHub workflows are created:\n\n1. **deploy-feature** - Automatically deploys your feature branch when a pull request is labeled with `feature-deployment`\n2. **destroy-feature** - Automatically destroys the feature deployment when:\n - The pull request is closed\n - The `feature-deployment` label is removed from the pull request\n\n#### Using Feature Deployments\n\n1. Create a pull request with your changes\n2. Add the `feature-deployment` label to trigger deployment\n3. The feature environment will be deployed with a stack name including your branch name\n4. Remove the label or close the PR to destroy the feature environment\n\nThe feature deployment uses the `--force` flag when destroying to ensure cleanup without manual confirmation.\n\n### Monorepo / Path Filtering\n\nIn monorepo setups, you may want to only trigger a pipeline when changes are made to specific paths. Use the `paths` option to configure path-based filtering:\n\n```typescript\nnew GithubCDKPipeline(app, {\n stackPrefix: 'MyApp',\n iamRoleArns: {\n default: 'arn:aws:iam::123456789012:role/GithubDeploymentRole',\n },\n paths: ['packages/my-app/**', 'shared-libs/**'],\n stages: [\n {\n name: 'dev',\n env: { account: '123456789013', region: 'eu-central-1' },\n },\n ],\n});\n```\n\nWhen `paths` is specified:\n- **GitHub Actions**: The deploy workflow will only trigger on pushes that include changes to the matching paths. Feature branch workflows (deploy/destroy) are also filtered. Manual dispatch (`workflow_dispatch`) remains unfiltered and can always be triggered.\n- **GitLab CI**: Deployment and diff jobs use `only.changes` to only run when matching files are modified.\n\nThis allows you to have multiple pipelines in the same repository, each responsible for a different subproject, without triggering unnecessary deployments.\n\n### AWS Amplify Deployment\n\nProjen Pipelines includes support for deploying static websites and single-page applications to AWS Amplify Hosting. This feature provides automated deployment of build artifacts to Amplify, with built-in support for multiple environments and branch-based deployments.\n\n#### Configuration\n\nTo add Amplify deployment to your pipeline, use the `AmplifyDeployStep`:\n\n```typescript\nimport { AmplifyDeployStep } from 'projen-pipelines';\n\n// Using a static Amplify app ID\nconst deployStep = new AmplifyDeployStep(project, {\n appId: 'd123gtgt770s1x',\n artifactFile: 'dist.zip',\n branchName: 'main', // optional, defaults to 'main'\n region: 'us-east-1', // optional, defaults to 'eu-central-1'\n});\n\n// Using dynamic app ID extraction from CDK outputs\nconst deployStep = new AmplifyDeployStep(project, {\n appIdCommand: 'jq -r \\'.MyStack.AmplifyAppId\\' cdk-outputs.json',\n artifactFile: 'build.zip',\n environment: 'production', // optional, for environment-specific deployments\n});\n```\n\n#### How It Works\n\nThe Amplify deployment step:\n1. Checks for any pending Amplify deployments and cancels them if needed\n2. Creates a new deployment with the Amplify service\n3. Uploads your build artifact (zip file) to Amplify\n4. Starts the deployment and monitors its progress\n5. Validates the deployment succeeded\n\n#### Build Artifact Preparation\n\nBefore using the Amplify deployment step, ensure your build process creates a zip file containing your static website assets:\n\n```bash\n# Example: Creating a deployment artifact\nnpm run build\ncd dist && zip -r ../dist.zip . && cd ..\n```\n\n#### Multi-Stage Deployments\n\nFor multi-stage deployments with different Amplify apps per environment:\n\n```typescript\n// In your CDK stack, output the Amplify app ID\nnew CfnOutput(this, 'AmplifyAppId', {\n key: 'AmplifyAppId',\n value: amplifyApp.appId,\n});\n\n// In your pipeline configuration\nconst deployStep = new AmplifyDeployStep(project, {\n appIdCommand: `jq -r '.${stackName}.AmplifyAppId' cdk-outputs-${stage}.json`,\n artifactFile: 'website.zip',\n environment: stage,\n branchName: stage === 'prod' ? 'main' : stage,\n});\n```\n\n## Current Status\n\nProjen-Pipelines is currently in version 0.x, awaiting Projen's 1.0 release. Despite its pre-1.0 status, it's being used in several production environments.\n\n## Contributing\n\n### By raising feature requests or issues\n\nUse the Github integrated \"[Issues](https://github.com/taimos/projen-pipelines/issues/new)\" view to create an item that you would love to have added to our open source project.\n\n***No request is too big or too small*** - get your thoughts created and we'll get back to you if we have questions!\n\n### By committing code\n\nWe welcome all contributions to Projen Pipelines! Here's how you can get started:\n\n1. **Fork the Repository**: Click the 'Fork' button at the top right of this page to duplicate this repository in your GitHub account.\n\n2. **Clone your Fork**: Clone the forked repository to your local machine.\n\n```bash\ngit clone https://github.com/<your_username>/projen-pipelines.git\n```\n\n3. **Create a Branch**: To keep your work organized, create a branch for your contribution.\n\n```bash\ngit checkout -b my-branch\n```\n\n4. **Make your Changes**: Make your changes, additions, or fixes to the codebase. Remember to follow the existing code style.\n\n5. **Test your Changes**: Before committing your changes, make sure to test them to ensure they work as expected and do not introduce bugs.\n\n6. **Commit your Changes**: Commit your changes with a descriptive commit message using conventional commit messages.\n\n```bash\ngit commit -m \"feat: Your descriptive commit message\"\n```\n\n7. **Push to your Fork**: Push your commits to the branch in your forked repository.\n\n```bash\ngit push -u origin my-branch\n```\n\n8. **Submit a Pull Request**: Once your changes are ready to be reviewed, create a pull request from your forked repository's branch into the `main` branch of this repository.\n\nYour pull request will be reviewed and hopefully merged quickly. Thanks for contributing!\n\n### How to test changes?\nThe best way currently is to test things locally or - if you have a working stall of all supported CI/CD tools - manually test the functionalities there in diferent projects.\n\n_For local testing:_\nUsing `yalc push` you can install the project locally to your local yalc package manager. You can also use `npm run local-push` instead of this.\n\nWith `yalc add projen-pipelines` you can then use it in a local project.\n\n\n## Future Plans\n\n* Move the project to the Open Construct Foundation for broader community involvement\n* Continue expanding support for different CI/CD platforms and project types\n\nJoin us in elevating CI/CD pipeline discussions from implementation details to fundamental building blocks, and help create a more efficient, standardized approach to pipeline development!\n\n## Known issues\n\n### Environment variable not recognized during `npx projen`\n\nWhen attempting to run `npx projen`, users may encounter an error related to environment variable substitution within configuration files. Specifically, the `${GITHUB_TOKEN}` placeholder fails to be replaced.\n\n#### Solution\n\nTo resolve this issue, prefix the `npx projen` command with the `GITHUB_TOKEN=` environment variable:\n\n```bash\nGITHUB_TOKEN= npx projen\n```\n"
112
112
  },
113
113
  "repository": {
114
114
  "type": "git",
@@ -942,7 +942,7 @@
942
942
  },
943
943
  "locationInModule": {
944
944
  "filename": "src/awscdk/base.ts",
945
- "line": 217
945
+ "line": 230
946
946
  },
947
947
  "parameters": [
948
948
  {
@@ -962,7 +962,7 @@
962
962
  "kind": "class",
963
963
  "locationInModule": {
964
964
  "filename": "src/awscdk/base.ts",
965
- "line": 210
965
+ "line": 223
966
966
  },
967
967
  "methods": [
968
968
  {
@@ -972,7 +972,7 @@
972
972
  },
973
973
  "locationInModule": {
974
974
  "filename": "src/awscdk/base.ts",
975
- "line": 420
975
+ "line": 438
976
976
  },
977
977
  "name": "createApplicationEntrypoint",
978
978
  "protected": true
@@ -984,7 +984,7 @@
984
984
  },
985
985
  "locationInModule": {
986
986
  "filename": "src/awscdk/base.ts",
987
- "line": 626
987
+ "line": 644
988
988
  },
989
989
  "name": "createFeatureStage",
990
990
  "protected": true
@@ -996,7 +996,7 @@
996
996
  },
997
997
  "locationInModule": {
998
998
  "filename": "src/awscdk/base.ts",
999
- "line": 675
999
+ "line": 693
1000
1000
  },
1001
1001
  "name": "createIndependentStage",
1002
1002
  "parameters": [
@@ -1019,7 +1019,7 @@
1019
1019
  },
1020
1020
  "locationInModule": {
1021
1021
  "filename": "src/awscdk/base.ts",
1022
- "line": 603
1022
+ "line": 621
1023
1023
  },
1024
1024
  "name": "createPersonalStage",
1025
1025
  "protected": true
@@ -1031,7 +1031,7 @@
1031
1031
  },
1032
1032
  "locationInModule": {
1033
1033
  "filename": "src/awscdk/base.ts",
1034
- "line": 649
1034
+ "line": 667
1035
1035
  },
1036
1036
  "name": "createPipelineStage",
1037
1037
  "parameters": [
@@ -1054,7 +1054,7 @@
1054
1054
  },
1055
1055
  "locationInModule": {
1056
1056
  "filename": "src/awscdk/base.ts",
1057
- "line": 548
1057
+ "line": 566
1058
1058
  },
1059
1059
  "name": "createReleaseTasks",
1060
1060
  "protected": true
@@ -1065,7 +1065,7 @@
1065
1065
  },
1066
1066
  "locationInModule": {
1067
1067
  "filename": "src/awscdk/base.ts",
1068
- "line": 406
1068
+ "line": 424
1069
1069
  },
1070
1070
  "name": "createSafeStageName",
1071
1071
  "parameters": [
@@ -1090,7 +1090,7 @@
1090
1090
  },
1091
1091
  "locationInModule": {
1092
1092
  "filename": "src/awscdk/base.ts",
1093
- "line": 708
1093
+ "line": 726
1094
1094
  },
1095
1095
  "name": "createVersionFetchTask",
1096
1096
  "parameters": [
@@ -1110,7 +1110,7 @@
1110
1110
  },
1111
1111
  "locationInModule": {
1112
1112
  "filename": "src/awscdk/base.ts",
1113
- "line": 271
1113
+ "line": 284
1114
1114
  },
1115
1115
  "name": "engineType",
1116
1116
  "returns": {
@@ -1126,7 +1126,7 @@
1126
1126
  },
1127
1127
  "locationInModule": {
1128
1128
  "filename": "src/awscdk/base.ts",
1129
- "line": 754
1129
+ "line": 772
1130
1130
  },
1131
1131
  "name": "generateVersioningAppCode",
1132
1132
  "parameters": [
@@ -1150,7 +1150,7 @@
1150
1150
  },
1151
1151
  "locationInModule": {
1152
1152
  "filename": "src/awscdk/base.ts",
1153
- "line": 768
1153
+ "line": 786
1154
1154
  },
1155
1155
  "name": "generateVersioningImports",
1156
1156
  "returns": {
@@ -1166,7 +1166,7 @@
1166
1166
  },
1167
1167
  "locationInModule": {
1168
1168
  "filename": "src/awscdk/base.ts",
1169
- "line": 781
1169
+ "line": 799
1170
1170
  },
1171
1171
  "name": "generateVersioningUtilities",
1172
1172
  "returns": {
@@ -1181,7 +1181,7 @@
1181
1181
  },
1182
1182
  "locationInModule": {
1183
1183
  "filename": "src/awscdk/base.ts",
1184
- "line": 697
1184
+ "line": 715
1185
1185
  },
1186
1186
  "name": "getCliStackPattern",
1187
1187
  "parameters": [
@@ -1205,7 +1205,7 @@
1205
1205
  },
1206
1206
  "locationInModule": {
1207
1207
  "filename": "src/awscdk/base.ts",
1208
- "line": 348
1208
+ "line": 366
1209
1209
  },
1210
1210
  "name": "provideAssemblyUploadStep",
1211
1211
  "protected": true,
@@ -1221,7 +1221,7 @@
1221
1221
  },
1222
1222
  "locationInModule": {
1223
1223
  "filename": "src/awscdk/base.ts",
1224
- "line": 314
1224
+ "line": 332
1225
1225
  },
1226
1226
  "name": "provideAssetUploadStep",
1227
1227
  "parameters": [
@@ -1246,7 +1246,7 @@
1246
1246
  },
1247
1247
  "locationInModule": {
1248
1248
  "filename": "src/awscdk/base.ts",
1249
- "line": 358
1249
+ "line": 376
1250
1250
  },
1251
1251
  "name": "provideDeployStep",
1252
1252
  "parameters": [
@@ -1270,7 +1270,7 @@
1270
1270
  },
1271
1271
  "locationInModule": {
1272
1272
  "filename": "src/awscdk/base.ts",
1273
- "line": 370
1273
+ "line": 388
1274
1274
  },
1275
1275
  "name": "provideDiffStep",
1276
1276
  "parameters": [
@@ -1301,7 +1301,7 @@
1301
1301
  },
1302
1302
  "locationInModule": {
1303
1303
  "filename": "src/awscdk/base.ts",
1304
- "line": 273
1304
+ "line": 286
1305
1305
  },
1306
1306
  "name": "provideInstallStep",
1307
1307
  "protected": true,
@@ -1317,7 +1317,7 @@
1317
1317
  },
1318
1318
  "locationInModule": {
1319
1319
  "filename": "src/awscdk/base.ts",
1320
- "line": 290
1320
+ "line": 308
1321
1321
  },
1322
1322
  "name": "provideSynthStep",
1323
1323
  "protected": true,
@@ -1333,7 +1333,7 @@
1333
1333
  },
1334
1334
  "locationInModule": {
1335
1335
  "filename": "src/awscdk/base.ts",
1336
- "line": 384
1336
+ "line": 402
1337
1337
  },
1338
1338
  "name": "renderInstallPackageCommands",
1339
1339
  "parameters": [
@@ -1373,7 +1373,7 @@
1373
1373
  "immutable": true,
1374
1374
  "locationInModule": {
1375
1375
  "filename": "src/awscdk/base.ts",
1376
- "line": 212
1376
+ "line": 225
1377
1377
  },
1378
1378
  "name": "branchName",
1379
1379
  "type": {
@@ -1388,7 +1388,7 @@
1388
1388
  "immutable": true,
1389
1389
  "locationInModule": {
1390
1390
  "filename": "src/awscdk/base.ts",
1391
- "line": 215
1391
+ "line": 228
1392
1392
  },
1393
1393
  "name": "namePrefix",
1394
1394
  "protected": true,
@@ -1403,7 +1403,7 @@
1403
1403
  "immutable": true,
1404
1404
  "locationInModule": {
1405
1405
  "filename": "src/awscdk/base.ts",
1406
- "line": 211
1406
+ "line": 224
1407
1407
  },
1408
1408
  "name": "stackPrefix",
1409
1409
  "type": {
@@ -1416,7 +1416,7 @@
1416
1416
  },
1417
1417
  "locationInModule": {
1418
1418
  "filename": "src/awscdk/base.ts",
1419
- "line": 217
1419
+ "line": 230
1420
1420
  },
1421
1421
  "name": "app",
1422
1422
  "protected": true,
@@ -1430,7 +1430,7 @@
1430
1430
  },
1431
1431
  "locationInModule": {
1432
1432
  "filename": "src/awscdk/base.ts",
1433
- "line": 217
1433
+ "line": 230
1434
1434
  },
1435
1435
  "name": "baseOptions",
1436
1436
  "protected": true,
@@ -1466,7 +1466,7 @@
1466
1466
  "immutable": true,
1467
1467
  "locationInModule": {
1468
1468
  "filename": "src/awscdk/base.ts",
1469
- "line": 167
1469
+ "line": 180
1470
1470
  },
1471
1471
  "name": "iamRoleArns",
1472
1472
  "type": {
@@ -1482,7 +1482,7 @@
1482
1482
  "immutable": true,
1483
1483
  "locationInModule": {
1484
1484
  "filename": "src/awscdk/base.ts",
1485
- "line": 172
1485
+ "line": 185
1486
1486
  },
1487
1487
  "name": "stages",
1488
1488
  "type": {
@@ -1523,7 +1523,7 @@
1523
1523
  "immutable": true,
1524
1524
  "locationInModule": {
1525
1525
  "filename": "src/awscdk/base.ts",
1526
- "line": 153
1526
+ "line": 166
1527
1527
  },
1528
1528
  "name": "deploySubStacks",
1529
1529
  "optional": true,
@@ -1540,7 +1540,7 @@
1540
1540
  "immutable": true,
1541
1541
  "locationInModule": {
1542
1542
  "filename": "src/awscdk/base.ts",
1543
- "line": 181
1543
+ "line": 194
1544
1544
  },
1545
1545
  "name": "featureStages",
1546
1546
  "optional": true,
@@ -1557,7 +1557,7 @@
1557
1557
  "immutable": true,
1558
1558
  "locationInModule": {
1559
1559
  "filename": "src/awscdk/base.ts",
1560
- "line": 175
1560
+ "line": 188
1561
1561
  },
1562
1562
  "name": "independentStages",
1563
1563
  "optional": true,
@@ -1570,6 +1570,31 @@
1570
1570
  }
1571
1571
  }
1572
1572
  },
1573
+ {
1574
+ "abstract": true,
1575
+ "docs": {
1576
+ "default": "- all paths trigger the pipeline",
1577
+ "example": "['packages/my-app/**', 'shared-libs/**']",
1578
+ "remarks": "This is useful for monorepos where you only want to run the pipeline\nwhen files in a specific subproject are modified.\n\nFor GitHub, these are used as `on.push.paths` and `on.pull_request.paths` filters.\nFor GitLab, these are used as `only.changes` filters.",
1579
+ "stability": "stable",
1580
+ "summary": "File path patterns that should trigger the pipeline when changed."
1581
+ },
1582
+ "immutable": true,
1583
+ "locationInModule": {
1584
+ "filename": "src/awscdk/base.ts",
1585
+ "line": 150
1586
+ },
1587
+ "name": "paths",
1588
+ "optional": true,
1589
+ "type": {
1590
+ "collection": {
1591
+ "elementtype": {
1592
+ "primitive": "string"
1593
+ },
1594
+ "kind": "array"
1595
+ }
1596
+ }
1597
+ },
1573
1598
  {
1574
1599
  "abstract": true,
1575
1600
  "docs": {
@@ -1579,7 +1604,7 @@
1579
1604
  "immutable": true,
1580
1605
  "locationInModule": {
1581
1606
  "filename": "src/awscdk/base.ts",
1582
- "line": 178
1607
+ "line": 191
1583
1608
  },
1584
1609
  "name": "personalStage",
1585
1610
  "optional": true,
@@ -1616,7 +1641,7 @@
1616
1641
  "immutable": true,
1617
1642
  "locationInModule": {
1618
1643
  "filename": "src/awscdk/base.ts",
1619
- "line": 164
1644
+ "line": 177
1620
1645
  },
1621
1646
  "name": "pkgNamespace",
1622
1647
  "optional": true,
@@ -1632,7 +1657,7 @@
1632
1657
  "immutable": true,
1633
1658
  "locationInModule": {
1634
1659
  "filename": "src/awscdk/base.ts",
1635
- "line": 194
1660
+ "line": 207
1636
1661
  },
1637
1662
  "name": "postSynthCommands",
1638
1663
  "optional": true,
@@ -1653,7 +1678,7 @@
1653
1678
  "immutable": true,
1654
1679
  "locationInModule": {
1655
1680
  "filename": "src/awscdk/base.ts",
1656
- "line": 198
1681
+ "line": 211
1657
1682
  },
1658
1683
  "name": "postSynthSteps",
1659
1684
  "optional": true,
@@ -1674,7 +1699,7 @@
1674
1699
  "immutable": true,
1675
1700
  "locationInModule": {
1676
1701
  "filename": "src/awscdk/base.ts",
1677
- "line": 192
1702
+ "line": 205
1678
1703
  },
1679
1704
  "name": "preInstallCommands",
1680
1705
  "optional": true,
@@ -1695,7 +1720,7 @@
1695
1720
  "immutable": true,
1696
1721
  "locationInModule": {
1697
1722
  "filename": "src/awscdk/base.ts",
1698
- "line": 196
1723
+ "line": 209
1699
1724
  },
1700
1725
  "name": "preInstallSteps",
1701
1726
  "optional": true,
@@ -1716,7 +1741,7 @@
1716
1741
  "immutable": true,
1717
1742
  "locationInModule": {
1718
1743
  "filename": "src/awscdk/base.ts",
1719
- "line": 193
1744
+ "line": 206
1720
1745
  },
1721
1746
  "name": "preSynthCommands",
1722
1747
  "optional": true,
@@ -1737,7 +1762,7 @@
1737
1762
  "immutable": true,
1738
1763
  "locationInModule": {
1739
1764
  "filename": "src/awscdk/base.ts",
1740
- "line": 197
1765
+ "line": 210
1741
1766
  },
1742
1767
  "name": "preSynthSteps",
1743
1768
  "optional": true,
@@ -1760,7 +1785,7 @@
1760
1785
  "immutable": true,
1761
1786
  "locationInModule": {
1762
1787
  "filename": "src/awscdk/base.ts",
1763
- "line": 145
1788
+ "line": 158
1764
1789
  },
1765
1790
  "name": "stackPrefix",
1766
1791
  "optional": true,
@@ -1777,7 +1802,7 @@
1777
1802
  "immutable": true,
1778
1803
  "locationInModule": {
1779
1804
  "filename": "src/awscdk/base.ts",
1780
- "line": 203
1805
+ "line": 216
1781
1806
  },
1782
1807
  "name": "versioning",
1783
1808
  "optional": true,
@@ -2575,6 +2600,99 @@
2575
2600
  ],
2576
2601
  "symbolId": "src/versioning/computation:ComputationContext"
2577
2602
  },
2603
+ "projen-pipelines.CorepackSetupStep": {
2604
+ "assembly": "projen-pipelines",
2605
+ "base": "projen-pipelines.PipelineStep",
2606
+ "docs": {
2607
+ "remarks": "This step is automatically injected when a project uses Yarn Berry as its package manager.\nIt ensures corepack is enabled in the CI environment before running any yarn commands,\nwhich is required for Yarn Berry (v2+) to work correctly.",
2608
+ "stability": "stable",
2609
+ "summary": "Step to enable corepack for Yarn Berry support."
2610
+ },
2611
+ "fqn": "projen-pipelines.CorepackSetupStep",
2612
+ "initializer": {
2613
+ "docs": {
2614
+ "stability": "stable"
2615
+ },
2616
+ "locationInModule": {
2617
+ "filename": "src/steps/package-manager-setup.step.ts",
2618
+ "line": 52
2619
+ },
2620
+ "parameters": [
2621
+ {
2622
+ "docs": {
2623
+ "summary": "- The projen project reference."
2624
+ },
2625
+ "name": "project",
2626
+ "type": {
2627
+ "fqn": "projen.Project"
2628
+ }
2629
+ }
2630
+ ]
2631
+ },
2632
+ "kind": "class",
2633
+ "locationInModule": {
2634
+ "filename": "src/steps/package-manager-setup.step.ts",
2635
+ "line": 50
2636
+ },
2637
+ "methods": [
2638
+ {
2639
+ "docs": {
2640
+ "remarks": "Should be implemented by subclasses.",
2641
+ "stability": "stable",
2642
+ "summary": "Generates a configuration for a bash script step."
2643
+ },
2644
+ "locationInModule": {
2645
+ "filename": "src/steps/package-manager-setup.step.ts",
2646
+ "line": 76
2647
+ },
2648
+ "name": "toBash",
2649
+ "overrides": "projen-pipelines.PipelineStep",
2650
+ "returns": {
2651
+ "type": {
2652
+ "fqn": "projen-pipelines.BashStepConfig"
2653
+ }
2654
+ }
2655
+ },
2656
+ {
2657
+ "docs": {
2658
+ "remarks": "Should be implemented by subclasses.",
2659
+ "stability": "stable",
2660
+ "summary": "Generates a configuration for a GitHub Actions step."
2661
+ },
2662
+ "locationInModule": {
2663
+ "filename": "src/steps/package-manager-setup.step.ts",
2664
+ "line": 56
2665
+ },
2666
+ "name": "toGithub",
2667
+ "overrides": "projen-pipelines.PipelineStep",
2668
+ "returns": {
2669
+ "type": {
2670
+ "fqn": "projen-pipelines.GithubStepConfig"
2671
+ }
2672
+ }
2673
+ },
2674
+ {
2675
+ "docs": {
2676
+ "remarks": "Should be implemented by subclasses.",
2677
+ "stability": "stable",
2678
+ "summary": "Generates a configuration for a GitLab CI step."
2679
+ },
2680
+ "locationInModule": {
2681
+ "filename": "src/steps/package-manager-setup.step.ts",
2682
+ "line": 67
2683
+ },
2684
+ "name": "toGitlab",
2685
+ "overrides": "projen-pipelines.PipelineStep",
2686
+ "returns": {
2687
+ "type": {
2688
+ "fqn": "projen-pipelines.GitlabStepConfig"
2689
+ }
2690
+ }
2691
+ }
2692
+ ],
2693
+ "name": "CorepackSetupStep",
2694
+ "symbolId": "src/steps/package-manager-setup.step:CorepackSetupStep"
2695
+ },
2578
2696
  "projen-pipelines.CustomVersioningConfig": {
2579
2697
  "assembly": "projen-pipelines",
2580
2698
  "datatype": true,
@@ -4104,7 +4222,7 @@
4104
4222
  },
4105
4223
  "locationInModule": {
4106
4224
  "filename": "src/awscdk/github.ts",
4107
- "line": 306
4225
+ "line": 309
4108
4226
  },
4109
4227
  "name": "createAssetUpload",
4110
4228
  "parameters": [
@@ -4131,7 +4249,7 @@
4131
4249
  },
4132
4250
  "locationInModule": {
4133
4251
  "filename": "src/awscdk/github.ts",
4134
- "line": 361
4252
+ "line": 364
4135
4253
  },
4136
4254
  "name": "createDeployment",
4137
4255
  "parameters": [
@@ -4160,7 +4278,7 @@
4160
4278
  },
4161
4279
  "locationInModule": {
4162
4280
  "filename": "src/awscdk/github.ts",
4163
- "line": 140
4281
+ "line": 141
4164
4282
  },
4165
4283
  "name": "createFeatureWorkflows",
4166
4284
  "protected": true
@@ -4172,7 +4290,7 @@
4172
4290
  },
4173
4291
  "locationInModule": {
4174
4292
  "filename": "src/awscdk/github.ts",
4175
- "line": 483
4293
+ "line": 486
4176
4294
  },
4177
4295
  "name": "createIndependentDeployment",
4178
4296
  "parameters": [
@@ -4194,7 +4312,7 @@
4194
4312
  },
4195
4313
  "locationInModule": {
4196
4314
  "filename": "src/awscdk/github.ts",
4197
- "line": 133
4315
+ "line": 134
4198
4316
  },
4199
4317
  "name": "engineType",
4200
4318
  "overrides": "projen-pipelines.CDKPipeline",
@@ -4650,7 +4768,7 @@
4650
4768
  },
4651
4769
  "locationInModule": {
4652
4770
  "filename": "src/awscdk/gitlab.ts",
4653
- "line": 263
4771
+ "line": 265
4654
4772
  },
4655
4773
  "name": "createIndependentDeployment",
4656
4774
  "parameters": [
@@ -4684,7 +4802,7 @@
4684
4802
  },
4685
4803
  "locationInModule": {
4686
4804
  "filename": "src/awscdk/gitlab.ts",
4687
- "line": 294
4805
+ "line": 297
4688
4806
  },
4689
4807
  "name": "engineType",
4690
4808
  "overrides": "projen-pipelines.CDKPipeline",
@@ -8743,6 +8861,6 @@
8743
8861
  "symbolId": "src/versioning/types:VersioningStrategyComponents"
8744
8862
  }
8745
8863
  },
8746
- "version": "0.3.13",
8747
- "fingerprint": "ZI7K8nrAt8N4CNRN0zxqVYfQsLD9tODfVIRn2Xw1Ro0="
8864
+ "version": "0.3.15",
8865
+ "fingerprint": "tRwRe5USo7y3OzD8Bz46nLesJz0KQOmbU3s7qk0Urqo="
8748
8866
  }