fix: Fix upgrade.yml workflow failure

[lym953]

Motivation

The upgrade.yml workflow upgrades the version of dependencies. It has been failing for a long time (sample GitHub Action run)
because it requires min Node.js version of 16.0.0 but our Datadog CDK Construct requires 14.15.0, and as a result, the projen framework uses version 14.15.0 to run upgrade.yml. I didn't find a way to make upgrade.yml run a later Node.js version without updating the minNodeVersion field of our CDK Construct.

What does this PR do?

Fixes upgrade.yml workflow. Details:

1. In package.json, change projen version from ^0.81.8 to ^0.91.6 (latest so far)
2. In .projenrc.js, change minNodeVersion from 14.15.0 to 18.18.0, which is required by stylistic/eslint-plugin package (see GitHub Action log)
3. Run npx projen

Testing Guidelines

Automated tests

Pass the existing unit tests and integration tests

Manual tests

Steps:

1. Trigger upgrade.yml workflow on this branch
   Result:
2. The workflow runs successfully, which means the dependency issue has been fixed
3. However, PR published by the workflow fails the integration test check. It needs manual changes. I will fix it in a separate PR.

Additional Notes

This is a breaking change in that it changes the required minimum node version minNodeVersion from 14.15.0 to 18.18.0. Therefore I will first merge this PR into the branch yiming.luo/v2-2, which will include the commits to be published in a major version bump (from v2-1.22.0 to v2-2.0.0). I will push more breaking changes to this branch, then bump the major version.

Types of Changes

• Bug fix
• New feature
• Breaking change
• Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

• This PR's description is comprehensive
• This PR contains breaking changes that are documented in the description
• This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
• This PR impacts documentation, and it has been updated (or a ticket has been logged)
• This PR's changes are covered by the automated tests
• This PR collects user input/sensitive content into Datadog

[datadog-datadog-prod-us1]

🟠 Code Vulnerability

Workflow depends on a GitHub actions pinned by tag (...read more)

When using a third party action, one needs to provide its GitHub path (owner/project) and can eventually pin it to a Git ref (a branch name, a Git tag, or a commit hash).

No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state.

Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks.

Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.

    

[lym953]

This is generated code.