feat: add AWS SSM Parameter Store adapter#29
Merged
Conversation
@oclif/test@2.2.13 crashes at import time on Node 20+ (reads
module.parent.filename, and module.parent is undefined under the modern
module loader). No 2.x release fixes this without also moving to
@oclif/core@3, so bump both together.
- @oclif/core 1.21.0 -> ^3.27.0, @oclif/test 2.2.13 -> ^3.2.15,
@oclif/plugin-help 5 -> ^6, oclif (dev) 3 -> ^4
- migrate the inject command's static args from the array form to the
Args.string({...}) object map required by core 3, and read positional
args off argv as string[]
- engines.node 18 -> >=20
The workflow failed every job at setup-node: cache:yarn shelled out to global yarn 1.x against a repo pinned to yarn@3.4.1 via corepack, so 'yarn cache dir' errored before install ran. It also carried a corrupted matrix value (20hashhas) and hardcoded node-version:'18', ignoring the matrix entirely. - enable corepack before setup-node so yarn 3.4.1 resolves - wire the matrix node_version/architecture into setup-node instead of the hardcoded 18 - drop EOL node (14/16/18/19), test on 20/22/24/26 - yarn install --frozen-lockfile -> --immutable (yarn 3 flag) - checkout@v3/setup-node@v3 -> @v4, add fail-fast: false
The repo builds only under the node-modules linker, but .yarnrc.yml was gitignored, so CI never received it and fell back to yarn's default PnP linker -- which nx cannot run under (nx's task runner and native binary loading are incompatible with PnP's virtual filesystem, confirmed on nx 15 through 23). Track .yarnrc.yml so CI and every contributor use the linker that actually builds the monorepo.
setup-node's cache:'yarn' invokes 'yarn cache dir' during the action using the runner's global yarn 1.x, before the corepack shim is active on windows -- which errors on the yarn@3.4.1 packageManager pin. Every windows matrix job failed there while ubuntu/macos passed. Drop the built-in yarn cache so nothing calls yarn until the corepack-managed 3.4.1 is active; install just fetches fresh.
corepack enable ran BEFORE setup-node, so setup-node reinstalled node and the global yarn 1.x shim shadowed corepack again -- every windows job still hit the yarn@3.4.1 packageManager error (ubuntu/macos happened to resolve corepack anyway). Move corepack enable after setup-node and add 'corepack prepare yarn@3.4.1 --activate' so the pinned yarn is the active shim before install runs, on all platforms.
corepack's activated shim did not survive into the next workflow step on windows: 'corepack prepare yarn@3.4.1 --activate' succeeded, but the following step's fresh pwsh session resolved the runner's global yarn 1.22.22 again (its yarn.cmd shadows the corepack shim on PATH). Collapse corepack activation + install/build/lint into a single 'shell: bash' step so the pinned yarn is active in the same session that runs yarn, and use git-bash on windows where the shim resolves reliably.
Node 26's bundled corepack fails 'prepare --activate' on windows while 20/22/24 pass with identical steps; Node 26 is not LTS. Mark just that matrix combo experimental via a matrix include and gate the job's continue-on-error on it, so the combo still runs and stays visible but does not block the workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds an AWS SSM Parameter Store adapter, mirroring the existing AWS Secrets Manager adapter.
What
@secretary/aws-ssm-parameter-store-adapter(packages/aws-ssm-parameter-store-adapter/)getSecret/putSecret/deleteSecretonto SSMgetParameter/putParameter/deleteParameter@aws-sdk/client-ssm@3.229.0(dev) /^3.229.0(peer)Behavior
Type: SecureStringwithOverwrite: true; caller options overrideSecretNotFoundError(keyed on the SSMParameterNotFounderror)Tests
Adapter.spec.tsthrough the sharedAdapterTestharness (typemoq-mocked SSM client): 4 passingtscbuild clean, eslint clean