chore(ci): make workflows consistent across Projen projects (#989)

Author: xiehan

.github/MAINTENANCE.md

@@ -9,33 +9,29 @@ This project is considered experimental, and does not offer any support or maint
 
 ## Security & Dependency Management
 
-Dependency upgrades (for security purposes as well as a best practice) can be divided into three categories: fully-automated, semi-automated, and not automated.
+Dependency upgrades (for security purposes as well as a best practice) can be divided into three categories: fully-automated, not automated, and disabled.
 
 ### Fully Automated
 
 The following Actions exist to automate various dependency upgrades:
 
 - [upgrade-cdktf](https://github.com/hashicorp/cdktf-aws-cdk/actions/workflows/upgrade-cdktf.yml): This is a custom workflow (source [here](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/projenrc/upgrade-cdktf.ts)) that runs four times a day and checks whether there is a new minor version of CDKTF itself (e.g. `0.19`, `0.20`, `0.21`, etc.), using the latest version published to npm as the source of truth. If a new version is found, it runs [this](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/scripts/update-cdktf.sh) script to update the CDKTF version in all the right places, as well as upgrading the minimum required (peer dependency) version of the `constructs` library, for which the source of truth is the peer dependency version of `constructs` required by the `cdktf` package. The PR that gets generated currently requires a human engineer to approve it as a sanity-check, but aside from that the process is fully automated.
+- [upgrade-jsii-typescript](https://github.com/hashicorp/cdktf-aws-cdk/actions/workflows/upgrade-jsii-typescript.yml): This is a custom workflow (source [here](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/projenrc/upgrade-jsii-typescript.ts)) that checks the [JSII support timeline](https://github.com/aws/jsii-compiler/blob/main/README.md#gear-maintenance--support) daily via [this](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/scripts/check-jsii-versions.js) script to see if the current version is less than 30 days away from EOS, and if so, creates a PR upgrading to the next supported version. The code for the upgrade itself lives in [this](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/scripts/update-jsii-typescript.sh) script. This process is 100% automated; as long as the build succeeds and any tests pass, the PR will be automatically merged without any human intervention.
+  - This workflow can also be manually triggered, optionally taking a hard-coded JSII/TypeScript version as input in case we ever want to upgrade to a newer version without waiting until the old one is less than 30 days away from EOS.
 - [upgrade-main](https://github.com/hashicorp/cdktf-aws-cdk/actions/workflows/upgrade-main.yml): This is a Projen built-in/default workflow that handles automated dependency updates. It currently runs on a weekly basis, which can be configured [here](https://github.com/hashicorp/cdktf-aws-cdk/blob/31f9be8c91984be2193db05dc4599b0d5e223fce/projenrc/index.ts#L114). Projen will upgrade itself as part of this process. This process is 100% automated; as long as the build succeeds and any tests pass, the PR that is generated will be automatically merged without any human intervention.
 - [upgrade-node](https://github.com/hashicorp/cdktf-aws-cdk/actions/workflows/upgrade-node.yml): This is a custom workflow (source [here](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/projenrc/upgrade-node.ts)) that runs once a day to check if the current minimum version of Node.js supported by this project is less than 30 days away from EOL; this check is done by [this](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/scripts/check-node-versions.js) script using [this](https://nodejs.org/download/release/index.json) file as the source of truth. If the script determines that the current version is less than 30 days away from EOL, it runs [this](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/scripts/update-node.sh) script to upgrade the project to the next even-numbered (i.e. LTS-eligible) version of Node.js. The PR that gets generated currently requires a human engineer to approve it (in case we want to control the timing of when these upgrades roll out across all of our projects), but aside from that the process is fully automated.
   - This workflow can also be manually triggered, optionally taking a hard-coded Node.js version as input in case we ever want to upgrade to a newer version without waiting until the old one is less than 30 days away from EOL.
 
 Dependabot is also [configured](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/.github/dependabot.yml) to check for new security updates daily and, if found, make changes to the lockfile only. This is because Dependabot can sometimes address security issues in dependencies more quickly than Projen due to its atomic nature. While you could tweak the Dependabot settings, note that Projen and Dependabot do not generally play nicely together; in particular, Dependabot cannot make changes to `package.json` because Projen would just override these changes (hence the reason why Dependabot is currently limited to lockfile-only). If you wanted to fully automate dependency management using Dependabot, you would want to disable Projen's [automatic updates](https://projen.io/docs/api/typescript#projen.typescript.TypeScriptProjectOptions.property.depsUpgrade).
 
-### Semi-Automated
-
-The following Actions either need to be manually triggered or require significant manual effort as part of the upgrade process:
-
-- [upgrade-jsii-typescript](https://github.com/hashicorp/cdktf-aws-cdk/actions/workflows/upgrade-jsii-typescript.yml): This is a custom workflow (source [here](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/projenrc/upgrade-jsii-typescript.ts)) that must be manually triggered because there currently is no programmatic way to determine when a JSII version is no longer supported. This means that somebody should be monitoring the [JSII support timeline](https://github.com/aws/jsii-compiler/blob/main/README.md#gear-maintenance--support) to determine when it's time to upgrade. The script takes as input the desired new version, and all the steps afterwards are fully automated. The code for the upgrade itself lives in [this](https://github.com/hashicorp/cdktf-aws-cdk/blob/main/scripts/update-jsii-typescript.sh) script.
-
 ### Not Automated
 
 - **GitHub Actions version pinning**: Because this project leverages Projen, HashiCorp Security's [tsccr-helper](https://github.com/hashicorp/security-tsccr?tab=readme-ov-file#tsccr-helper-cli) CLI and other tooling cannot be used to manage/upgrade GitHub Actions versions. Instead, we have consolidated all of the versions into a single [object](https://github.com/hashicorp/cdktf-aws-cdk/blob/31f9be8c91984be2193db05dc4599b0d5e223fce/.projenrc.ts#L8-L20) in code that must be manually updated. Historically, one of the maintainers has followed these manual steps on a roughly monthly basis:
   1. Look up the latest supported versions [here](https://github.com/hashicorp/security-tsccr/tree/main/components/github_actions)
   2. Update the [object](https://github.com/hashicorp/cdktf-aws-cdk/blob/31f9be8c91984be2193db05dc4599b0d5e223fce/.projenrc.ts#L8-L20)
   3. Run `npx projen`
   4. Create a new PR with the title `chore(deps): update pinned versions of GitHub Actions`
-- **`aws-cdk-lib` library upgrades**: Because `aws-cdk-lib` is a peer dependency, the `upgrade-main` script described above will _never_ increment its version; this will always need to be done manually by [editing](https://github.com/hashicorp/cdktf-aws-cdk/blob/31f9be8c91984be2193db05dc4599b0d5e223fce/projenrc/cdktf-config.ts#L25) `projenrc/cdktf-config.ts`. This could _in theory_ be (semi)automated like some of our other upgrade workflows described above for things like CDKTF, Node, and JSII, but in practice we currently have no logic or criteria that governs when `aws-cdk-lib` should be updated; as such, creating a custom workflow for it felt like more effort than it's really worth.
+- **`aws-cdk-lib` library upgrades**: Because `aws-cdk-lib` is a peer dependency, the `upgrade-main` workflow described above will _never_ increment its version; this will always need to be done manually by [editing](https://github.com/hashicorp/cdktf-aws-cdk/blob/31f9be8c91984be2193db05dc4599b0d5e223fce/projenrc/cdktf-config.ts#L25) `projenrc/cdktf-config.ts`. This could _in theory_ be (semi)automated like some of our other upgrade workflows described above for things like CDKTF, Node, and JSII, but in practice we currently have no logic or criteria that governs when `aws-cdk-lib` should be updated; as such, creating a custom workflow for it felt like more effort than it's really worth.
 
 ### Disabled